Subject: RE: Transport requirements for DNS-like protocols
From: John C Klensin <[email-masked]>
To: Patrik Fältström <[email-masked]>, Nicolas Popp <[email-masked]>, 'Michael Mealling' <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]
Date: Sun, 30 Jun 2002 21:14:02 -0400
List-Id: <ietf-irnss.lists.elistx.com>

--On Saturday, June 29, 2002 10:11 AM +0200 Patrik Fältström
<[email-masked]> wrote:

> --On 2002-06-28 10.24 -0700 Nicolas Popp <[email-masked]>
> wrote:
> 
>> As soon as you do fuzzy matching that forces you to retrieve
>> multiple records and rank them, the operational complexity is
>> increased ten-fold (and your query response time becomes way
>> more inpredictable unless you do a few "right things").
> 
> Doing fuzzy-matching is most efficiently done by doing a
> calculation of a hash on the search string (something like
> soundex) and then exact mathing in the database.
> 
> So, fuzzy-matching is for me just another version of
> "preparation" of the search string.

Patrik,

In a number of areas, matching by distance function --i.e.,
knowing all of the things that might match and determining which
one(s) are closest-- has turned out to be much more useful than
matching on a canonical form.  In one of the classic examples,
the first-generation theory of how to do OCR was to try to
standardize ("prepare" in your terminology) characters,
font-independent, down to a common abstraction.  Nice idea, but
it basically didn't work.  Instead, we now assume (with English)
that a given character has to match one of 62, and make a
tentative decision based on similarity functions.  Then we
repeat the process, looking up word-candidates in a dictionary
to see which candidates can be excluded because they are
uncommon in, or absent from, the language.

Sonex/ soundex matches are fuzzy matching, but they are not
fuzzy search; I think that fuzzy search is going to be needed
here.

So, I hope you are right -- it would be a lot easier.  But...

     john

Date: Sat, 29 Jun 2002 21:25:05 -0700
From: Dave Crocker <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Michael Mealling <[email-masked]>
Cc: [email-masked]

At 11:04 PM 6/29/2002 -0400, Michael Mealling wrote:
>The proposal I've been toying with was to limit the number of packets
>in the train to some number equating to *small*. Anything above that
>is responded to with a "I'm sorry but the response is on the order of
>a file stransfer instead of a simple response so please requery via TCP".

interesting idea.

>But sans some hard network testing across variously connected parts of
>the network I have no idea how to come up with that number.

worse, today's statistics don't necessarily predict tomorrow's.

>Yes. The fact that fragmentation is the exception rather than the rule
>means that the context switching required during the probable situation
>that the router is 'stressed' suggests that the large UDP packet solution
>is relying on the network feature most likely to fail instead of most
>likely to succeed.

Also it is bad in the receiving host.  With IP fragmentation, the fragment 
is held down in the IP layer, consuming a network buffer.

>  We have good evidence that UDP packets smaller than
>512 bytes succeed at a high rate. IMHO, we should optimize to what will
>succeed rather than what is an error correction.

exactly.  for all of the processing efficiencies of larger packets, quick 
DNS-like transactions might be the place to bias towards smaller chunks.

> > >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.
>
>Correct. Its the recovery from the dropped fragments that causes additional
>network impact and increased delay due to timeouts for the user.

With a dropped fragment, the entire IP datagram must be resent.  An 
application-level, selective-retransmission scheme does not incur that.

Still, there is the minor issue of retaining state in the server application.

> > 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.
>
>Beyond a simple sequence number and possible checksum in the first octet,
>would anything else be needed. The only thing I can think of is
>some additional octet in the first packet indicating the total number
>of packets sent.

Sounds about right.  The issue is not designing such a mechanism.  It's the 
impact on the servers that I would guess to be the major issue.

> > However to add selective retransmission requires that the server 
> 'assemble'
> > the DNS query and acknowledge its parts selectively.  Hence the server
> > becomes statement.
>
>And increases server demands to the point that a cost of a truly reliable
>connect becomes the optimal solution, when in truth it ends up being
>overkill.

Not if we are faced with a true requirement for larger application data 
units, as it seems we are (and, frankly, have been for a number of years.)

The debate is how to provide those larger transaction units, not whether.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

Date: Sat, 29 Jun 2002 23:04:26 -0400
From: Michael Mealling <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Dave Crocker <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]
Reply-to: Michael Mealling <[email-masked]>

On Sat, Jun 29, 2002 at 12:47:53PM -0700, Dave Crocker wrote:
> At 03:34 PM 6/28/2002 -0400, Rob Austein wrote:
> >> 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.

The proposal I've been toying with was to limit the number of packets
in the train to some number equating to *small*. Anything above that
is responded to with a "I'm sorry but the response is on the order of 
a file stransfer instead of a simple response so please requery via TCP". 
But sans some hard network testing across variously connected parts of 
the network I have no idea how to come up with that number.

> >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.

Yes. The fact that fragmentation is the exception rather than the rule
means that the context switching required during the probable situation
that the router is 'stressed' suggests that the large UDP packet solution 
is relying on the network feature most likely to fail instead of most 
likely to succeed. We have good evidence that UDP packets smaller than
512 bytes succeed at a high rate. IMHO, we should optimize to what will 
succeed rather than what is an error correction.

> >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.

Correct. Its the recovery from the dropped fragments that causes additional
network impact and increased delay due to timeouts for the user.

> >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.

Or rely on the fact that the hops closest to the destination may in fact
be the more incapable. Especially in the case of firewalls and NAT boxes
in the vicinity of the client.

> >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.

Beyond a simple sequence number and possible checksum in the first octet,
would anything else be needed. The only thing I can think of is
some additional octet in the first packet indicating the total number
of packets sent.

> 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.

But in the case where requerying is so cheap for the server it actually
becomes the best optimization for performance on both ends.

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

And increases server demands to the point that a cost of a truly reliable
connect becomes the optimal solution, when in truth it ends up being
overkill.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Sat, 29 Jun 2002 10:29:58 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Cc: Nicolas Popp <[email-masked]>, 'Michael Mealling' <[email-masked]>, John C Klensin <[email-masked]>, Rob Austein <[email-masked]>, [email-masked], [email-masked]

Granted, this mess began with shady characters, but that isn't the exclusive
scope of a blob-o-gop-in-dns-record-out thing-above-transport. Besides, I've
been warned off of attempting to improve characters as that is a well-solved
problem.

Here is one representation of spatial data. It contains in-fix dots, and
three characters not in the LDH set, and there are applications that can
benefit from inexact match. Here "o" serves for U+00B0, "degree", UTC3.0,
and the leading tab is for clarity.

	29o46'59.63940"N
	95o34'46.23606"W
	-11.380m

Here is another representation of spatial data, this time from iso6709,
again with a leading tab for clairity. Altitude is the (optional) 3rd datum.

	+40-075/
	+401213.1-0750015.1+2.79/
	+40.20361-075.00417/

Again, in-fix dots, and two characters not in the LDH repitoire.

So, blob-o-glop is a coordinate system reference, e.g., the weather
sensor complex at 44o16'N, 71o18'W, 2,000m, (Mt. Washington, NH, US),
and "fuzzy" has some algorithmic expression e.g., 1'/1'/Km.

What I'd like, is for a something-above-dns not to be over-constrained
to be "language", nor harmed by non-generic problem domain issues.

The LDH limit exists, extensions to it can be mapped to it, and lookups,
as well as searches, may be attempted using the LDH-mapped thingee that
isn't LDH-constrained.

Personally, I'd go for adding "+" to LDH, but I lost my sense of humor
some time earlier.

Cheers,
Eric

Date: Sat, 29 Jun 2002 12:47:53 -0700
From: Dave Crocker <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Rob Austein <[email-masked]>
Cc: [email-masked]

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:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

Date: Sat, 29 Jun 2002 10:11:15 +0200
From: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Subject: RE: Transport requirements for DNS-like protocols
To: Nicolas Popp <[email-masked]>, 'Michael Mealling' <[email-masked]>, John C Klensin <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]

--On 2002-06-28 10.24 -0700 Nicolas Popp <[email-masked]> wrote:

> As soon as you do fuzzy matching that forces you to retrieve
> multiple records and rank them, the operational complexity is increased
> ten-fold (and your query response time becomes way more inpredictable
> unless you do a few "right things").

Doing fuzzy-matching is most efficiently done by doing a calculation of a
hash on the search string (something like soundex) and then exact mathing
in the database.

So, fuzzy-matching is for me just another version of "preparation" of the
search string.

    paf

Date: Fri, 28 Jun 2002 18:49:48 -0400
From: John C Klensin <[email-masked]>
Subject: dns-search: draft section 3.6.2 on caching
To: [email-masked]

Hi.  The text that follows is the current draft of section 3.6.2
of the new dns-search document (section numbers correspond to
those of the draft-klensin-dns-search-03.txt, now in the
archives).

It reflects parts of today's discussion as well as some earlier
text.

Comments welcome up to late Sunday US EDT, at which time the
document will go into the I-D posting process (and I'll try to
post an FTP location for those who are impatient).

    john

--------------------------------------------

3.6.2 The cache model

The model proposed here is ultimately one of "searching" --
finding a resource in a way that may involve some interaction
between the various databases and the user.  It differs from the
"search engine" approach because the databases are intentionally
populated (not unlike the DNS although syntax and semantics are
different) and the searches are highly structured.  In the
"search engines", the databases are largely populated by
automated processes that walk through the Internet (or the web)
picking up data of possible interest.  And the queries use, at
most, boolean conditions, not a structured, faceted,
architecture.  The obvious advantage of a search technique of
this sort is that it should have good odds of permitting owners
or operators of resources who wish those resources to be found
to have them efficiently found by those who are looking for
them.  But it is unlikely that the process can be made as fast
or resource-minimizing as a DNS lookup where the fully-qualified
domain name is already known.

At the same time, the nature of the systems being proposed makes
it likely that a user will think of a particular resource (or
its location) in terms of the terminology used to find it.  And,
especially if the user needs to be involved in the search and
resolution process to identify a resource (or resources) of
interest from among those that match a set of facets, users will
not tolerate having to go through the process on every
reference.  The combination of these factors makes it almost
essential that it be possible to maintain a local table of
references and targets (in DNS or URL terms) so that additional
references soon after the first can be used by protocols to
directly access recently-used targets without having to go
through the search and resolution process each time.

Even "soon" may be quite different from our experience with the
DNS. With the DNS, the resources bound to names are typically IP
addresses or something similar, and these change frequently
enough, often on short notice, that "time to live" (TTL) values
are typically short, rarely more than a day.  By contrast, the
faceted name of a sublayer two search is likely to represent a
fairly long-lived relationship with the DNS names and URLs that
it identifies.  Clearly, it should be convenient for the user to
reinitiate the search when that is obviously needed (e.g., if a
target goes bad) but TTLs for ordinary refreshing of a search
will, in most cases, be set closer to the order of weeks than to
minutes or hours, with the DNS taking responsibility for the
volatile portion of the references, as it does today.

A facility similar to this is provided for web browsers by the
common "bookmarks" or "favorites" functions, but those do not
support the functionality that will be necessary for caching
operations in this sublayer two search environment.

The sublayer two search entries ("bookmarks" or "favorites" if
it is useful to think of them that way) can be thought of as a
local cache of queries and responses with sufficient information
to both immediately locate a target associated with the user's
perception of what was looked for and of "refreshing" the search
if circumstances changed or values timed out.  In the presence
of a particular query, a client system would presumably check
for a matching bookmark.  If one was not found, the layer two
search would be performed, yielding values that might require
user intervention for selection.  Once selected, the search, the
full set of facets returned, the DNS names or URIs, and any TTL
information would be stored (possibly using a user-supplied name
or tag) and the resource accessed via the appropriate DNS name
or URI.  If the search or tag was found in the cache, checks
would be made for the values being current and then the DNS name
or URI used directly, without going back through the search
procedure.

One useful consequence of this is that the number of queries to
the database will be roughly proportionate to the number of new
inquiries by the user (increased by the impact of TTL timeout
and user-initiated repeated search.  That number should be much
smaller, and hence imply significantly less load, than
per-reference DNS queries.

Date: Fri, 28 Jun 2002 15:34:04 -0400
From: Rob Austein <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: [email-masked]
Reply-to: Rob Austein <[email-masked]>

At Fri, 28 Jun 2002 09:47:02 -0400, Michael Mealling wrote:
> On Thu, Jun 27, 2002 at 11:41:33PM -0400, Rob Austein wrote:
> 
> > b) The idempotence of normal DNS queries, and the relatively small
> >    amount of work that a DNS server has to do in order to process a
> >    normal query.
> 
> Which is something any designer of a Layer 2 service should keep in mind.

Yes.  As others have suggested, the key word here is "relative": that
is, what one has to look at is the cost of re-running the query versus
the full cost of buffering the answer for retransmission.  My notion
of the "full" cost of retransmission is probably a bit skewed from
what most people think about, due to having spent most of a decade
writing embedded protocol stacks designed to run on bare silicon
(kernel?  we don't need no stinkeen kernel...).

> > c) The relatively low probability that any particular DNS response
> >    message will be dropped by the network.
> 
> Is this due to its size? I.e. can that be re-written as:
> 
>  c) The relatively low probability that any particular 512 byte UDP packet
>     will be dropped by the network.

I suspect that the community lacks consensus on whether one should
count by packets or count by bytes.  No doubt the real answer is
somewhere in between.  I tend to count by packets on the theory that
router packet buffers and CPU time are more often a bottleneck than
the number of bits one can shove down a pipe, but that begs the
question of whether one should build that assumption into protocols.

> Ok, this and the rest of the paragraphs assume IP fragmentation. The
> question I have is this: since there is no congestion control at the
> IP layer for fragments, and IP fragmentation seems to be acceptable, 
> why not do it at the application layer? Limit the packet size to the
> minimum MTU for that network and don't do retransmission of packets.
> I'm not a transport guru but it seems that all of the congestion
> control issues come about because of packet retransmission. 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.
Sorry.  This is where I ran into trouble with my NETBLT-like
suggestion a few years ago.

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.  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.
Note that the EDNS0 size mechanism is really just a statement by the
client to the server that the client would like the server to risk
sending a reply up to size N.

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.  IPv6 fragmentation doesn't work this way,
I haven't yet figured out whether that's a serious problem.

Finally, note that there are really two different magic numbers that
often get confused: the MTU, and the reassembly buffer size.  If the
network isn't dropping fragments, the MTU is (almost) irrelevant, what
matters is whether the receiver can reassemble the frags upon receipt.
If the network is lossy, however, and if the lossiness is somehow
proportional to the number of packets in flight, MTU issues become
much more important.

If you haven't already done so, I recommend reading the Jacobson &
Karels 1988 SIGCOMM paper on congestion control and avoidance:

  http://www-nrg.ee.lbl.gov/papers/congavoid.pdf

Figuring out how it applies to things like IP fragmentation takes some
work, but the basic congestion issues almost certainly apply, even if
the specific techniques for overcoming them don't.

> In other words, instead of negotiating packet size in the first packet,
> have it hardwired to 512 bytes but send multiple packets with
> simple sequence numbers so the application can just piece 'em back
> together. If it fails you can retry the query via TCP (or UDP
> if you feel it might work the second time). But you never ask for individual 
> packets to be retransmitted, and you never ACK. 
> 
> Its the same network profile as IP fragmentation but with a much
> better chance of success at greater than 1500 byte message sizes.

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...).

> > In the long term, if we ever get a real white pages protocol and
> > people stop caring about having cute DNS names, we're still going to
> > need an underlying system for associating long-term identifiers with
> > IP addresses.  At a technical level, such a system will probably look
> > an awful lot like the DNS, but perhaps it'll be sufficently
> > decentralized that a reliable transport protocol wouldn't be such a
> > burden on the servers.
> 
> Awfully prescient!

Can't take full credit, I came to this conclusion by standing on the
toes of others (including John Klensin).  Sadly, all of us who have
been thinking this way for much of the last decade have found that it
is much easier to predict that water which is demonstrably running
downhill will eventually reach bottom than it is to build a pump.

Date: Fri, 28 Jun 2002 13:55:35 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: John C Klensin <[email-masked]>
Cc: Eric Brunner-Williams in Portland Maine <[email-masked]>, Rob Austein <[email-masked]>, [email-masked], [email-masked]

> To the extent to which I have a voice here, I don't want to
> waste time on "on topic" versus "off topic" discussions. ...

I got my money's worth from Rob's note. draft-mumble-epp-udp-checkmate
in another wg not entirely proximal.

We're teetering on the edge of farce, or bathos (IDN), but this note from
Patrik reminded me of an old i18n-haha [1]:

> We make the problem easier to solve if we have the ability to inside the
> protocol do ...
>    ... 
>  - Split the query load on more than one server, so the query
>    load can be shared (which imply that the server should not
>    keep state -- if at all possible)

So there was this big spindle set project that AT&T and NCR did, with
lots of go-fast and partition and dependency-removal and ... and more
go-fast.

To internationalize the app running on this wicked fast spindle farm,
all the US stuff went on the "U" spindle, all the GB stuff went on the
"G" spindle, all the FR stuff went on the "F" spindle, ...

It honked. So long as the data was in English. The Spanish data put the
US data on the E spindle.

Well, I thought it was funny. Estadios Unidos [2].

Eric

[1] Unicode shindig, Don Knuth (Stanford) keynote speaker, early 90's, in
    San Jose. It was a guy from Xerox who I recall telling the story.

See, not everything associated with the UTC is inherently evil, colonial,
or humorless, and they probably played only a minor role in the management
of Xerox.

[2] Which someone's Principle of Least Astonishment requires be expressed
    as "US", and with a straight face, to be consistent with iso3166.

Date: Fri, 28 Jun 2002 13:51:31 -0400
From: John C Klensin <[email-masked]>
Subject: RE: Transport requirements for DNS-like protocols
To: Nicolas Popp <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]

Nico,

A few observations here.   Let me stress that I'm trying to keep
an open mind on some of these issues, so am less positive about
my statements of my positions than I might otherwise be.

--On Friday, 28 June, 2002 10:24 -0700 Nicolas Popp
<[email-masked]> wrote:

> On the client versus server discusssion, I strongly disagree
> with any approach that requires pre-processing on the client,
> even localization / normalization type of processing. John has
> already emphasized some of the main advantages to putting the
> IRNSS smart on the server side. I would add to that the issue
> of writing, maintaining and pushing new client codes which
> over time becomes a huge penalty that our design should
> minimize if not preclude, especially if we want to make IRNSS
> real in our lifetime (I would have hoped that the slowness of
> IDNA deployment had made it clear by now). 

I think this is exactly correct.   Doing things server-side also
reduces the need to negotiate with each client vendor
separately, and you can probably give the rest of us lessons on
the difficulties of such strategies.

That said, part of the language I've been trying to use has been
fairly careful to preserve the option of various mixed
strategies.   For example, as some of you know, I think that
some clients (like 3G cellphones) are going to end up doing IDNA
by either sending whatever the user keys in to intermediate
servers that, in turn, do the nameprep and other IDNA
operations, then query the DNS.   I don't find anything in the
present IDNA spec that prohibits that strategy.    More
generally, I can imagine a search layer two implementation in
which a client, given a faceted query:

	(i) Passes the raw form of the query, whatever that
	means, off to a _generic_ server that canonicalizes it
	into standard form(whatever _that_ means) and returns
	the result.  Note that this server would not need access
	to the database of registered entries and so could be
	replicated and distributed as much as needed.
	
	(ii) Consults a cache database that is user-specific but
	possibly on some server somewhere rather than
	client-local, and returns either a result or a failure
	indication.
	
	(iii) If results are not in the cache, consults the
	IRNSS server using the canonical form and a full set of
	facets.
	
	(iv) Caches the results, by storing back to that
	user-specific cache.
	
	(v) Takes the URL and does its thing.

I think that is more or less the right order.  Verification of
signed data records (or equivalent) and authentication to the
cache might imply additional steps.  But the important thing is
that this is an "almost everything on the server" model without
"big load on the database servers".    Intuitively, it has a lot
of appeal.

> Also note that the name-string pre-processing (normalization
> and so forth) which is CPU bound is relatively cheap on the
> server side (more importantly highly predictable so that you
> can adjust your number of servers to query rates). What is
> always much much much more costly is records lookup form the
> data store. As soon as you do fuzzy matching that forces you
> to retrieve multiple records and rank them, the operational
> complexity is increased ten-fold (and your query response time
> becomes way more inpredictable unless you do a few "right
> things"). At that point, the string pre-processing time
> becomes relatively irrelevant and you may as well go all the
> way and do everything on the server side. That way, your
> client libraries are trivial to develop and maintain across OS
> platforms, client application and devices.

Yes.  The question is whether we can take the load.  And, given
the advantages of highly-optimized database search engines, it
still might make sense to split things up a bit.   Another
advantage of the sort of split above is that the client has
access to _all_ of the forms of a name, the queries, and the
response.  For what I would consider a well-written client, that
implies the ability to return error messages that include the
user-provided name as well as more specific information.  I can
easily imagine other schemes requiring a good deal of complexity
to avoid returning the equivalent of 
    not found - <some ACE-ish gibberish>
and no other information.

> On the other hand, I agree that we should design IRNSS with
> server-side optimizations in mind (such as data set
> distribution, caching strategies and stateless servers...).
> 
> Lastly, operations wise, don't you think that an IRNSS name
> service will be closer to a search engine than DNS? In fact, I
> would anticipate that most of the traffic will still be repeat
> traffic using straight layer 1 identifiers.

Partially yes to the first -- it depends a bit on what you mean
by "search engine", and I would have said "standard database
seach" instead.  To the second, I think also yes, which is why
really smart caching strategies are going to be very important.

      john

Date: Fri, 28 Jun 2002 10:24:55 -0700
From: Nicolas Popp <[email-masked]>
Subject: RE: Transport requirements for DNS-like protocols
To: 'Michael Mealling' <[email-masked]>, John C Klensin <[email-masked]>
Cc: =?iso-8859-1?Q?Patrik_Fältström?= <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]

On the client versus server discusssion, I strongly disagree with any
approach that requires pre-processing on the client, even localization /
normalization type of processing. John has already emphasized some of the
main advantages to putting the IRNSS smart on the server side. I would add
to that the issue of writing, maintaining and pushing new client codes which
over time becomes a huge penalty that our design should minimize if not
preclude, especially if we want to make IRNSS real in our lifetime (I would
have hoped that the slowness of IDNA deployment had made it clear by now). 

Also note that the name-string pre-processing (normalization and so forth)
which is CPU bound is relatively cheap on the server side (more importantly
highly predictable so that you can adjust your number of servers to query
rates). What is always much much much more costly is records lookup form the
data store. As soon as you do fuzzy matching that forces you to retrieve
multiple records and rank them, the operational complexity is increased
ten-fold (and your query response time becomes way more inpredictable unless
you do a few "right things"). At that point, the string pre-processing time
becomes relatively irrelevant and you may as well go all the way and do
everything on the server side. That way, your client libraries are trivial
to develop and maintain across OS platforms, client application and devices.

On the other hand, I agree that we should design IRNSS with  server-side
optimizations in mind (such as data set distribution, caching strategies and
stateless servers...).

Lastly, operations wise, don't you think that an IRNSS name service will be
closer to a search engine than DNS? In fact, I would anticipate that most of
the traffic will still be repeat traffic using straight layer 1 identifiers.

-Nico

-----Original Message-----
From: Michael Mealling [mailto:[email-masked]]
Sent: Friday, June 28, 2002 7:05 AM
To: John C Klensin
Cc: Patrik Fältström; Rob Austein; [email-masked]
Subject: Re: Transport requirements for DNS-like protocols

On Fri, Jun 28, 2002 at 09:29:13AM -0400, John C Klensin wrote:
> (Note to readers of this list other than Patrik and Rob...
> Patrik has raised, in conjunction with this "transport
> requirements" discussion, a rather fundamental design issue.

Very fundamental and very important, especially if you ever aspire
to running something even a fraction of the size of ".com"....

>

Date: Fri, 28 Jun 2002 16:49:25 +0200
From: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Michael Mealling <[email-masked]>, John C Klensin <[email-masked]>
Cc: Michael Mealling <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]

--On 2002-06-28 10.17 -0400 Michael Mealling <[email-masked]> wrote:

> I don't necessarily
> agree with his conclusion concerning where normalization occurs and
> when/where you do byte-level comparison since they are specifically
> concerned with DNS and IDN.

Bringing up IDN as an example was stupid. Let's forget that example. We
just end up discussing IDN...

   paf

Date: Fri, 28 Jun 2002 10:49:28 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]

Exactly.
    john

--On Friday, 28 June, 2002 16:30 +0200 Patrik Fältström
<[email-masked]> wrote:

> --On 2002-06-28 09.29 -0400 John C Klensin <[email-masked]>
> wrote:
> 
>> If one can keep the operations sufficiently simple
>> (e.g., no profiles and few or none of the constraints you are
>> concerned about), there are very significant advantages to
>> server-side operations, particularly to interoperability,
>> getting things right, and being able to do upgrades/ changes
>> in a rational way.
> 
> Agreed. And, another reason why one want to do more
> calculations on the server side is because differentiation
> between services. I.e. if we look at systems which does not
> work like the DNS (where koherence is extremely important, and
> together with caching create a very very special constrain),
> we can allow different servers to do different things. Some
> servers should be able to be "better" for chemistry than
> others.
> 
> So, I would like to see something where both server and client
> side can do good things, because at the end the user using the
> client want to have "correct" results back.
> 
> My point with saving CPU in the server is just because too
> many don't think about the fact that a server can not spend
> more time on a query than the time between queries. Yes, via
> parallell threads in the server this is possible, but only to
> a certain degree. The server need to at least get rid of
> responses in the same speed new queries are coming in.
> 
> Now, this create problem if we mix "large data sets" with
> "many queries".
> 
> We make the problem easier to solve if we have the ability to
> inside the protocol do things which DNS can not handle:
> 
>  - Split one dataset on more than one server, so the dataset
> can    always be arbitrary small (a zone in DNS is a zone...is
> a zone)
> 
>  - Split the query load on more than one server, so the query
>    load can be shared (which imply that the server should not
>    keep state -- if at all possible)
> 
> With simple things like this, we will get much easier
> operations than what we have today in many protocols (DHCP,
> DNS etc).
> 
>    paf
> 
> 
>  

Date: Fri, 28 Jun 2002 16:30:14 +0200
From: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: John C Klensin <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]

--On 2002-06-28 09.29 -0400 John C Klensin <[email-masked]> wrote:

> If one can keep the operations sufficiently simple
> (e.g., no profiles and few or none of the constraints you are
> concerned about), there are very significant advantages to
> server-side operations, particularly to interoperability,
> getting things right, and being able to do upgrades/ changes in
> a rational way.

Agreed. And, another reason why one want to do more calculations on the
server side is because differentiation between services. I.e. if we look at
systems which does not work like the DNS (where koherence is extremely
important, and together with caching create a very very special constrain),
we can allow different servers to do different things. Some servers should
be able to be "better" for chemistry than others.

So, I would like to see something where both server and client side can do
good things, because at the end the user using the client want to have
"correct" results back.

My point with saving CPU in the server is just because too many don't think
about the fact that a server can not spend more time on a query than the
time between queries. Yes, via parallell threads in the server this is
possible, but only to a certain degree. The server need to at least get rid
of responses in the same speed new queries are coming in.

Now, this create problem if we mix "large data sets" with "many queries".

We make the problem easier to solve if we have the ability to inside the
protocol do things which DNS can not handle:

 - Split one dataset on more than one server, so the dataset can
   always be arbitrary small (a zone in DNS is a zone...is a zone)

 - Split the query load on more than one server, so the query
   load can be shared (which imply that the server should not
   keep state -- if at all possible)

With simple things like this, we will get much easier operations than what
we have today in many protocols (DHCP, DNS etc).

   paf

Date: Fri, 28 Jun 2002 10:40:06 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Eric Brunner-Williams in Portland Maine <[email-masked]>, Rob Austein <[email-masked]>
Cc: [email-masked]

--On Friday, 28 June, 2002 10:25 -0400 Eric Brunner-Williams in
Portland Maine <[email-masked]> wrote:

>> It could be construed as off-topic for ...
> 
> I wouldn't say its off topic. Then again, there may be several
> topics that resemble "transport requirements".

Rob, Eric, Michael, and others,

To the extent to which I have a voice here, I don't want to
waste time on "on topic" versus "off topic" discussions.  As the
last few notes have again made clear (at least to me), we are
still at the stage of asking rather basic questions about the
nature of this approach.   They are questions I would have
preferred to have gotten to many months ago, but so it goes...
they are clearly important.  The question of client-side versus
server-side functions and what can reasonably be transported and
how are, it seems to be, to be absolutely critical.  And if some
of you/us believe that teasing out transport details is useful
to making those decisions, or even to getting to how to think
about those decisions, I think it is on-topic, and probably in
the critical path.

For whatever it is worth, one of the main reasons I haven't
tried to turn "dns-role" into a protocol specification is
because I haven't felt we have anything resembling an informed
consensus around these issues.  So I'm delighted that the
conversation has started.

    john

Date: Fri, 28 Jun 2002 10:35:55 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Michael Mealling <[email-masked]>
Cc: John C Klensin <[email-masked]>, Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <[email-masked]>, Rob Austein <[email-masked]>, [email-masked], [email-masked]

> Very fundamental and very important, especially if you ever
> aspire to running something even a fraction of the size of
> ".com"....

Uh, the flatness of the namespace is an artifact of non-technical policy
making. It isn't something that anyone other than the direct beneficiaries
have an interest in. It brand management. We don't do that. Other bodies
do.

I don't care if .com can't be signed, searched, inverted, hashed, browned,
or stir-fried. Defect of implementation is an implementation issue.

Cheers,
Eric

Date: Fri, 28 Jun 2002 10:30:29 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Michael Mealling <[email-masked]>
Cc: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]

--On Friday, 28 June, 2002 10:05 -0400 Michael Mealling
<[email-masked]> wrote:

> On Fri, Jun 28, 2002 at 09:29:13AM -0400, John C Klensin wrote:
>> (Note to readers of this list other than Patrik and Rob...
>> Patrik has raised, in conjunction with this "transport
>> requirements" discussion, a rather fundamental design issue.
> 
> Very fundamental and very important, especially if you ever
> aspire to running something even a fraction of the size of
> ".com"....

Personally, I aspire to a design that prevents ever needing to
do that, especially on that architecture.   I haven't been
actively in touch with my former colleagues in the VLBD
community for a decade or so, but I would assume that, by now,
they would consider COM to be of quite moderate size.

>> Yes, but...  If one can keep the operations sufficiently
>> simple (e.g., no profiles and few or none of the constraints
>> you are concerned about), there are very significant
>> advantages to server-side operations, particularly to
>> interoperability, getting things right, and being able to do
>> upgrades/ changes in a rational way. Based on some experience
>> with very large databases involving a high ratio of queries
>> to updates, I think one can go well beyond bitwise comparison
>> and still have that be true, at least given reasonable
>> database design.
> 
> I really think some cost/benifit analysis with an input from
> Moore's Law would be helpful. Simply saying that "server side
> operations = bad" isn't sufficient. Certain complex operations
> would be but its not that simple. Part of the problem is that
> we don't know how to do the analysis. If the benifit is high
> enough (a true multilingual Internet) does it become desirable
> at any cost? Some would say yes and happily go out and build
> co-located server farms with literally thousands of machines.
> I wouldnt' agree with them but we have to be really careful
> how we address this. 

yes
 
> <thinking out loud>
> My gut level, first reaction is that simple computation and
> byte-level lookup is fine. Things like per-user customized
> queries, attempts at anything like natural language would
> break that barrier. These things would be very appropriate for
> Layer 3 type services but not for Layer 2. But I can't really
> put my finger on how I'm making those decisions... I guess it
> has something to do with being able to treat each query the
> same and utilizing the fastest parts of the system (simple,
> non-conditional and deterministic computation backed up with
> octet-wise database lookup).  </thinking out loud>

I think we are largely in agreement, regardless of how we are
thinking about it.  Going back to my previous note, I think
there is an important role for localization, or even
user-specific, functions, but I don't think they belong on
global servers.  I would think that per-user customization and
natural language functions would mostly fall into the
"localization" category.  Now, some of those localizations would
be appropriately client-side activities (before getting into
IRNSS) and some would be sublayer three search functions (I
understand that boundary less well today than I thought I did
six months ago).

One caution, however: the two biggest advantages of IRNSS at
sublayer two over the traditional DNS model are 

	* the organization of the database (however distributed)
	on a faceted basis, rather than yielding all naming
	semantics to an administrative hierarchy.
	
	* the ability to define and perform near-match searches
	for at least some facets.

The former is consistent with a "just match bits" approach to
server functions.  The latter is not.  Moreover, it generally
cannot be done client-side, since access to the database will be
required to determine what is, and is, not a [near] match. Fuzzy
matching can be faked in some cases by multiple queries, but the
multipliers get large quickly and the tradeoffs between
increased network load and more queries versus some additional
server work on a single query will, I think, rarely come out to
favor the former.

Again, if some of you believe that fuzzy matching is too
server-complex to think about, we had best have that discussion
quickly, as it is _very_ basic to the current model.

     john

Date: Fri, 28 Jun 2002 10:25:12 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Rob Austein <[email-masked]>
Cc: [email-masked], [email-masked]

> It could be construed as off-topic for ...

I wouldn't say its off topic. Then again, there may be several topics that
resemble "transport requirements".

An epp domain check (xml-over-tcp) runs to half-a-K-bytes before adding the
sld and tld strings and any transaction id strings.

The reply is close to 1K-bytes before getting cluttered up with data.

Since an existence check is a staggeringly large fraction of what passes for
"responsible use" of the dns provisioning infrastructure (see "cute names",
"flat namespaces"), putting it into udp-friendly-form is odd in its absence.

Eric

Date: Fri, 28 Jun 2002 10:17:04 -0400
From: Michael Mealling <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: John C Klensin <[email-masked]>
Cc: Michael Mealling <[email-masked]>, Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]
Reply-to: Michael Mealling <[email-masked]>

On Fri, Jun 28, 2002 at 10:05:55AM -0400, John C Klensin wrote:
> --On Friday, 28 June, 2002 08:44 -0400 Michael Mealling
> <[email-masked]> wrote:
> >> > It's not a big deal for the server to perform the entire
> >> > query operation again.
> >> 
> >> ...given the matching operation is cheap. I.e. what you don't
> >> say explicitly is that we should use as much as possible of
> >> the CPU on the client side.
> >> 
> >> This is one of the reasons why I when I came up with IDNA
> >> want the client to do the normalization etc, so the server
> >> can do bitwise comparison which make handling of hash tables
> >> easier.
> >>...
> > I have to agree. Our experience running .com suggests that,
> > due to  the scale of queries, any small percentage change in
> > processing requirements on the server side results in huge
> > swings in operational requirements that affect the entire
> > robustness of the system. 
> 
> Mumble.  I don't question your data, but I think you have drawn
> a seriously-wrong inference from it.

Let me be clearer, I agree with Patrik's concen. I don't necessarily
agree with his conclusion concerning where normalization occurs and
when/where you do byte-level comparison since they are specifically
concerned with DNS and IDN. Since we're doing something new
here we have the ability to distribute the costs differently given
these possible optimizations:

> I suggest that we have a rather wide range of options for making
> databases perform acceptably.  They include:
> 
> 	* Having them do as little as possible (that would be an
> 	extreme reading of Patrik's argument).
>
> 	* Distributing the data widely.
> 	
> 	* Using extensive replication.
> 	
> 	* Using sophisticated caching so as to keep some load
> 	out of the database entirely.
> 
> 	* Designing the servers so that they function as
> 	efficiently as possible given the characteristics of the
> 	queries.

Completely agree.

> I suggest that the inference we should draw is that our design
> assumptions about database size and organization should match
> usage patterns so that we can design and tune for efficiency.
> To tune such a system for the experience with COM would likely
> be the beginning of another mistake.

Yes. I am talking usage patterns. I'm assuming that since we
are talking about something "above DNS" that we have the ability
to design to the usage pattern that ".com" is being pressed into,
not how its exactly been done.

> Example:  The DNS model permits stub resolvers with no caching
> at all under client control or bound to the client.  Names are
> also bound to objects whose addresses/ definitions change on
> short notice, so typical TTLs are a day or less.  Now, contrast
> this with where IRNSS seems to be headed.  A faceted name is
> used to locate one or more DNS names, with user determination of
> which DNS name, or names, are relevant.  We assume that, once
> the user makes that choice, we will cache the query and its
> results on a per-user basis.  The high-volatility situation
> still occurs in the mapping between DNS name and resource, so,
> in most cases, IRNSS TTLs should be quite large, keeping the
> query rate per user on the IRNSS structure fairly low.  

Yes. The late binding to the correct host-node is done at the DNS
level with regard to the domain-name in the URI, and not at the
IRNSS (NRS in SLS) level....

> The DNS query rate might benefit too, from fewer queries for names that
> don't exist, but we will have to see how that develops.   We
> certainly need to be careful about the architecture, but it is
> well-known how to distribute and scale canonicalization
> processes independent of database search, and how to do rapid
> database searches on properly-organized and indexed databases of
> much larger size than COM.  

Yes. I think I mispoke (as I laid out in another message). I think
the concern about the cost of server side operations is an extremely
valid one as it relates to network performance and scalability.
Would I come to Patrik's same conclusion? No since its based on DNS
and not doing something completely new like IRNSS.

> > I think that's a valuable enough guideline to warrant putting
> > it into at least the SLS document I'm working on...
> 
> I'm increasingly seeing SLS as a server location mechanism and
> don't have a clear sense as to how often (per user, per hour,
> per user-level query, per... ?) that will occur.  Intuitively,
> it would seem to me that SLS, too, might want to focus as much
> or more on getting caching right than on particular
> characteristics of the server-side function.  If one can
> eliminate 20% of the queries, that should produce, all other
> things being equal, more performance improvement than making the
> server-side algorithms 20% more efficient (or more minimal in
> function).  And it is probably easier to achieve.
> 
> But I don't have a clear enough picture of what you have in mind.

I'm simply stating in the introduction as one of the design criteria.
I haven't really decided if any parts of the design actaully change.
I.e. I kept that design constraint in the back of my mind when I think
about this but I never state it explicitly....

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Fri, 28 Jun 2002 15:40:24 +0200
From: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Michael Mealling <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]

--On 2002-06-28 08.44 -0400 Michael Mealling <[email-masked]> wrote:

> I think that's a valuable enough guideline to warrant putting it into at
> least the SLS document I'm working on...

Please...

Of course, any kind of fuzzy matching rule _can_ be expressed in a more
clever hashing function. But, someone have to invent that hash, and if they
have already, we will not have more implementations.

So, simple protocol, simple processing on server side. Clever clients.

That also create an opportunity for people to compete for smart client
things.

   paf

Date: Fri, 28 Jun 2002 10:05:03 -0400
From: Michael Mealling <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: John C Klensin <[email-masked]>
Cc: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]
Reply-to: Michael Mealling <[email-masked]>

On Fri, Jun 28, 2002 at 09:29:13AM -0400, John C Klensin wrote:
> (Note to readers of this list other than Patrik and Rob...
> Patrik has raised, in conjunction with this "transport
> requirements" discussion, a rather fundamental design issue.

Very fundamental and very important, especially if you ever aspire
to running something even a fraction of the size of ".com"....

> --On Friday, 28 June, 2002 14:11 +0200 Patrik Fältström
> <[email-masked]> wrote:
> 
> > --On 2002-06-27 23.41 -0400 Rob Austein <[email-masked]> wrote:
> > 
> >> It's not a big deal for the server to perform the entire
> >> query operation again.
> > 
> > ...given the matching operation is cheap. I.e. what you don't
> > say explicitly is that we should use as much as possible of
> > the CPU on the client side.
> > 
> > This is one of the reasons why I when I came up with IDNA want
> > the client to do the normalization etc, so the server can do
> > bitwise comparison which make handling of hash tables easier.
> > 
> > I am very nervous when people come up with protocols where the
> > client can pass whatever constraints to the server, and
> > request the server to do complicated things. Things which is
> > easy when you have an MySQL database with 100 records, but,
> > when you have more data in the database than what fits in
> > primary memory, then you loose.
> > 
> >    paf -- with tons of experience regarding "hitting the wall"
> > regarding           implementation of databases etc
> 
> Yes, but...  If one can keep the operations sufficiently simple
> (e.g., no profiles and few or none of the constraints you are
> concerned about), there are very significant advantages to
> server-side operations, particularly to interoperability,
> getting things right, and being able to do upgrades/ changes in
> a rational way. Based on some experience with very large
> databases involving a high ratio of queries to updates, I think
> one can go well beyond bitwise comparison and still have that be
> true, at least given reasonable database design.

I really think some cost/benifit analysis with an input from Moore's Law
would be helpful. Simply saying that "server side operations = bad"
isn't sufficient. Certain complex operations would be but its not
that simple. Part of the problem is that we don't know how to do the
analysis. If the benifit is high enough (a true multilingual Internet)
does it become desirable at any cost? Some would say yes and happily go out
and build co-located server farms with literally thousands of machines.
I wouldnt' agree with them but we have to be really careful how we
address this. 

<thinking out loud>
My gut level, first reaction is that simple computation and byte-level
lookup is fine. Things like per-user customized queries, attempts at
anything like natural language would break that barrier. These things
would be very appropriate for Layer 3 type services but not for Layer 2.
But I can't really put my finger on how I'm making those decisions...
I guess it has something to do with being able to treat each query the
same and utilizing the fastest parts of the system (simple, non-conditional
and deterministic computation backed up with octet-wise database lookup). 
</thinking out loud>

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Fri, 28 Jun 2002 10:05:55 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Michael Mealling <[email-masked]>, =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]

--On Friday, 28 June, 2002 08:44 -0400 Michael Mealling
<[email-masked]> wrote:

>> > It's not a big deal for the server to perform the entire
>> > query operation again.
>> 
>> ...given the matching operation is cheap. I.e. what you don't
>> say explicitly is that we should use as much as possible of
>> the CPU on the client side.
>> 
>> This is one of the reasons why I when I came up with IDNA
>> want the client to do the normalization etc, so the server
>> can do bitwise comparison which make handling of hash tables
>> easier.
>>...
> I have to agree. Our experience running .com suggests that,
> due to  the scale of queries, any small percentage change in
> processing requirements on the server side results in huge
> swings in operational requirements that affect the entire
> robustness of the system. 

Mumble.  I don't question your data, but I think you have drawn
a seriously-wrong inference from it.

I suggest that we have a rather wide range of options for making
databases perform acceptably.  They include:

	* Having them do as little as possible (that would be an
	extreme reading of Patrik's argument).
	
	* Distributing the data widely.
	
	* Using extensive replication.
	
	* Using sophisticated caching so as to keep some load
	out of the database entirely.

	* Designing the servers so that they function as
	efficiently as possible given the characteristics of the
	queries.

Now, the DNS tries to do some of these things.  But the caching
isn't good enough, the distribution model may be inadequate to
today's load, the most popular implementation may not represent
today's state of the art in high-retrieval, low-update
databases, etc.  And, probably more important than all of these,
it was designed on the assumption of deep hierarchy and
relatively small zones.  COM breaks that assumption entirely.

I suggest that the inference we should draw is that our design
assumptions about database size and organization should match
usage patterns so that we can design and tune for efficiency.
To tune such a system for the experience with COM would likely
be the beginning of another mistake.

Example:  The DNS model permits stub resolvers with no caching
at all under client control or bound to the client.  Names are
also bound to objects whose addresses/ definitions change on
short notice, so typical TTLs are a day or less.  Now, contrast
this with where IRNSS seems to be headed.  A faceted name is
used to locate one or more DNS names, with user determination of
which DNS name, or names, are relevant.  We assume that, once
the user makes that choice, we will cache the query and its
results on a per-user basis.  The high-volatility situation
still occurs in the mapping between DNS name and resource, so,
in most cases, IRNSS TTLs should be quite large, keeping the
query rate per user on the IRNSS structure fairly low.  The DNS
query rate might benefit too, from fewer queries for names that
don't exist, but we will have to see how that develops.   We
certainly need to be careful about the architecture, but it is
well-known how to distribute and scale canonicalization
processes independent of database search, and how to do rapid
database searches on properly-organized and indexed databases of
much larger size than COM.  

> I think that's a valuable enough guideline to warrant putting
> it into at least the SLS document I'm working on...

I'm increasingly seeing SLS as a server location mechanism and
don't have a clear sense as to how often (per user, per hour,
per user-level query, per... ?) that will occur.  Intuitively,
it would seem to me that SLS, too, might want to focus as much
or more on getting caching right than on particular
characteristics of the server-side function.  If one can
eliminate 20% of the queries, that should produce, all other
things being equal, more performance improvement than making the
server-side algorithms 20% more efficient (or more minimal in
function).  And it is probably easier to achieve.

But I don't have a clear enough picture of what you have in mind.

      john

Date: Fri, 28 Jun 2002 09:47:02 -0400
From: Michael Mealling <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Rob Austein <[email-masked]>
Cc: [email-masked]
Reply-to: Michael Mealling <[email-masked]>

On Thu, Jun 27, 2002 at 11:41:33PM -0400, Rob Austein wrote:
> This is the piece on DNS transport requirements to which I referred in
> the previous message, written as input to a BOF in 1998 that I wasn't
> able to attend in person.  It could be construed as off-topic for
> IRNSS per se, but Michael did ask, so for what it's worth....

I wouldn't say its off topic. Especially since you even discuss
something like IRNSS in there. I don't want to spend the entire
time discussing this point but possibly a short discussion might
help me with the document I'm writing...

> DNS has somewhat peculiar transport requirements (not news to you
> folks, obviously).  There are several interwoven factors at work here:
> 
> a) The relatively huge number of DNS clients compared to the relatively
>    small number of DNS servers, particularly as one gets close to the
>    root of the DNS tree (root zone itself, TLDs, big SLDs, etc).
> 
> b) The idempotence of normal DNS queries, and the relatively small
>    amount of work that a DNS server has to do in order to process a
>    normal query.

Which is something any designer of a Layer 2 service should keep in mind.

> c) The relatively low probability that any particular DNS response
>    message will be dropped by the network.

Is this due to its size? I.e. can that be re-written as:

 c) The relatively low probability that any particular 512 byte UDP packet
    will be dropped by the network.

> Taken together, these factors suggest that DNS as we currently know it
> is a classic example of what should be a "stateless" protocol.  The
> server is a critical resource and expects to receive *lots* of
> queries, a vanishingly small number of which will be from any single
> client.  It's not a big deal for the server to perform the entire
> query operation again.  The result is that the aggregate cost to the
> network of using an unreliable transport and recomputing responses
> when retransmission is necessary is less than the cost would be for
> the server to maintain *any* kind of state on behalf of its clients,
> including the kind of state required for even the most lightweight of
> reliable transport protocols.  This has a number of implications,
> perhaps the most troubling of which is the relative uselessness of
> attempting to do conventional path-MTU discovery.

This was one of my conclusions as well. RESCAP also fits into this
same model. The cost of re-querying to the server is lower than just 
about any other technique...

> Therefore, horrifying as it may be to all right-thinking engineers,
> one can make a very strong case that the correct transport protocol
> for normal DNS queries is exactly what we have now, even though
> implies that the correct way of handling bigger DNS response packets
> is via IP fragmentation.  This topic comes up regularly in the DNS
> working groups, but so far the consensus has been that while UDP is a
> terrible transport protocol for DNS, the known alternatives are worse.

Ok, this and the rest of the paragraphs assume IP fragmentation. The
question I have is this: since there is no congestion control at the
IP layer for fragments, and IP fragmentation seems to be acceptable, 
why not do it at the application layer? Limit the packet size to the
minimum MTU for that network and don't do retransmission of packets.
I'm not a transport guru but it seems that all of the congestion
control issues come about because of packet retransmission. If you
just don't _do_ packet level retransmission then congestion control
becomes a non-issue.

In other words, instead of negotiating packet size in the first packet,
have it hardwired to 512 bytes but send multiple packets with
simple sequence numbers so the application can just piece 'em back
together. If it fails you can retry the query via TCP (or UDP
if you feel it might work the second time). But you never ask for individual 
packets to be retransmitted, and you never ACK. 

Its the same network profile as IP fragmentation but with a much
better chance of success at greater than 1500 byte message sizes.

> In the long term, if we ever get a real white pages protocol and
> people stop caring about having cute DNS names, we're still going to
> need an underlying system for associating long-term identifiers with
> IP addresses.  At a technical level, such a system will probably look
> an awful lot like the DNS, but perhaps it'll be sufficently
> decentralized that a reliable transport protocol wouldn't be such a
> burden on the servers.

Awfully prescient!

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Fri, 28 Jun 2002 09:29:13 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>, Rob Austein <[email-masked]>, [email-masked]

(Note to readers of this list other than Patrik and Rob...
Patrik has raised, in conjunction with this "transport
requirements" discussion, a rather fundamental design issue.
The explanation below reflects what I believe about the issue.
It is thinking that very strongly influences the "dns-search"
framework.  It may also be wrong: people who think it is, or
might be, should try to speak up, since, if it is, resolving it
now and looking for alternatives will save us hugh amounts of
time and energy later.  And, if the argument isn't clear,
whether you agree with me or a much more extreme form of
Patrik's positin than I think he is taking, please ask now...
this may be _very_ important)

--On Friday, 28 June, 2002 14:11 +0200 Patrik Fältström
<[email-masked]> wrote:

> --On 2002-06-27 23.41 -0400 Rob Austein <[email-masked]> wrote:
> 
>> It's not a big deal for the server to perform the entire
>> query operation again.
> 
> ...given the matching operation is cheap. I.e. what you don't
> say explicitly is that we should use as much as possible of
> the CPU on the client side.
> 
> This is one of the reasons why I when I came up with IDNA want
> the client to do the normalization etc, so the server can do
> bitwise comparison which make handling of hash tables easier.
> 
> I am very nervous when people come up with protocols where the
> client can pass whatever constraints to the server, and
> request the server to do complicated things. Things which is
> easy when you have an MySQL database with 100 records, but,
> when you have more data in the database than what fits in
> primary memory, then you loose.
> 
>    paf -- with tons of experience regarding "hitting the wall"
> regarding           implementation of databases etc

Yes, but...  If one can keep the operations sufficiently simple
(e.g., no profiles and few or none of the constraints you are
concerned about), there are very significant advantages to
server-side operations, particularly to interoperability,
getting things right, and being able to do upgrades/ changes in
a rational way. Based on some experience with very large
databases involving a high ratio of queries to updates, I think
one can go well beyond bitwise comparison and still have that be
true, at least given reasonable database design.

To be specific, I have a substantive concern about IDNA which I
have not wanted to raise in the "IDN" context because I don't
see an alternative there.  There is, as we know, some
controversy about the various normalizations and mappings.  Even
those who believe that they represent reasonable tradeoffs and
are globally correct are likely to find cases that they believe
should be different for local use (e.g., should U+00F6 and
U+00F8 map together if one knows the user is in Sweden or
Norway).  I don't think there is ever going to be a
universally-agreed "right" answer to this sort of question,
given adequate localization.  Of course, for a German user
working in Norway, the answer is clearly "no".  

I fear, and expect, that we will see client implementations of
IDNA/Nameprep that are "improved for use in ...", i.e., that use
slightly different mappings for locally-important characters.
And that is the road to subtle and hard-to-detect
non-interoperability, one that may ultimately require exhibiting
the ACE form to users as a disambiguator.  If, by contrast, the
functions were based on servers that explicitly had to serve the
global Internet community, the incentives for non-interoperable
implementations, and the ability to implement them without being
noticed, would be much less.

The alternative here is to be very explicit about localization
and what is localized and what is not.  Unless the servers
themselves are localized (basically impossible with the DNS,
although it is possible, as we know, to fake it for particular
subtrees), it seems to me to be a reasonable model to assume
that global services and databases, and the associated mappings,
are server-side, that localization is more of a client function,
and we had best figure out how to make it work that way.

Coming back to the U+00F6 / U+00F8  case, I can easily imagine
reasonable client-side localizations that would map one way from
Norwegian and the other way from Swedish, given knowledge of the
language of the user and that of the database entry.  I would
see the UIs for that sort of function making the
global/canonical form readily available to users, and users
becoming aware that, typing convenience aside, they are better
off using the canonical form in global interchange.  One could,
in principle, do that in IDNA as well, but the IDNA (and other
IDN WG) documents have been (probably properly) very quiet on
processing and presentation recommendations during the various
pre-Unicode coding, mapping, and canonicalization steps.  And,
with everything client-side, there may not be enough incentive
to get this right.

Because it is bound to the DNS, which has no semantics to
support the anything but global functions (in
internationalization or anything else), IDNA will almost
certainly never be a completely adequate solution since it moves
global normalization and matching functions to the client,
confusing them with localization issues.  That doesn't make it
"wrong" -- I still believe it is as good, or better, than any
other approach given the constraints -- but it becomes part of
the justification for an "above DNS" approach to these problems.

Let's not lose one of the advantages of such an approach by
shifting functionality and processing to the client side just
because it will save some CPU, at least without doing a very
careful analysis of what is actually involved.

    john

Date: Fri, 28 Jun 2002 08:44:23 -0400
From: Michael Mealling <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Patrik =?iso-8859-1?B?RuRsdHN0cvZt?= <[email-masked]>
Cc: Rob Austein <[email-masked]>, [email-masked]
Reply-to: Michael Mealling <[email-masked]>

On Fri, Jun 28, 2002 at 02:11:18PM +0200, Patrik Fältström wrote:
> --On 2002-06-27 23.41 -0400 Rob Austein <[email-masked]> wrote:
> > It's not a big deal for the server to perform the entire
> > query operation again.
> 
> ...given the matching operation is cheap. I.e. what you don't say
> explicitly is that we should use as much as possible of the CPU on the
> client side.
> 
> This is one of the reasons why I when I came up with IDNA want the client
> to do the normalization etc, so the server can do bitwise comparison which
> make handling of hash tables easier.
> 
> I am very nervous when people come up with protocols where the client can
> pass whatever constraints to the server, and request the server to do
> complicated things. Things which is easy when you have an MySQL database
> with 100 records, but, when you have more data in the database than what
> fits in primary memory, then you loose.

I have to agree. Our experience running .com suggests that, due to 
the scale of queries, any small percentage change in processing requirements
on the server side results in huge swings in operational requirements
that affect the entire robustness of the system. 

I think that's a valuable enough guideline to warrant putting it into at
least the SLS document I'm working on...

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Fri, 28 Jun 2002 14:11:18 +0200
From: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Subject: Re: Transport requirements for DNS-like protocols
To: Rob Austein <[email-masked]>, [email-masked]

--On 2002-06-27 23.41 -0400 Rob Austein <[email-masked]> wrote:

> It's not a big deal for the server to perform the entire
> query operation again.

...given the matching operation is cheap. I.e. what you don't say
explicitly is that we should use as much as possible of the CPU on the
client side.

This is one of the reasons why I when I came up with IDNA want the client
to do the normalization etc, so the server can do bitwise comparison which
make handling of hash tables easier.

I am very nervous when people come up with protocols where the client can
pass whatever constraints to the server, and request the server to do
complicated things. Things which is easy when you have an MySQL database
with 100 records, but, when you have more data in the database than what
fits in primary memory, then you loose.

   paf -- with tons of experience regarding "hitting the wall" regarding
          implementation of databases etc

Date: Thu, 27 Jun 2002 23:41:33 -0400
From: Rob Austein <[email-masked]>
Subject: Transport requirements for DNS-like protocols
To: [email-masked]

--Boundary_(ID_kR2vbgphEDacWJMKRvJ3gg)
Content-type: text/plain; charset=US-ASCII

This is the piece on DNS transport requirements to which I referred in
the previous message, written as input to a BOF in 1998 that I wasn't
able to attend in person.  It could be construed as off-topic for
IRNSS per se, but Michael did ask, so for what it's worth....

--Boundary_(ID_kR2vbgphEDacWJMKRvJ3gg)
Content-type: text/plain; charset=US-ASCII

DNS has somewhat peculiar transport requirements (not news to you
folks, obviously).  There are several interwoven factors at work here:

a) The relatively huge number of DNS clients compared to the relatively
   small number of DNS servers, particularly as one gets close to the
   root of the DNS tree (root zone itself, TLDs, big SLDs, etc).

b) The idempotence of normal DNS queries, and the relatively small
   amount of work that a DNS server has to do in order to process a
   normal query.

c) The relatively low probability that any particular DNS response
   message will be dropped by the network.

Taken together, these factors suggest that DNS as we currently know it
is a classic example of what should be a "stateless" protocol.  The
server is a critical resource and expects to receive *lots* of
queries, a vanishingly small number of which will be from any single
client.  It's not a big deal for the server to perform the entire
query operation again.  The result is that the aggregate cost to the
network of using an unreliable transport and recomputing responses
when retransmission is necessary is less than the cost would be for
the server to maintain *any* kind of state on behalf of its clients,
including the kind of state required for even the most lightweight of
reliable transport protocols.  This has a number of implications,
perhaps the most troubling of which is the relative uselessness of
attempting to do conventional path-MTU discovery.

Therefore, horrifying as it may be to all right-thinking engineers,
one can make a very strong case that the correct transport protocol
for normal DNS queries is exactly what we have now, even though
implies that the correct way of handling bigger DNS response packets
is via IP fragmentation.  This topic comes up regularly in the DNS
working groups, but so far the consensus has been that while UDP is a
terrible transport protocol for DNS, the known alternatives are worse.

There are other factors besides the ones that I've listed, but these
are the most interesting, because they're all subject to change as the
Internet evolves.

Factor (a) seems likely to get worse, not better, at least for the
near term.  For non-technical reasons, the overall trend in the DNS
today is towards a flatter namespace, which increases the load on the
servers close to the root (particularly the big TLD servers).  This is
bad network engineering, but the people making these decisions are not
engineers, and let's not go down that rathole :).

In the long term, if we ever get a real white pages protocol and
people stop caring about having cute DNS names, we're still going to
need an underlying system for associating long-term identifiers with
IP addresses.  At a technical level, such a system will probably look
an awful lot like the DNS, but perhaps it'll be sufficently
decentralized that a reliable transport protocol wouldn't be such a
burden on the servers.

Factor (b) is probably the most interesting at a technical level.  One
of the design goals of the DNSSEC extensions was to allow RRs to be
signed offline rather than in real time during query processing.
There were several reasons for this, but one of the reasons was that
cryptographic operations are computationally expensive.  However, in
the case of transaction signatures and secure dynamic DNS update, some
cryptographic operations must be done in real time.  At the moment, we
expect these operations to be relatively infrequent, but if these
operations (or any other "expensive" operation which must be performed
on every query) become frequent enough, that could (theoretically)
change the current balance to the point where a reliable transport
protocol for DNS might pay for itself.  But it may never happen, since
we may be able to stay ahead of the game just by putting enough money
into the relatively small number of heavily loaded servers.

Factor (c) is a little weird.  The current trade-off for DNS works
because the underlying network service is usually pretty good even
though it's "unreliable".  If this were to change significantly for
the worse, it would tip the balance in favor of a reliable transport
protocol for DNS.  A major shift away from hardwired links to noisy
radio links at the physical layer might do it, or a sufficiently bad
episode of widespread network congestion.  DNS is far from the only
thing that would break if unreliable service got significantly worse,
of course, but DNS bears close scrutiny because its transport model
does not degrade very gracefully.  Basic engineering paranoia suggests
that we should continue looking at candidate lightweight transport
protocols for DNS, in the hope of eliminating this risk.

One last observation.  There are a few things that could be done to
improve DNS's transport environment without imposing the burden of
keeping state on the server.  DNS clients usually talk to a relatively
small number of DNS name servers at any given time, so there's no
reason why the client couldn't keep some transport-related state on
the servers it's been talking to recently.  For example, since the
client handles all retransmissions, there's no reason why the client
couldn't use the same variance-based retransmission timeout
calculation that TCP uses.  Some DNS clients may already do this, but
it's not a requirement.  Perhaps it should be.

Another form of state that the client could keep would be path-MTU
information.  Since the server isn't keeping any state and the client
can't dictate the server's behavior, this mechanism would necessarily
be in the form of a request from the client to the server as to how
big a response packet the client would like the server to try sending,
and as to whether or not the client wants the server to allow
fragmentation of the response message.  Some recent work in the DNSIND
group is heading in this general direction, but there are some details
of how the client should vary its use of this mechanism during
retransmission that haven't really been thrashed out yet.  If this
approach pans out, it won't completely eliminate DNS's reliance on IP
fragmentation, but it might reduce the associated risks to an
acceptable level.

--Boundary_(ID_kR2vbgphEDacWJMKRvJ3gg)--

Date: Thu, 27 Jun 2002 23:05:09 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Rob Austein <[email-masked]>
Cc: [email-masked], [email-masked]

> Which, for many protocols, would be a Bad Thing (tm), but for an
> idempotent protocol in which it is cheaper to re-run the query than to
> stash replies in case something bad happens, this might be the best
> one can do.

Yeah. I've been thinking of an optimization for the epp check to run over
udp for just this reason.

Date: Thu, 27 Jun 2002 19:31:43 -0400
From: Rob Austein <[email-masked]>
Subject: Re: Where we stand and where we are going
To: [email-masked]

At Thu, 27 Jun 2002 09:19:17 -0400, Michael Mealling wrote:
> 
> On Wed, Jun 26, 2002 at 04:42:15PM -0400, Rob Austein wrote:
>
> Ok, I've been doing a lot of thinking in this realm and talking to all
> sorts of people and I keep hearing different things. Here's the FUD I 
> keep hearing:
> 
> 1) IP fragmentation on the Internet is awful so if you do UDP packets
> larger than 1500 bytes you will probably loose one of the fragments
> about 10 percent of the time

Which, for many protocols, would be a Bad Thing (tm), but for an
idempotent protocol in which it is cheaper to re-run the query than to
stash replies in case something bad happens, this might be the best
one can do.

> 2) Attempts to do UDP fragementation at the application layer and not the
> IP layer just means you're going to reinvent all of TCP over again so
> why bother trying and just use TCP.

Yeah, I've had that conversation too.  A few years ago I suggested
reimplementing portions of NETBLT over UDP, and was roundly trounced
for failing to understand the behavior of a tail-drop universe.  I
have not yet figured out whether I really believe that argument, but I
think it would be safe to say that we understand single-datagram UDP,
we understand TCP, and we may understand a few other protocols, but
the more general issues of timing, retransmission (ie, timing), and
buffering (ie, timing) for transport protocols are significantly more
"interesting" than one might wish (in the sense of the Chinese curse).

> 3) "Try with UDP and if it fails retry with TCP" is "good enough". <insert
> all of your "good enough is the enemy of good" verbage here>

If you're willing to live with approximately an order of magnitude
increase in load as the cost of failover, this might indeed be the
least bad option.  Transaction TCP shaves a bit off of that, but in
practice one gets to a point of diminishing returns very quickly in
the transport protocol space, if only because transport protocols
usually live in OS kernels.

> I have had two instances where the usage profile of a protocol suggests
> that 99% of the responses will be less than 2K and the interaction is
> stateless and connection-less. Inheriting the full session semantics of TCP
> isn't required. But neither is the sad state of UDP packet size limitations.
> 
> My proposed solution is to limit UDP packet sizes to 512 bytes and put
> packet sequence numbers on them. You still have a connectionless interaction
> but it a) puts the packet size into a realm with a higher probability of
> success and b) allows for a handful of those packets to get through. I'm
> not sure if you need more than that. You can still do the "well if 
> that didn't work I can always do TCP"...

I did a think piece years ago on transport requirements for DNS, as
input to a BOF that Vern held in, um, Orlando.  No doubt I've still
got it somewhere.  The 5 cent version is that transport requirements
for a lightweight idempotent query protocol with many orders of
magnitude more clients than servers are, um, kind of whacky.  So we
have stayed with UDP for DNS, but have added the aforementioned EDNS0
size "negotiation"[*] extension.

[*] It's not a negotation, just a statement by the client that the
server should please feel free to generate a response up to N bytes
long.  Life is wierd when a conversation only lasts for two packets.

Date: Thu, 27 Jun 2002 15:31:12 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Nicolas Popp <[email-masked]>
Cc: 'Leslie Daigle' <[email-masked]>, John C Klensin <[email-masked]>, Michael Mealling <[email-masked]>, [email-masked], [email-masked]

> That being said, I am not even sure why we are focusing on the transport at
> this stage.

Fine. However, it is possible that foo-over-udp and bar-over-tcp won't look
like twins seperated at birth.

Date: Thu, 27 Jun 2002 15:11:44 -0400
From: John C Klensin <[email-masked]>
Subject: RE: Where we stand and where we are going
To: Nicolas Popp <[email-masked]>
Cc: 'Leslie Daigle' <[email-masked]>, Michael Mealling <[email-masked]>, [email-masked]

--On Thursday, 27 June, 2002 11:44 -0700 Nicolas Popp
<[email-masked]> wrote:

> I strongly agree with Leslie on that one (it reminds me of the
> WAP binary XML debate).
> That being said, I am not even sure why we are focusing on the
> transport at this stage.

Let me both agree and try to answer your question...

There are, at the moment, exactly two protocol, or
near-protocol, documents on the table that address basic issues
at sublayer two (I'm not counting the ex-RealNames one because
of it "deal with the other facets later" approach -- doesn't
make it wrong, just in a different category).  One is SLS, the
other is "Chinese character string" one.  Most of us aren't
competent to discuss the latter in any depth, so why not discuss
the former?  :-(

Of course, the solution to this is "more drafts"

> Maybe it is just me, but my recollection from the Mineapolis
> meeting is that we still have substantial conceptual issues
> for which I have not seen clear definition or consensus. 
>> From the top of my head: what is the final list for layer 2
>> facets (e.g.
> what about service-type, serviceID and network-location?
> String matching rules: how fuzzy does it need to be? Do we
> need to standardize string matching rules within a cultural
> context (e.g. geography & language) or is it up to the
> service? should the match fuzzines be specified in the query
> (distance function)? How? Should the output be DNS names or
> URIs?...

There is more on some of this in the new version of dns-search
(pieces will go out tonight or tomorrow if I don't die of
heatstroke first), but we will still need protocol documents.

The list I sent you some months ago when you asked what people
should be doing is, of course, an orthogonal cut at the above.

    john

Date: Thu, 27 Jun 2002 11:44:51 -0700
From: Nicolas Popp <[email-masked]>
Subject: RE: Where we stand and where we are going
To: 'Leslie Daigle' <[email-masked]>, John C Klensin <[email-masked]>
Cc: Michael Mealling <[email-masked]>, [email-masked]

I strongly agree with Leslie on that one (it reminds me of the WAP binary
XML debate).
That being said, I am not even sure why we are focusing on the transport at
this stage.

Maybe it is just me, but my recollection from the Mineapolis meeting is that
we still have substantial conceptual issues for which I have not seen clear
definition or consensus. 
>From the top of my head: what is the final list for layer 2 facets (e.g.
what about service-type, serviceID and network-location? String matching
rules: how fuzzy does it need to be? Do we need to standardize string
matching rules within a cultural context (e.g. geography & language) or is
it up to the service? should the match fuzzines be specified in the query
(distance function)? How? Should the output be DNS names or URIs?...

I still don't have a good mental picture of what needs to be passed back and
forth, so it hard to focus on XML versus binary encoding. Can we see the
latest work (even in its draft form) first & soon? 

Thanks.

-Nico

-----Original Message-----
From: Leslie Daigle [mailto:[email-masked]]
Sent: Wednesday, June 26, 2002 12:28 PM
To: John C Klensin
Cc: Michael Mealling; [email-masked]
Subject: Re: Where we stand and where we are going

Howdy,

John C Klensin wrote:
>  And I
> think, in that context, that, unless the capabilities and
> flexibilities of XML are needed, that we should assume that this
> is infrastructure. Hence, those capabilities and flexibilities
> should be assumed to be overhead, fluff, and opportunities for
> profiles that kill interoperability.

Actually, I'm not ready to agree with this (not saying I won't
get there -- saying I'm not there yet).  XML in toto is overkill,
but we're not talking about that; we're trying to define a
constrained service and leverage XML as an expression for it.

> I can't speak for consensus, but my preference in all of this is
> to follow N. Wirth to the greatest degree possible, i.e., the
> goal should be "as simple as possible, but no simplier".

Date: Thu, 27 Jun 2002 19:20:31 +0200
From: =?ISO-8859-1?Q?Patrik_Fältström?= <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Michael Mealling <[email-masked]>, Rob Austein <[email-masked]>
Cc: [email-masked]

--On 2002-06-27 09.19 -0400 Michael Mealling <[email-masked]> wrote:

> My proposed solution is to limit UDP packet sizes to 512 bytes and put
> packet sequence numbers on them. You still have a connectionless
> interaction but it a) puts the packet size into a realm with a higher
> probability of success and b) allows for a handful of those packets to
> get through. I'm not sure if you need more than that. You can still do
> the "well if  that didn't work I can always do TCP"...
> 
> I really would like to hear some definitive answers on this topic because
> it keeps coming up and a solution would make a heck of a lot of sense.

As soon as you will send more than one packet, you need congestion control
and other things from TCP.

I rather say one can send data in either "one packet" or "many". Many
packets should be over TCP (or something else with congestion control)
while one packet can be over UDP.

That said, any protocol today needs to have negotiation/announcement of
capabilities from both a client and server perspective.

So, client send one packet to server. If server detect the packet was
fragmented, and some data which was wanted was missing, it can send back
"try again over better transport".

My question is: Can not a packet include in the beginning a length
indication in the beginning of the packet so the server can detect if MTU
was too small?

   paf

Date: Thu, 27 Jun 2002 09:19:17 -0400
From: Michael Mealling <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Rob Austein <[email-masked]>
Cc: [email-masked]
Reply-to: Michael Mealling <[email-masked]>

On Wed, Jun 26, 2002 at 04:42:15PM -0400, Rob Austein wrote:
> At Wed, 26 Jun 2002 10:36:41 -0400, Eric Brunner-Williams in Portland Maine wrote:
> > 
> > A move toward binary, UDP-friendly packet format is good.
> 
> Just please, if we go down this road, let's put the UDP packet length
> negotiation junk into the initial rev of the protocol and not wire
> arbitrary length limits (other than those imposed by IP and UDP
> themselves) into the protocol the way that RFC 1035 did to DNS.
> 
> Retrofitting this (EDNS0) has been an interesting learning experience,
> but it's one that I'd prefer not to have to repeat in this lifetime.

Ok, I've been doing a lot of thinking in this realm and talking to all
sorts of people and I keep hearing different things. Here's the FUD I 
keep hearing:

1) IP fragmentation on the Internet is awful so if you do UDP packets
larger than 1500 bytes you will probably loose one of the fragments
about 10 percent of the time

2) Attempts to do UDP fragementation at the application layer and not the
IP layer just means you're going to reinvent all of TCP over again so
why bother trying and just use TCP.

3) "Try with UDP and if it fails retry with TCP" is "good enough". <insert
all of your "good enough is the enemy of good" verbage here>

I have had two instances where the usage profile of a protocol suggests
that 99% of the responses will be less than 2K and the interaction is
stateless and connection-less. Inheriting the full session semantics of TCP
isn't required. But neither is the sad state of UDP packet size limitations.

My proposed solution is to limit UDP packet sizes to 512 bytes and put
packet sequence numbers on them. You still have a connectionless interaction
but it a) puts the packet size into a realm with a higher probability of
success and b) allows for a handful of those packets to get through. I'm
not sure if you need more than that. You can still do the "well if 
that didn't work I can always do TCP"...

I really would like to hear some definitive answers on this topic because
it keeps coming up and a solution would make a heck of a lot of sense.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Thu, 27 Jun 2002 09:15:18 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Rob Austein <[email-masked]>
Cc: [email-masked]

> ... UDP packet length negotiation junk into the initial rev ...

Thanks Rob, I hadn't thought of that. 

Date: Wed, 26 Jun 2002 16:42:15 -0400
From: Rob Austein <[email-masked]>
Subject: Re: Where we stand and where we are going
To: [email-masked]

At Wed, 26 Jun 2002 10:36:41 -0400, Eric Brunner-Williams in Portland Maine wrote:
> 
> A move toward binary, UDP-friendly packet format is good.

Just please, if we go down this road, let's put the UDP packet length
negotiation junk into the initial rev of the protocol and not wire
arbitrary length limits (other than those imposed by IP and UDP
themselves) into the protocol the way that RFC 1035 did to DNS.

Retrofitting this (EDNS0) has been an interesting learning experience,
but it's one that I'd prefer not to have to repeat in this lifetime.

Date: Wed, 26 Jun 2002 15:51:10 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Leslie Daigle <[email-masked]>
Cc: John C Klensin <[email-masked]>, Michael Mealling <[email-masked]>, [email-masked], [email-masked]

In drafting draft-jaye-mumble, we came real close to proposing to put the
p3p-++-esque policy for a cookie on several octets. The policy weenies in
p3p-land vetoed anything that didn't approximate Leslie's schema <-> xslt
comment, so we have compact policies (section 4 of the p3p spec), that are
not xml, but look like it.

A constraint, at least beyond the wireline/wireless demark, was the byte
count. It turns out that evaluation complexity is a harder constraint.

Now in this problem space, we've got the same dinky byte arrays the IDN
mob had, and no worse frequency of putting junk on the wire than the dns
has, so byte count isn't the first constraint.

That said, the weakness I see, with the little wit I possess, in an XML
framework is that XML and its authoring body have "solved" the charset
problem by defaulting to Unicode.

Yes, other charsets may be expressed.

I don't expect anyone to agree with me, but I feel that the problem space
is over-constrained, and poorly-constrained, when the solution space must
incorporate Unicode.

My $.02 of EBCDIC,
Eric

Date: Wed, 26 Jun 2002 15:27:39 -0400
From: Leslie Daigle <[email-masked]>
Subject: Re: Where we stand and where we are going
To: John C Klensin <[email-masked]>
Cc: Michael Mealling <[email-masked]>, [email-masked]

Howdy,

John C Klensin wrote:
>  And I
> think, in that context, that, unless the capabilities and
> flexibilities of XML are needed, that we should assume that this
> is infrastructure. Hence, those capabilities and flexibilities
> should be assumed to be overhead, fluff, and opportunities for
> profiles that kill interoperability.

Actually, I'm not ready to agree with this (not saying I won't
get there -- saying I'm not there yet).  XML in toto is overkill,
but we're not talking about that; we're trying to define a
constrained service and leverage XML as an expression for it.

> I can't speak for consensus, but my preference in all of this is
> to follow N. Wirth to the greatest degree possible, i.e., the
> goal should be "as simple as possible, but no simplier".

Date: Wed, 26 Jun 2002 11:47:19 -0400
From: John C Klensin <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Michael Mealling <[email-masked]>
Cc: [email-masked]

--On Wednesday, 26 June, 2002 09:41 -0400 Michael Mealling
<[email-masked]> wrote:

>> I am working on getting another version of "dns-search" out
>> before next Monday's deadline.  While it contains a number of
>> clarifications and updates, the important material is in
>> several new (or almost-new) sections.  I will circulate those
>> to this group as they are ready, in the hope of getting
>> comments before I fold them into the document or, at least, of
>> giving the rest of you some time to think about them before
>> Yokohama.
>> 
>> I have realized as I have been working on it that it presents
>> an abstract model, but perhaps too many undefined choices.
>> Would it be helpful to have drafts that identify and specify
>> implementable protocols (even if they are wrong) as a means of
>> getting comments and moving forward?  If so, we need to figure
>> out how to get those written -- I can certainly produce some
>> text for people to revise and replace, but that may not be the
>> most efficient way to move forward.
> 
> Would the SLS document help in that regard or are you suggesting
> something different? I expect to have the SLS document revised
> by thea deadline as well. 

I think the SLS document has been one of the more concrete bits
on the table.   I have been more concerned about all of the other
bits and pieces.

>> Suggestions as to how to proceed, comments on drafts, etc.,
>> are, of  course, welcome at any time.
> 
> My intent is that the SLS document will be upgraded to reflect
> somethings we've learned in the past few months, along with an
> update of the transport to be more 'DNS-like'. This means
> moving away from the XML chattiness and into a binary,
> UDP-friendly packet format. Is there any concensus for using
> that as a strawman protocol to bang against for concrete
> protocol-level discussions?

I can't speak for consensus, but my preference in all of this is
to follow N. Wirth to the greatest degree possible, i.e., the
goal should be "as simple as possible, but no simplier".  And I
think, in that context, that, unless the capabilities and
flexibilities of XML are needed, that we should assume that this
is infrastructure. Hence, those capabilities and flexibilities
should be assumed to be overhead, fluff, and opportunities for
profiles that kill interoperability.

      john

Date: Wed, 26 Jun 2002 10:36:41 -0400
From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Subject: Re: Where we stand and where we are going
To: Michael Mealling <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked], [email-masked]

Michael,

A move toward binary, UDP-friendly packet format is good.

Eric

Date: Wed, 26 Jun 2002 09:41:13 -0400
From: Michael Mealling <[email-masked]>
Subject: Re: Where we stand and where we are going
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Reply-to: Michael Mealling <[email-masked]>

On Tue, Jun 25, 2002 at 12:55:47PM -0400, John C Klensin wrote:
> Well, as usual, we have an IETF coming up, the publication
> deadline is very near, I haven't accomplished as much as I would
> like, and most others appear to not be publishing quickly either.

I resemble that remark. ;-)

> I am working on getting another version of "dns-search" out
> before next Monday's deadline.  While it contains a number of
> clarifications and updates, the important material is in several
> new (or almost-new) sections.  I will circulate those to this
> group as they are ready, in the hope of getting comments before I
> fold them into the document or, at least, of giving the rest of
> you some time to think about them before Yokohama.
> 
> I have realized as I have been working on it that it presents an
> abstract model, but perhaps too many undefined choices.  Would it
> be helpful to have drafts that identify and specify implementable
> protocols (even if they are wrong) as a means of getting comments
> and moving forward?  If so, we need to figure out how to get
> those written -- I can certainly produce some text for people to
> revise and replace, but that may not be the most efficient way to
> move forward.

Would the SLS document help in that regard or are you suggesting
something different? I expect to have the SLS document revised by
thea deadline as well. 

> Several people have asked about a BOF (or even a WG) in Yokohama.
> The problem, unfortunately, remains what it was in Minneapolis:
> especially for a WG, I don't think we have quite enough material
> on the table to ask the IESG to set one up: the only relevant
> draft I've seen since Minneapolis has been the Chinese name
> string proposal.  As most of you know, I would like to have
> enough substantive material ready before we try for general
> meetings to avoid one of the problems that has hindered the work
> of the IDN WG: too many people talking about too many different
> topics and not really understanding that they are not
> communicating with each other.

I definitely agree...

> Suggestions as to how to proceed, comments on drafts, etc., are,
> of  course, welcome at any time.

My intent is that the SLS document will be upgraded to reflect somethings
we've learned in the past few months, along with an update of the
transport to be more 'DNS-like'. This means moving away from the XML
chattiness and into a binary, UDP-friendly packet format. Is there
any concensus for using that as a strawman protocol to bang against
for concrete protocol-level discussions?

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling	|      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net

Date: Tue, 25 Jun 2002 12:55:47 -0400
From: John C Klensin <[email-masked]>
Subject: Where we stand and where we are going
To: [email-masked]

Hi.

Well, as usual, we have an IETF coming up, the publication
deadline is very near, I haven't accomplished as much as I would
like, and most others appear to not be publishing quickly either.
I am working on getting another version of "dns-search" out
before next Monday's deadline.  While it contains a number of
clarifications and updates, the important material is in several
new (or almost-new) sections.  I will circulate those to this
group as they are ready, in the hope of getting comments before I
fold them into the document or, at least, of giving the rest of
you some time to think about them before Yokohama.

I have realized as I have been working on it that it presents an
abstract model, but perhaps too many undefined choices.  Would it
be helpful to have drafts that identify and specify implementable
protocols (even if they are wrong) as a means of getting comments
and moving forward?  If so, we need to figure out how to get
those written -- I can certainly produce some text for people to
revise and replace, but that may not be the most efficient way to
move forward.

Several people have asked about a BOF (or even a WG) in Yokohama.
The problem, unfortunately, remains what it was in Minneapolis:
especially for a WG, I don't think we have quite enough material
on the table to ask the IESG to set one up: the only relevant
draft I've seen since Minneapolis has been the Chinese name
string proposal.  As most of you know, I would like to have
enough substantive material ready before we try for general
meetings to avoid one of the problems that has hindered the work
of the IDN WG: too many people talking about too many different
topics and not really understanding that they are not
communicating with each other.

Suggestions as to how to proceed, comments on drafts, etc., are,
of  course, welcome at any time.

regards,
    john