[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Minimum IP Compression Algorithm for Interoperability

<David_Mason@nai.com> wrote:

 > If I recall it was suggested that the header and Alder checksum
 > would be included if the IPCOMP_DEFLATE transform ID was used
 > as it is currently specified in the DOI (rfc2407) and that a
 > new transform ID would be allocated to specify Deflate without
 > the header and Alder checksum.
 > 
 > -dave

My recollection agrees with you about "it was suggested" but there were
multiple suggestions and no apparent group concensus on the issue.  See
the prior discussion on this topic in the Jan 14->24 archives for ipsec
or ippcp with subject "Deflate issue".

The point was also made that the extra header and Alder checksums:
added unnecessary computational and space overheads for ipsec/ippcp
usage, was an "artifact" of how a existing/ZLIB implementations worked,
and no one responded to my requests for any advantages to the usage of
Alder32 and the deflate header that makes them worth using.  Also, the
existing IPCOMP documents' DEFLATE references do *not* refer to any
documents which specify Adler32 and header checksums unless you search
"deeper" (as in ZLIB specs or code), beyond whats specified by IPCOMP
RFCs 2393/2394 with their RFC 1951 reference for the basic DEFLATE
functionality.  Suggested wording had been supplied to clarify the
existing DEFLATE documents that are under control of the IPCOMP working
group.  But, admittedly, there was no working group concensus that I
could detect on what to do here.  No one commented on the specification
clarifications made by myself or Slava.

There are apparently some people who implemented these Alder checksums
and deflate headers, presumably because of their usage of the ZLIB
implementation.  And these people (several?) interoperated fine at
bake-offs, with this extra overhead that ZLIB generates in certain
configurations.  Even someone in *that* group stated "...we were all
(except IRE) wrong.".  But, admittedly, properly enforcing the basic
specs could be a problem for a deployed based depending upon how much
interoperation is going on out there now.  Can anyone comment on
whether there's significant inter-vendor DEFLATE usage with the extra
Adler32 checksums and header?

OTOH, someone coding strictly from the specs as I and others did would
*not* (and don't) have Adler32 checksums nor deflate headers in their
implementations.  Perhaps we need a poll on what vendors have done
what.

I'd argue that its the more efficient variation that should *remain*
the official DEFLATE specification for the long-haul and that
additional transform IDs could be used for the "deflate with additional
stuff" as a transition aid.  Or the current transform ID's value could
even become the transitional one, to save the (re)deployment
heartbreak.  But even if we decided, due to deployed base, to make the
inefficient version the official DEFLATE its going to require more
updating/explanation in the existing IPCOMP specs to guard against
future implementation errors, let alone to properly describe the
protocol.  The minimal verbiage/procedures supplied by Slava and myself
in the archives is all that would be needed to warn future implementers
to do the right thing for the more efficient variation which the specs
currently describe.

But this has to be worked out as a group.
                        
                         
   -- Marc --
Follow-Ups: