RE: TO COMPRESS OR NOT TO CMPRS (please reply)

[Stephen Kent <[e-mail]>]

Rob,

	As you noted, compression, like encryption, can be provided at
various layers.  We have to make smart choices as to where to offer the
function, but that doesn't mean that there is a single, right answer, no
more than there is a single, right layer at which to offer encryption.

	Compression can be optimized at the application layer where there
is knowledge of the data types being compressed, and for static, stored
data (e.g., GIFs) this is great.  But, not all of our traffic is of this
sort, and so we cannot rely on this later of compression in all cases.
Encryption at the application layer has many of the same benefits, but it
also has drawbacks, e.g., the need to develop and/or integrate the
mechanisms for each application (hence the motivation for GSSAPI).

	At the other end of the stack, we do link layer compression
whereever it seems useful, at a point where we have no knowldege at all
about the data types.  This has proved quite useful for dialup and wireless
transmission systems.  It often is done in hardware and is applied
selectovely, where the processing/bandwidth tradeoff analysis suggests it
is useful.  However, use of encrytion at any higher layer negates the
effectiveness of link layer encryption, and that is one motivation for
inclusion of compression at a higher layer.

	The IP layer is a good candidate primarily because that's where we
are adding encryption (in the context of this WG) and thus we have the
opportunity to help offset the effects of the encryption that we are
imposing.  Of course, we don't have access to data type info, so we won't
be able to do as good a job as at the application layer, but we do have the
benefit of being able to apply (or consider applying)  compression to all
the traffic we encrypt, without modifying any other protocols, i.e., by
keeping within the subl-layer where we are introducing new protocols anyway.

	If we move up to the transport layer, there isn't any better data
type knowledge, and we now are looking at making changes to each transport
protocol (if we want to offer as broad a service), plus having to change a
protocol that was not being modified otherwise (or adding a new sub-layer).
Also, if we choose to compress because we are encrypting, compressing at
the tranport layer is not consistent with the use of ESP, since ESP is a
lower layer and knowledge of its use should not be visible at the transport
layer.

	SSL, in optionally offering compression, is taking the same tact
that we are exploring for ESP, and I think that is consistent.

	From a pragmatic perspective, if we don't offer compression in ESP,
then we ought not expect it to be available anytime soon, to help counter
the packet size expension effects of ESP and to help alleviate the link
layer compression loss problems.

Steve