Re: Transport requirements for DNS-like protocols

[Dave Crocker <[e-mail]>]

At 11:41 PM 6/27/2002 -0400, Rob Austein wrote:
>   Basic engineering paranoia suggests
>that we should continue looking at candidate lightweight transport
>protocols for DNS, in the hope of eliminating this risk.

This strikes me as a compelling point.  A lesson from the Arpanet that 
drove the reliability mechanisms for TCP was that networks aren't as 
reliable as they promise to be.  In the case of DNS, having such a critical 
bit of service be so fragile to network conditions certainly seems dangerous.


At 03:34 PM 6/28/2002 -0400, Rob Austein wrote:
>I suspect that the community lacks consensus on whether one should
>count by packets or count by bytes.

As I recall, the byte count mechanism was chosen for TCP to permit 
underlying layers to package portions of the TCP segment, according to the 
MTU variances.  So TCP would not have to worry about underlying datagram 
sizes.  From a practical standpoint, do we still have that concern in the 
Internet?


> > Ok, this and the rest of the paragraphs assume IP fragmentation. The
> > question I have is this: ... If you
> > just don't _do_ packet level retransmission then congestion control
> > becomes a non-issue.
>
>Multiple IP packets sent all at once == congestion issues, even if
>those multiple packets are really just fragments of a single packet.

On the other hand, the natural clumping of packets into packet trains 
suggests that quickly sending a *small* number of IP datagrams together -- 
such as for an extended transaction unit -- might not be all that bad.


>I think the theory behind preferring IP level fragmentation over
>having the application do the same thing is that the latter guarentees
>fragmentation while the former only risks it.

The non-determinacy is the problem.  Also the fact that IP fragmentation is 
basically a problem-recovery mechanism.


>  That is, even in the
>absence of PMTU discovery, there is still a chance that a larger than
>minimum IP packet might still make it through the net unfragmented.

But the fact that it might not is the problem.


>Also note that (in IPv4) fragmentation can happen anywhere along the
>path.  Thus, if (count by packets) congestion is a problem near the
>server but one can keep the local MTU high on the links nearest the
>server, one can defer fragmentation until the response packet is
>closer to its destination.

However nothing in Internet technology makes it comfortable to require or 
detect particular client/server topologies.


>Having just recently had to explain to a bunch of nontechnical folks
>that the magic number thirteen in the sentence "the thirteen root name
>servers" derives, ultimately, from the hardwired 512 byte message size
>specified in RFC 1035, you will understand that I would prefer not to
>repeat this particular mistake (I'd rather make new ones...).

Perhaps the way to avoid this mistake is to make DNS use a transport 
protocol that does not rely on the size of the underlying packets.  The 
easiest way to do this is a thin layer ON TOP of UDP, that strings them 
together.

Whether selective retransmission of individual UDP datagrams is a 
requirement becomes the question.  Without it, we remain reliant on a 
mostly-reliable network.  That's pretty fragile, in spite of how well it 
has worked for so long.

However to add selective retransmission requires that the server 'assemble' 
the DNS query and acknowledge its parts selectively.  Hence the server 
becomes statement.

Mumble.


As to the matter of server side processing of the content, such as 
canonicalization of strings, the kinds of things being discussed on this 
thread strike me as similar to spelling correction, rather than upper/lower 
case mapping.  That is, there is a degree of heuristic to the processing 
and there is likely to be significant disagreement about the efficacy.  By 
contrast, matching upper/lower case strings is well and long established 
outside of computing.  (In fact, the computing world is the only place I 
have seen the strange behavior of treating to strings different if they 
only vary in case.)

d/


----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]


----------
Dave Crocker <mailto:[e-mail]>
TribalWise, Inc. <http://www.tribalwise.com>
tel [phone]; fax [phone]