Re: Transport requirements for DNS-like protocols

[John C Klensin <[e-mail]>]

--On Friday, 28 June, 2002 10:05 -0400 Michael Mealling
<[e-mail]> 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