[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression and encryption
When my customers have run compression I've seen them find
acceptable benefit from using non-history-based compression,
which is to say I feel it's fine to do a reset after every
packet. This case side-steps your analysis. I don't have
enough information at my fingertips to confirm your simulation
matches the field data I have seen.
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.
Follow-Ups: