[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Minimum IP Compression Algorithm for Interoperability
Bronislav also brought up the following point found at the
last bakeoff that most implementations were using the less
efficient Deflate (header and Alder checksum) method and not
using the undocumented feature of the Zlib that avoids that
overhead. I don't believe this mailing list ever resolved
this Deflate issue.
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
From: Slava Kavsan [bkavsan@ire-ma.com]
Sent: Friday, January 14, 2000 1:32 PM
To: ipsec@lists.tislabs.com
Subject: Deflate issue
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;
Follow-Ups: