[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deflate issue
I agree. Our preference is that we all agree on using DEFLATE in the way I described
here - I do not see any need for overheads of extra header, checksum and related
computation.
Avram Shacham wrote:
> Slava,
>
> Am I reading correctly that the DEFLATE decompression is dependent
> on the parameters to the compression process, i.e. an extra attribute
> needs to be negotiated in order to enable the decompression process?
> For comparison, afaik, LZS has the capability to decompress a packet
> regardless of the compression parameters.
>
> Your suggestion to negotiate a DEFLATE-specific attribute,
> while doable and supported by the protocol, will have the side-effect
> of excluding that compression algorithm from the list of well-known
> algorithms, as RFC2393 defines:
>
> Compression Parameter Index (CPI)
>
> 16-bit index. The CPI is stored in network order. The values
> 0-63 define well-known compression algorithms, which require no <==
> additional information, and are used for manual setup. The <==
> values themselves are identical to IPCOMP Transform identifiers
> as defined in [SECDOI]. [...] The values
> 256-61439 are negotiated between the two nodes in definition of
> an IPComp Association, as defined in section 4. Note: When
> negotiating one of the well-known algorithms, the nodes MAY
> select a CPI in the pre-defined range 0-63.
>
> In order to keep the advantages of using a well-known algorithm ID,
> I'd suggest (a) modifying RFC2394 to dictate a unified approach,
> or (b) creating multiple DEFLATE IDs in the DOI, one for each option.
>
> avram
>
> At 01:32 PM 1/14/00 -0500, Slava Kavsan wrote:
> >We discovered some Deflate implementation differences that control the
> >inclusion of the Deflate
> >header and Adler32 checksum. RFC2394 makes no mention of the Deflate
> >header or Adler32 checksum . These items are redundant in the case of
> >IPCOMP.
> >
> >It doesn't make sense to spend the time to do it as it uses bandwidth
> >unnecessarily for the extra
> >(8?) bytes.
> >
> >Unfortunately, the ability to NOT include the Deflate header and Adler32
> >
> >checksum is an undocumented feature of the ZLIB implementation of
> >Deflate,
> >which is controlled by the -15 parameter to the deflateInit2_()
> >
> >Sooooo... should the inclusion of the extra header and the checksum be
> >controlled by another IPCOMP attribute or should we simply all change
> >the way Deflate engine is initialized from:
> >
> >if (Z_OK != deflateInit(&c_stream, Z_DEFAULT_COMPRESSION)) break;
> >
> >to:
> >
> >if (Z_OK != deflateInit2_(&c_stream, Z_DEFAULT_COMPRESSION, Z_DEFLATED,
> >-11,
> >DEF_MEM_LEVEL, Z_DEFAULT_STRATEGY, ZLIB_VERSION, sizeof(z_stream)))
> >break;
> >
> >And similar for Inflate, from:
> >
> >if (Z_OK != inflateInit(&d_stream)) break;
> >
> >to:
> >
> >if (Z_OK != inflateInit2_(&d_stream, -15, ZLIB_VERSION,
> >sizeof(z_stream))) break;
> >
References: