Subject: To Be Cached, or Not To Be Cached, That is the Question

From: Kevin Darcy <[email-masked]>
Date: Wed, 16 Feb 2000 16:54:37 -0500

Hello All,
                Talking about OPT flags (EDNS0, EDNS1), how about one
that means "Answer Will Not Be Cached"? Seems to me a Not-To-Be-Cached
DNS answer could be optimized in some dramatic ways:

    1. Except for referrals (and ???), the Authority and Additional
sections could be omitted.
    2. TTL fields could be omitted.

Imagine the savings in packet sizes and processing costs!

Although undoubtedly far more modest, maybe some optimizations could
also be achieved for answers which a server knows is going to a
caching-capable requestor. For instance, maybe a server could safely
assume that a requestor capable of caching answers is also capable of
performing sorting and/or ordering of answer sets, and could therefore
forego such operations itself, thus eliminating duplicated
sorting/ordering effort.

Although a given client or server process would normally *always* set or
not set the Not-To-Be-Cached flag for all queries it generates, in some
circumstances I could see an application for dynamic and/or temporary
switching of behavior, e.g. during a memory-exhaustion situation, a node
which normally caches may switch to Not-To-Be-Cached queries while it
goes about freeing up memory resources (presumably by purging old cache
entries).

A couple of caveats immediately spring to mind:

   1. A server performing recursion should give a downstream client an
answer in the format the client requests, regardless of the format the
server uses to communicate with upstream servers. A non-caching server
performing recursion should simply preserve the Not-To-Be-Cached flag
and pass the answer through. A caching server performing recursion for a
self-identified non-caching client should convert the answer to
Not-To-Be-Cached format.

    2. To reap full benefits of this optimization, the default for
resolvers should at some point switch from To-Be-Cached to
Not-To-Be-Cached. At that time, any applications using a resolver API,
and which require "full" (To-Be-Cached) DNS answers, will need to
explicitly turn on an option to get them. This will require a certain
amount of advance notice and coordination, but should be fairly easily
implementable with a construct like

#ifdef RES_NOCACHE
_res.options &= ~RES_NOCACHE;
#endif

Am I totally out to lunch here? Please point out the error of my ways.

- Kevin

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: [email-masked]
Date: Thu, 17 Feb 2000 10:23:40 +1100

Generally caching is a good thing and just because one client
	also has a cache is no reason not to cache an answer.  So far
	in over 10 years of working with the DNS I have only found one
	example where the client requesting the cache be disabled would
	be useful.

	That case was discovering the zone a domain belonged to and even
	then only to disable negative caching.

	Mark
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 17 Feb 2000 10:29:34 +1100

Date:        Wed, 16 Feb 2000 16:54:37 -0500
    From:        Kevin Darcy <[email-masked]>
    Message-ID:  <[email-masked]>

  |                 Talking about OPT flags (EDNS0, EDNS1), how about one
  | that means "Answer Will Not Be Cached"?

I'm not sure the saving is worth it - it would need careful investigation
of what canbe saved.

  |     1. Except for referrals (and ???), the Authority and Additional
  | sections could be omitted.

Those can be omitted now if they aren't sending anything useful, and
omitting them does any good.  Whether the answer is to be cached or not
is generally irrelevant (the SOA in an NXDOMAIN might be the one difference).

  |     2. TTL fields could be omitted.

That would not be a good idea at all - it would mean the packet format
would change in a horrible way - the saving there just isn't worth it.

  | Imagine the savings in packet sizes and processing costs!

The server is where the processing costs are, and the cost to make the
decision is likely to be more than the saving of not copying in the
extra few bytes.

  | For instance, maybe a server could safely
  | assume that a requestor capable of caching answers is also capable of
  | performing sorting and/or ordering of answer sets, and could therefore
  | forego such operations itself, thus eliminating duplicated
  | sorting/ordering effort.

Servers shouldn't be sorting answers in any case, they don't have
nearly enough information to work out what a sane ordering is.

Until some real benefit can be found - something which the server could
really avoid doing in an answer which is not to be cached, I don't think
it is worth spending much time on this.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 16 Feb 2000 19:07:46 -0500

>         then only to disable negative caching.

Mark,
          I don't think you quite understood my suggestion. The client
wouldn't be able to disable the server's cache; it would only be capable of
asking that the response to its own query be given in a slimmer,
non-cacheable form. The server would still cache answers -- if that is its
normal mode of operation -- regardless of the respective formats in which it
answered its clients.

- Kevin

---

From: "D. J. Bernstein" <[email-masked]>
Date: 17 Feb 2000 02:16:36 -0000

My cache always omits AU and AR. BIND could do the same when RD is set.
I don't see the need for a protocol extension.

---Dan

---

From: [email-masked]
Date: Thu, 17 Feb 2000 12:02:35 +1100

> normal mode of operation -- regardless of the respective formats in which it

	We were talking at cross purposes apon re-reading.

	Mark

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 16 Feb 2000 20:29:06 -0500

> is generally irrelevant (the SOA in an NXDOMAIN might be the one difference).

Current implementations can only guess whether the requestor will find Authority
or Additional information "useful" or not. Maybe the requestor doesn't need the
extra data *now*, but should have it in cache for some future query. On this
assumption, most server implementations understandably seem to err on the
"safe" side and populate Authority and Additional sections willy-nilly. This is
wasted processing and packet bloat if the client doesn't care about the data. If
it is known that the answer won't be cached, the server can, I believe, assume
that the requestor has a "short-attention span" and only cares about data
directly relevant to the question asked or successful resolution of same, i.e.
the answer itself, or a referral (or possibly the SOA for an NXDOMAIN, as you
mentioned).

> would change in a horrible way - the saving there just isn't worth it.

4 octets per RR isn't worth it? It seems like some of the recent
DNS protocol-enhancements have been focused on packet- or message-size
limitations, and some of them call for more convoluted manipulations than a
simple conditional skipping of the TTL field in the low-level RR encoding and/or
decoding routines. Are we (collectively) being penny-wise and pound-foolish? The
packet-space is there; it's just being squandered right now by caching-related
information that's only useful some certain percentage of the time.

> decision is likely to be more than the saving of not copying in the

I guess I was thinking about packet-size savings primarily and processing
optimization secondarily. Having said that, though, the decision should be
pretty cheap, since it requires matching only a single bit. Plus the omission of
Authority and Additional sections is bound to save some processing cycles as
well. And don't forget that smaller packets mean less processing -- often
interrupt-level processing -- in the lower levels of the protocol stack.
Overall, I see it as being a significant performance and latency win.

> nearly enough information to work out what a sane ordering is.

Ah, you discovered my ulterior motive! That's all I'll say for now...

> it is worth spending much time on this.

1. 32 TTL bits per RR2. a much higher confidence -- I hesitate to use the term
"certainty" --  that the Authority and Additional sections can be safely omitted
from the response.

There's gold in them thar hills!

I was dreading a reply more along the lines of "You can't omit Authority in X
situation, because, unbeknownst to you, the client may need to do Y and/or Z,
and those actions have a dependency on Authority data", which would be a
significant spanner in the works. But, no offense intended, a "the savings don't
seem to be worth it" type of response doesn't deter me at all from further
research and experimentation. I think I have a pretty good gut feel for what
performs well and what doesn't, and this mod sure feels like a performance
winner to me.

Would any of this impact the security extensions? Positively *or* negatively?

- Kevin

---

From: [email-masked]
Date: Thu, 17 Feb 2000 17:00:10 +1100

> Would any of this impact the security extensions? Positively *or* negatively?

	If your client needs to authenticate negative answers some of the
	authority section needs to be sent.

	Mark

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 17 Feb 2000 16:59:10 -0500

> My cache always omits AU and AR. BIND could do the same when RD is set.

Isn't that behavior a little indiscriminate? The requestor could be a
caching server _selectively_ forwarding to you. In that case, you're
depriving it of potentially valuable, query-saving information.
Admittedly, you're optimizing for the general case (which IMHO is an
improvement over BIND's behavior), but the bottom line is, without some
explicit indication from the requestor, the server is limited to pure
guesswork as to whether the client will be able to productively use AU,
AR, or TTL. My aim is to take the guesswork out of the equation.

> I don't see the need for a protocol extension.
What level of performance gains and/or packet-size-reduction would change
your mind?

- Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 17 Feb 2000 17:07:47 -0500

[email-masked] wrote:

>> I was dreading a reply more along the lines of "You can't omit Authority
>> in X situation, because, unbeknownst to you, the client may need to do Y
>> and/or Z, and those actions have a dependency on Authority data", which
>> would be a significant spanner in the works. But, no offense intended, a
>> "the savings do n't seem to be worth it" type of response doesn't deter
>> me at all from further research and experimentation. I think I have a
>> pretty good gut feel for what performs well and what doesn't, and this
>> mod sure feels like a performance winner to me.
>>

Thanks, Mark: that's the kind of "gotcha" I was looking for.

Pardon my ignorance -- I haven't dealt with the security extensions in any
depth -- but would the server *know* that the client needed the Authority
section in such a situation?

- Kevin

---

From: Doug Barton <[email-masked]>
Date: Thu, 17 Feb 2000 20:30:04 -0800

> I'm not sure the saving is worth it - it would need careful investigation

	How many millions of queries per day/month/year do you have to have before
saving N number of bytes per query becomes significant? Personally I'd love
to save those bytes wherever possible, and would fully support an
innovation like this. 

Doug
-- 
"Welcome to the desert of the real." 

    - Laurence Fishburne as Morpheus, "The Matrix"

---

From: [email-masked]
Date: Fri, 18 Feb 2000 14:28:27 +1100

> section in such a situation?

	Yes (CD bit), but it doesn't know when it doesn't need them.
	See RFC 2535.
--
Mark Andrews, Nominum Inc. / Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Fri, 18 Feb 2000 18:07:36 +1100

Date:        Thu, 17 Feb 2000 20:30:04 -0800
    From:        Doug Barton <[email-masked]>
    Message-ID:  <[email-masked]>

  | How many millions of queries per day/month/year do you have to have before
  | saving N number of bytes per query becomes significant?

If we really believed that saving a few bytes from DNS responses was
worth mangling the packet formats, we would have optimised away (from
almost all uses) the class field from RR's years ago (perhaps leave it
in the question section and omit it elsewhere).

The pain of having to cope with packet (and even RR) formats that aren't
the same everywhere just isn't worth the gain.

kre

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 18 Feb 2000 19:21:30 -0500

> in the question section and omit it elsewhere).

This isn't "years ago", it's *now*, with the address lists of large server
clusters
being thrown around in DNS responses, which are increasingly being re-queried via
TCP because of UDP packet size limitations. The packet-size situation is bound to
get even worse when SIG/NXT/A6/SRV/etc. RR's start showing up more ubiquitously
in responses, not to mention multiple-answers-to-multiple-questions responses.
Whatever undoubtedly exhaustive research was done years ago to determine that
optimizing the class field wasn't worth any "mangling" is in serious need of
review in light of the subsequent extensions and evolving usages of the protocol
-- pain-versus-gain is a moving target here! And there's nothing to say that
class-field omission couldn't be rolled into this protocol "weight-reduction"
effort as well; thanks for bringing it up.

> the same everywhere just isn't worth the gain.

To get a handle on the "pain" level, I just whipped up an
experimental-but-functional version of BIND 8.2.2-p5 -- just the named, nslookup
and resolver library parts of the distribution -- which implements the
NCF (non-cacheable format) option, as I have spec'ed it up to this point.
I picked BIND 8 rather than BIND 9 because of the relative infancy of the latter
plus my greater familiarity with the BIND 8 code base; however, since BIND 8
doesn't support OPT, I had to cheat a little bit and give NCF meaning to the
Z bit instead. Results:

changed or added lines of code (not including #ifdef's, comments, or mere
indentation changes):
    named: 37
    nslookup: 30
    resolver library functions and resolv.h: 5

The named binary (Sun Sparc, with full debugging) was less than 0.7% larger than
an unmodified named.

So far, it doesn't look too painful to me. Of course, I realize NCF would require
changes in *many* more places than just these. But experience so far is that a
"if the NCF bit is set, skip the TTL field" conditional is quite trivial to code
(a large percentage of the "nslookup" code changes, for instance, involved
debug-output and option-setting rather than low-level response decoding). And
since -- as previously pointed out in this thread -- inclusion of Authority and
Additional sections in responses is often optional anyway, client applications
should *already* be prepared to deal with answers missing those sections.

Next week, if I have the time, I'll run some performance trials.

- Kevin

---

From: Jim Reid <[email-masked]>
Date: Tue, 22 Feb 2000 09:43:27 +0000

>>>>> "Kevin" == Kevin Darcy <[email-masked]> writes:

    Kevin> This isn't "years ago", it's *now*, with the address lists
    Kevin> of large server clusters being thrown around in DNS
    Kevin> responses, which are increasingly being re-queried via TCP
    Kevin> because of UDP packet size limitations. The packet-size
    Kevin> situation is bound to get even worse when SIG/NXT/A6/SRV/etc. 
    Kevin> RR's start showing up more ubiquitously in responses

Indeed. And that's what is solved by EDNS0. It gives us bigger DNS
payloads without breaking anything in the current installed base. And
saving a few bytes in a DNS packet is moot when you consider how big
the typical SIG record is.

    >> The pain of having to cope with packet (and even RR) formats
    >> that aren't the same everywhere just isn't worth the gain.

    Kevin> To get a handle on the "pain" level, I just whipped up an
    Kevin> experimental-but-functional version of BIND 8.2.2-p5 --
    Kevin> just the named, nslookup and resolver library parts of the
    Kevin> distribution

I believe you miss the point. It's not an issue about how quick
someone can hack code or even how many lines in BIND have to be
changed. The issue is interoperability. One part of that is testing
and deploying this change. Just look at the number of installations
that are still running BIND4, or the number of vendors who still ship
BIND4 with their OS. [And remember BIND isn't the only DNS
implementation out there.] An even bigger issue will be preserving
compatibility with the millions of resolvers and name servers that are
currently in use and expect/demand that DNS packets are in the current
format. They will choke badly if the explicit class and TTL fields go
away as you (seem to) propose. And you've *no hope* of ever getting
all of that installed base upgraded.

Personally, I think micro-optimising the size of DNS packets is a
waste of time and effort. Why is anyone worrying about a few bytes in
a DNS packet when there are petabytes of unmitigated junk - spam,
netnews, www, streaming audio/video, etc. - crossing the Internet
every day? What fraction of the Internet's traffic is DNS these days
anyway, 2-3%? Would shaving a few bytes from every DNS packet make the
world a better place? Will the typical dialup or T1 user even see a
difference?

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 22 Feb 2000 23:24:07 -0500

Jim Reid wrote:

> Indeed. And that's what is solved by EDNS0.

With all due respect to the creators of EDNS0, I wouldn't say that the
UDP-payload-size field -- assuming that's what you are referring to --
"solves" the problem of protocol bloat. It's more of an accommodation than
a solution. It allows bigger UDP transactions between capable nodes and
helps avoid some of the UDP-truncated-retry-via-TCP waste and delays, but
doesn't get to the root cause of why the query was so large that it didn't
fit into the default-payload UDP packet in the first place. In other words,
payload-size-reporting increases "supply" of network (and to a lesser
extent, processing) resources, whereas an NCF (non-cacheable format) option
reduces "demand" on those resources. It's kind of like the recurring
political question: prevent crime or build more jails? NCF is prevention;
payload-size-reporting builds a bigger hoosegow.

> It gives us bigger DNSpayloads without breaking anything in the current
> installed base.

As a client-originated EDNS *option*, NCF wouldn't break anything in the
installed base unless and until the low-level resolver API default was
changed, which wouldn't happen until the option was widely tested and
accepted. See below.

> And

I still profess relative ignorance of the security extensions. How big is
the "typical" SIG record?

> all of that installed base upgraded.

As mentioned above, NCF would be a client-originating option in the EDNS
framework. If the resolver doesn't grok NCF, then it doesn't set the
NCF flag and doesn't receive NCF responses. The *servers* have to change,
granted, but only conditional on a certain EDNS{X} (where {X} is
> 1) conformance level. If the server doesn't grok EDNS{X}, the client will
discover this quickly and know to not set the NCF flag, in which case they
will get "classic", obese responses as always.

Now, in my original message I made reference to a "big switch" where the
low-level resolver API default would change from NCF=off to NCF=on. At this
point, any application using a low-level resolver API would have to either
a) know how to decode TTL-less responses (typically 1 line of code), or
b) explicitly tell the API to turn off the NCF flag on the query to get fat
responses, either directly (if the API supports it) or by specifying a
lower EDNS conformance level that doesn't include NCF functionality (again,
the API would need to co-operate by supporting conformance-level-setting).
Admittedly, either option requires application code changes. But how many
applications actually grovel through DNS packets as opposed to just calling
the gethostby*() routines? sendmail comes to mind. Others? Maybe a few
sniffer programs and other troubleshooting tools. With a little advance
notice, co-ordination and some careful #ifdef'ing, the "big
switch" wouldn't necessarily have to require huge code changes or loss of
application portability.

(Originally I thought application code changes would also be necessary
because of the omission of the Authority and Additional sections, but as a
result of enlightenment from the feedback on this list, plus re-review of
RFC 1035, it is now obvious to me that any RFC-conforming application must
*already* be prepared to deal with missing Authority and/or Additional
sections in response to its recursive queries).

> world a better place? Will the typical dialup or T1 user even see a

I'm thinking more of the large organizations and ISP's who are installing
DNS server farms to handle the query load, or those unfortunate non-US
users who are still paying per-byte charges to monopolistic or
pseudo-monopolistic telco's, rather than the typical dialup or T1 user on a
free-market, open network. Don't you think they would appreciate *every*
reasonable effort to curb protocol bloat? Will it make the world a better
place? As long as the gain exceeds the pain, most certainly, though
probably not in any dramatic or spectacular way. Every bit helps (well,
maybe not every *bit*, due to padding, but 4 octets per RR does :-)

Your points about spam, netnews, streaming protocols, etc. are well taken,
but why exacerbate the problem? Moreover, the argument can at least be made
that the users of the netnews/www/streaming-whatever are deriving
heightened perceived value from the additional bandwidth they are consuming
and thus volunteering to pay for the necessary infrastructure. In the case
of DNS protocol bloat, which is not known by the vast majority of users,
that argument is much weaker. In fact, because of the "invisibility" of DNS
-- the unseen costs of the transactions -- I think in many ways we (those
who have a working if not perfect understanding of the protocol) have a
sort of quasi-custodial duty to curb the bloat as much as possible on the
users' behalf: since they don't know what's being consumed, we don't have
their "permission" to consume any more than is necessary.

Your point above about the size of SIG records -- assuming that they are
large -- is quite a propos: a large part of the reason why I'm bringing up
protocol weight-reduction *now* is because I can foresee that the capacity
requirements of the upcoming new extensions are likely to cause problems.
If we (speaking collectively again) can selectively and interoperably
remove some of the old protocol baggage at the same time we add new
features, then maybe the capacity problems will be mostly averted. Not to
sound alarmist, but if DNS consumption is left to grow without bounds, what
is not a problem today could easily become one tomorrow.

- Kevin

---

From: [email-masked]
Date: Wed, 23 Feb 2000 18:16:27 +1100

Kevin,
	       this optimisation would really only come into play between
	stub resolvers and their servers.  This is normally a LAN
	connection or a couple of hops to the ISP's nameserver.  It will
	not (normally) result in savings on international links as most
	of those queries are coming from servers which do cache the results
	and do need those additional RRsets.

	I would suggest that you consider what Dan said and use RD as
	a flag bit, not worry about the ttl and just trim the RRsets that
	are not required to answer the question.  Patches welcome.

	Mark

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Feb 2000 09:17:41 -0500

Just to contribute another (vote/)opinion on the value of eliminating a few
bytes from transmitted resource records.  I've been under the impression
that the network performance is a function of number of packets rather than
the size of packets.

If the change cuts down the number of messages, then we win.

Here are some reasons why I don't think a few bytes are worth the change.:

On ethernet, there is a minimum size, so small packets would be padded
anyway.  Also, the network's "waste" time is during the collision
avoidance, not the transmission.  In this case, a few bytes here or there
aren't worth worrying about.  (I know the world isn't entirely ethernet, so
maybe this is a red herring.)

I think a more important factor is how a host accepts a packet.  An
interrupt is raised and the OS has to handle that.  Whether the packet is 2
bytes or 2 K bytes, the time to handle the packet is pretty much the same.
To some extent, this rule also applies to routers.

I won't bother to repeat the other reasons I agree with that have already
appeared in the thread.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

Opinions expressed are property of my evil twin, not my employer.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 24 Feb 2000 17:18:09 -0500

> To some extent, this rule also applies to routers.

Yes, network performance is *largely* dependent on the number of packets
rather than the number of bytes, but I believe there are also some components
which are packet-size dependent. I don't make my living as a network engineer,
but from my general knowledge of such matters, it seems to me that packet
fragmentation and reassembly is more likely with larger packets. Also, a
typical networking stack implementation does a fair number of internal buffer
copies in the course of processing network transactions, and these can be more
resource-intensive with larger packets. And it seems to me that serial and/or
point-to-point protocols like the ubiquitous PPP are going to be affected by
large packets more than "bus" protocols like Ethernet (although doesn't a
larger payload increase the chance of collisions even in an Ethernet
context?).

- Kevin

---

From: Terry Lambert <[email-masked]>
Date: Thu, 24 Feb 2000 17:22:01 -0800

Kevin Darcy wrote:
> Yes, network performance is *largely* dependent on the
> number of packets rather than the number of bytes, but
> I believe there are also some components which are
> packet-size dependent.

There are.  For one, a larger packet will hold the
carrier up longer.  There are a lot of good reasons
to want to use the same number of smaller packets, or
have smaller payload components so that the agregate
won't push you to TCP.

> I don't make my living as a network engineer, but from
> my general knowledge of such matters, it seems to me
> that packet fragmentation and reassembly is more likely
> with larger packets.

The whole path minimum MTU, not fragging, is the gating
factor on UDP packet sizes.  A lot of things, including
NAT, tend to break MTU discovery.

> Also, a typical networking stack implementation does a
> fair number of internal buffer copies in the course of
> processing network transactions, and these can be more
> resource-intensive with larger packets.

In general, most modern systems do "zero copy" transmits;
they copy once from user-to-kernel or from buffer cache
to network buffer (as in "sendfile()"), and they copy once
from the network buffer to the network adapter memory.

Some systems use references and buffer mapping so that
they can pass a reference to a buffer cache entry instead
of needing to copy the data to a seperate network buffer
(this is most common in systems with a unified VM and
buffer cache).

Fragged packet reassembly on the receiver is commonly done
using scatter-gather to only copy the data once from the
network card memory into a network (or buffer cache) buffer.

> And it seems to me that serial and/or point-to-point
> protocols like the ubiquitous PPP are going to be affected
> by large packets more than "bus" protocols like Ethernet
> (although doesn't a larger payload increase the chance of
> collisions even in an Ethernet context?).

PPP usually has a smaller MTU, but as a general rule, it is
high enough for a 512b UDP packet plus headers.  We should
note now that this is more a client resolver issue than it
is a server issue, since servers are unlikely to be on the
other side of transient connections, and it would be very
hard for a server on the other side of a transient connection
to be authoritative, even under the best of circumstances.

I think we all acknowledge that if you had smaller bits of
data, you'd be better of than if you had larger bits of
data.  We don't need to reach for examples that end up
being straw men; if we set up straw men to be knocked down,
we risk the legitimate reasons for keeping packets small
being tarred with the same brush.

As far as the current argument goes, I think it would be a
good idea if we could notify the server to not send us stuff
we are going to discard.  By the same token, it's not a good
idea to break interoperability.

I'd like to see a clarification on options for implicit
negotiation, such that the responding server is permitted
to treat all unknown option bits as zeros.  Without that
basis, I think even the currently drafted non-zero bits
could legitimately result in undefined behaviour.  It only
makes sense to add the "don't send me this crap" bit after
you've defined a way for down-rev servers to ignore your
request because they can't satisfy it.

-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- [email-masked]
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 24 Feb 2000 18:58:31 -0800

> idea to break interoperability.

That's my opinion as well.

Personally, I also think it would be an extremely useful for CDPD and
other media that are both lossy and expensive. It would not be extremely
useful on LANs, and could actually be harmful in some situations. But as
an option that must be implemented to be used, no harm should fall to
devices that don't use it.

I would think that the first step would be to have some sort of proof
that somebody will actually use this feature. If so, I see no reason not
to do it. But if not, then I see no reason to waste time on it.

It would also seem to be prudent to show that a significant number of
products would implement such a feature. If only one client (or only one
server) supports it, then that wouldn't be very compelling either.

-- 
Eric A. Hall                                            [email-masked]
+1-650-685-0557                                    http://www.ehsco.com

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Feb 2000 21:50:16 -0500

>larger payload increase the chance of collisions even in an Ethernet

Not with carrier sensing, per se, although a longer packet transmission
increases the expected number of waiting stations ready to participate in
the next round of competition for the channel.  I guess you could say this
is an increase in collisions.

This is getting a bit far afield now.

IMHO, saving a few bytes in the envelope isn't really worth it.  We've
already discarded local compression because the WG judged the savings
weren't worth the effort.

Saving bytes by "stifling" the sending of certain types of SIG records is
another matter.  See the following link for the draft.  Eliminating SIG
records gives more bang for the (insert local currency reference here).

 http://www.ietf.org/internet-drafts/draft-ietf-dnsind-sigalgopt-00.txt.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 24 Feb 2000 22:19:45 -0500

>         and do need those additional RRsets.

Such generalizations are iffy. Yes, what you say may be true of
*most* Internet arrangements and *most* intranet architectures, but our
intranet, for one, has many stub resolvers sending their queries over
WAN links -- in many cases *international* WAN links -- because local
DNS servers are not cost-justified for the location.

As they say in the automotive business and elsewhere: Your Mileage May Vary.

>         are not required to answer the question.  Patches welcome.

RD is a rough approximation. RD queries can come from downstream
selective-forwarders who may be able to put Authority and/or Additional data
to good use: by omitting Authority and Additional in that case, you are
causing them to generate extra queries over the long haul. Nevertheless,
trimming responses to RD queries optimizes for the general case, which is a
Good Thing, and I'll see what I can do about producing a patch (BIND 8 or BIND
9? #ifdef'ed or not?).

The TTL field constitutes 28% of an A RR's size, less for other
fixed-RDATA-size types, and possibly more for records where the RDATA consists
of only a compressed label. Together with the class field, we're talking 42%,
plus or minus. That's the level of potential "gain" we're talking about here
(although Jim Reid's comment about 4 octets being a drop in the bucket
compared to the size of SIG records is of course salient).

As for "pain", my initial performance trials indicate a 16%/4%/12% *savings*
for NCF in user/system/overall CPU time, but the modified named was omitting
Authority and Additional sections for many if not most of the queries (the
simulator set NCF only for recursive A and PTR queries -- the kind of queries
mostly likely to originate from high-level resolver calls -- which constituted
72% of the total query volume, but that figure needs to be offset by some
as-yet-unknown percentage of queries which received referrals, containing
Authority and Additional sections). I'll run some more trials between a
"section-trimming" BIND and "full NCF" -- including, I think, class-field
omission as well as TTL-field omission -- and see how the numbers turn out.
BIND patch or no BIND patch, I don't know that I'm ready to abandon full
field-omitting optimization just yet. There's still a lot of resources to be
saved.

- Kevin