Re: Proposal: Compression of large packets|
Sat, 1 Dec 2001 00:11:24 +0100|
I agree: We should find out which bit we could use for zpackets from
Olaf. For the moment, would it be kosher to just use one arbitrarily for
For configuring the compression of packets, there should be an option that
reads: if length(zpacket) is X% less than length(packet), send
zpacket; else send packet.
This would add considerable latency, but it could be coupled with 'and
length(packet) > 100' or some such thing. It may also make sense to check
the TOS flag. If the packet is flagged 'Minimize-Delay 16 (0x10) (from
iptables)', then never compress. That way we do our best to compress
everything, and let minimum delay packets through as fast as possible.
On Fri, 30 Nov 2001, Josef Drexler wrote:
> On Fri, 30 Nov 2001 ewheeler,AT,kaico,DOT,com wrote:
> > As I understand the code, ciped only exists to keep the bring up/down &
> > configure the cipcbX interface. I had thought all traffic and encryption
> > handling happens in the kernel. I agree, if this can happen in userland,
> > all the better; but I know know if it will be possible.
> You're probably right about the module, that would make sense. And if we
> can't do it in user-space a module will have to be good enough for now.
> > What do you mean by "...we can have a bit in P..." below? I've not heard
> > the colloquialism.
> I just mean that there needs to be a way to distinguish between compressed
> and uncompressed packets, and in the description of the CIPE protocol
> there is a value called "P" that would serve this purpose. Currently bits
> 7, 3 and 0 are reserved, and one of these could be used to indicate
> whether a packet is compressed. This is necessary so that we can avoid to
> send packets where compression increased the size, and also to use
> compression only for certain packets. Right now I would like to be able
> to choose based on packet size, but additional hooks would be useful, for
> example to exclude ssh packets based on tcp ports because they cannot be
> Alternatively we could define a new packet type, compressed data using one
> of the currently reserved types 10 or 11. Either choice might interfere
> with Olaf's future plans so I would like to have his input on this first.
20417 SW 70th Ave.
Tualatin, OR 97062