Subject: Re: LZS compression for IPPCP

From: Avram Shacham <[email-masked]>
Date: Fri, 01 Aug 1997 15:36:44 -0700

At 09:25 AM 8/1/97 -0700, Bob Monsour wrote:

>Title: IP Payload Compression Using LZ
<SNIP>
>1.2 Background of LZS Compression
<SNIP>
>   The LZS algorithm uses a sliding window of 2,048 bytes.

In the typical IP over Ethernet environment, where MTU is 1500 bytes, why
use 2048 bytes as a sliding window?

<SNIP>
>   LZS achieves a compression ratio of 2.34:1 on the University of
>   Calgary Text Compression Corpus [Calgary].

See my comments to "7. Appendix: Compression Efficiency versus Datagram Size".

>2.2 Anti-expansion of Payload Data
<SNIP>
>   If the size of a compressed IP datagram, including whatever overhead
>   is included to define the compression protocol, is not smaller than
>   the size of the original IP datagram, the IP datagram MUST be sent in
>   the original non-compressed form.  This policy ensures saving the
>   decompression processing cycles and avoiding incurring IP datagram
>   fragmentation when the expanded datagram is larger than the MTU.
>
>   Small IP datagrams are more likely to expand as a result of
>   compression. Therefore, a numeric threshold SHOULD be applied before
>   compression, where IP datagrams of size smaller than the threshold are
>   sent in the original form without attempting compression.  The numeric
>   threshold is implementation dependent.
>
>   An IP datagram with payload, which has been previously compressed,
>   tends not to compress any further.  Such previously compressed payload
>   may be the result of external processes, such as compression applied
>   by an upper layer in the communication stack, or by an off-line
>   compression utility.  An adaptive algorithm SHOULD be implemented in
>   order to avoid the performance penalty of futile compression attempts.
>   Such as adaptive algorithm is implementation dependent and independent
>   of compression method. 

These paragraphs already appear in the protocol draft and afterwards in the
architecture draft. Why duplicate and not just refer to the
architecture/protocol I-D?

>4. Security Considerations
>
>   This memo discusses the use of lossless compression technology in the
>   Internet Protocol. This can include use of IP Security. The proposed
>   use of compression within this protocol is not believed to have an
>   effect on the underlying security functionality provide by the
>   protocol; i.e., the use of compression is not known to degrade or
>   alter the nature of the underlying security architecture or the
>   encryption technologies used to implement it.

What about IP compression without IPSec?  For example, IP compression can
prevent firewalls from "seeing" ULP fields, such as TCP port.

>7. Appendix: Compression Efficiency versus Datagram Size
>
>   The following table offers some guidance on the compression efficiency
>   that can be achieved as a function of datagram size.  Each entry in
>   the table shows the compression ratio that was achieved when LZS was
>   applied to a test file using datagrams of a specified size.
>
>   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.
>
>    Datagram size,|
>    bytes         |  64   128   256   512  1024  2048  4096  8192 16384
>    --------------|----------------------------------------------------
>    Compression   |1.18  1.28  1.43  1.58  1.74  1.91  2.04  2.11  2.14
>    ratio         |

In the IP environment, where each packet is compressed without history (as
you defined in sec 2.1 of this draft), how can one compress a 3.2MB file "as
a single payload"?  Instead, could you refer to the results of IP
compression using LZS, that I presented in IETF #38?  The results of the
tests show a ratio of 1.78:1 for the Calgary files when MTU of 1500 bytes is
used.

Moreover, the same results show that packets of size less than 128 bytes
rarely compress.

avram

---

From: Daniel Harkins <[email-masked]>
Date: Fri, 01 Aug 1997 16:03:26 -0700

> prevent firewalls from "seeing" ULP fields, such as TCP port.

  Do you see this as a benefit? I hear enough grumbling that IPSec masks
that information and renders typical switching and queueing methods void.
With IPSec I at least can try to convince customers that this is a "feature" 
because it prevents traffic analysis. 
  I'm not saying compression without IPSec is bad (in fact, I'm pretty 
agnostic about it), just that preventing firewalls, or just plain ol' routers,
from seeing ULP fields is _not_ good.

  Dan.