<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Proposal: Compression of large packets
From: Josef Drexler <jdrexler,AT,josefsbox,DOT,cjb,DOT,net>
Date: Fri, 30 Nov 2001 23:50:51 +0100
In-reply-to: <Pine.LNX.4.21.0111301352160.28187-100000@raid.kaico.com>

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.

   Josef Drexler                 |    http://publish.uwo.ca/~jdrexler/
 Please help Conserve Gravity    | Email address is *valid*.
 Walk with a light step.         | Don't remove the "nospam" part.

<< | Thread Index | >> ]    [ << | Date Index | >> ]