[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression and encryption
On Thu, 7 Nov 1996, Steven Bellovin wrote:
> It's quite compatible with n=1, which is more or less my point -- that
> we need to use very small burst sizes. 1 is a very nice low number,
> and it makes the protocol a lot simpler.
>
> If someone wants to accept the potential impact of using a
> history-based compression scheme I don't see any reason to
> architect the protocol to stop them. On the other hand, if
> there's not 'rough consensus' for putting compression into ESP
> then fine, don't put it in.
>
> There's still the 'next header' field so the stand-alone
> compression transform can be used.
>
> Yes. If we're going to do compression at this layer, that may be the
> right answer. But we should measure the effectiveness of compression
> when you have a dictionary in each packet, and the packets are ~512
> bytes uncompressed.
A quick bit of hopefully helpful background --
A few years ago, when compression was being discussed in the context of
PPP there was a proposal offered by HP for a 'stateless' compressor. I was
a bit fuzzy on the details (and still am) but the essence was some clever
folk had examined the nature of the available entropy in short bit streams
and tuned some variant of LZ+ to focus at that level. The result claimed
was better compression where "n=1". How much better and how much heat
would get generated at both ends was never made clear. As well, there were
some patent issues involved if memory serves.
--
Ian Duncan <iduncan@Newbridge.com>
Access Products Development
Newbridge Networks Corp.
References: