[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compression and encryption
At 02:13 AM 11/8/96 +0000, Steven Bellovin wrote:
> 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.
>
Below is a table of numbers that shows an example of the tradeoff
between compression efficiency and the parameter n in a "reset after n
packets" strategy. The table is from an appendix in
<draft-sabin-esp-des3-lzs-md5-01.txt>. It is based on the LZS
compression algorithm.
Here's the row of the table that corresponds to 512-byte payloads:
n: 1 2 4 8 16 32
Compression ratio: 1.58 1.73 1.89 2.01 2.08 2.11
In the case n=1, the compression boosts throughput by about 60%.
(Headers are neglected here.) Larger values of n give better compression,
obviously.
-----------------------------------
>From <draft-sabin-esp-des3-lzs-md5-01.txt>:
9. Appendix: Guidelines for Resetting Compression Histories
The following table offers some guidance on how frequently an LZS
compression history can be reset. The table considers two
parameters: "payload_bytes," the number of bytes in each payload; and
"reset_bytes," the number of bytes between history resets.
Reset_bytes is a multiple of payload_bytes, since an integer number
of payloads is processed between resets. Each entry in the table
shows the compression ratio that was achieved when compressing a test
file with the corresponding values of payload_bytes and reset_bytes.
The test file was the University of Calgary Text Compression Corpus
[Calgary]. The length of the file prior to compression was 3,278,000
bytes. When the entire file was compressed as a single payload, a
compression ratio of 2.34 resulted.
| reset_bytes
| 64 128 256 512 1024 2048 4096 8192 16384
------------+-----------------------------------------------------
packet_bytes|
64 | 1.18 1.26 1.37 1.48 1.61 1.74 1.84 1.89 1.92
128 | 1.28 1.40 1.53 1.67 1.82 1.93 1.99 2.03
256 | 1.43 1.56 1.71 1.86 1.98 2.05 2.08
512 | 1.58 1.73 1.89 2.01 2.08 2.11
1024 | 1.74 1.90 2.02 2.09 2.13
2048 | 1.91 2.03 2.10 2.14
4096 | 2.04 2.10 2.14
8192 | 2.11 2.14
16384 | 2.14
The table suggests that not there is not much degradation in
compression ratio if the compression history is reset after several
thousand bytes have been processed. Resetting after less than 1,000
bytes is probably too soon -- the compression ratio degrades
significantly. But waiting longer than about 8,000 bytes gains
little -- the compression ratio does not increase much.