Subject: Re: draft-dnsext-edns1-04.txt

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Sep 2002 08:37:35 +0000

> If the caching system is hopelessly screwed and we need to do
> something else to let the application forcibly optimize the query
> process, I think that EDNS1 is the right "something else" to pursue.
> 
> However, since the available evidence to date has not convinced me
> that the caching system is hopelessly screwed, I'd rather just let the
> caching system do its thing and avoid another nontrivial protocol
> change while we're trying to finish DNSSEC.
> 
> Not blaming anybody for the lack of hard evidence or running down
> Paul's EDNS1 proposal, BTW, just trying to answer Paul's implied
> question.

i think kre's analysis applies here, so i won't repeat it, but i will
put in my own two bits.  caching, specifically negative caching, can
speed up the total dns transaction time and thus cut down the interval
between "when you know where you want to go" and "when you can initiate
your session".  this is critical for overall "internet" performance,
perhaps more significant than the bits per second per flow will be in
the average case.

i won't quibble about the lack of negative caching deployment, since
EDNS1 would have a similar deployment mountain to climb.

however, the cost of a cache miss will be higher with two full round
trips from the intermediate server to the authority server than it is
with one.  if we expect AAAA and A, or MX and A, or all three, to be a
common query pattern in the future, and if we expect any diversity among
query patterns (such that some clients might query in one order while
others query in some other order), then new successful flows will remain
expensive due to the (positive) cache misses and new error flows will
remain expensive due to the (negative) cache misses.  forever.

i see multiple queries as (1) an intended part of the original
architecture which was left underspecified, and (2) a necessary feature
in the long run if we don't want dns to remain a significant part of our
total transaction or session initiation times.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>