Subject: Re: WG last call: Local Compression

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Sun, 31 Oct 1999 22:24:10 -0500

I've been a mild supporter of Local Compression in the past, but I
have not admit that I'm no longer sure the added complexity is worth
the payback, particulalry the DNSSEC complexities.  However, I'm also
not convinced that EDNS negotation of a RR ceiling for global
compression, althogh better, if the best way to go.

How about EDNS negotiation of just plain compressing the whole answer,
or at least everything after the header, with some general compression
algorithm?  It would not seem to be too hard to do some tests to find
out how much this would gain.  In fact, I vaguely recall hearing that
someone had sone such tests and found a bigger improvement than from
global compression and, due to a faster cpu than net, an improvement
in speed....

Thanks,
Donald

From:  Brian Wellington <[email-masked]>
Date:  Thu, 28 Oct 1999 11:32:24 -0400 (EDT)
To:  [email-masked]
cc:  Olafur Gudmundsson <[email-masked]>
In-Reply-To:  <4.1.19991013145730.00a50100@localhost>
Message-ID:  <[email-masked]>

>On Thu, 14 Oct 1999, Olafur Gudmundsson wrote:
>
>> As indicated in the minutes of the DNSIND meeting, the WG meeting 
>> in Oslo concluded that the "Local Compression" draft is ready for WG last 
>> call.
>
>I don't think that the local compression draft should be advanced.  As
>stated before, by Mark Andrews and others, there's a real problem with
>DNSSEC verification of locally compressed data, as it has two valid
>canonical forms.  The only advantage of local compression is a decrease in
>packet size when using records which cannot otherwise be compressed, which
>is not a common occurence (especially since BIND compresses MX records).
>
>There has been mention several times about including a list of
>compressible record types in the EDNSx specifications.  If EDNS1, which is
>in limbo somewhere, were to specify that all record types <= n (where n is
>the highest allocated type code) could be compressed with global
>compression, this would solve the size problem, which not adversely affect
>DNSSEC.  Since we can assume that EDNS will be implemented soon, and in
>use soon afterwards, we can have compression of all record types without
>any real protocol changes or additional code complexity.  This would
>remove any need for local compression.
>
>Brian
>
>