Re: draft-ietf-uri-urn-path-01.txt: performance estimates?

Daniel LaLiberte (liberte@ncsa.uiuc.edu)
Fri, 28 Jul 95 23:45:10 CDT


Date: Fri, 28 Jul 95 23:45:10 CDT
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
Message-Id: <9507290445.AA06026@void.ncsa.uiuc.edu>
To: connolly@beach.w3.org, mshapiro@ncsa.uiuc.edu
Subject: Re:  draft-ietf-uri-urn-path-01.txt: performance estimates?
Cc: uri@bunyip.com

> From: "Daniel W. Connolly" <connolly@beach.w3.org>

> But... it seems that resolution of path URNs would involve failed
> DNS lookups, which take a long time, no?

Thanks for your interest.  Michael Shapiro can give a better answer
regarding performance since he did a variety of tests.  Generally, it
is fast (less than a second with a good local resolver) and I can say
why the problem you are concerned about does not occur when you think
it might.

> Under "Resolving the URL-sets into the Resource" it says "After
> constructin a list of URL-sets, ..." 

This is partly an abstract description, so one does not actually need to
construct all the URL-sets before starting to resolve the most specific
ones.  However,...

> So I get the impression that the,
> for example, http transactions don't start until after the DNS
> transactions are done. 

That is true. Or at least, the URL resolution doesn't start until
the most specific resolver is found, but one could start somewhere
in the middle of the path, look for more specific resolvers, and
if they fail, only then look for higher level backup resolvers.

But the thing you are concerned about is ...

> And failed DNS lookups, in my experience, take 15 to 120 minutes.

Not in this case.  The long failures (I've never waited *that* long)
are due to not getting an authoritative answer (or maybe no answer at
all) so the resolvers keep looking around or trying to get through to a
server that is down.  The failure at the bottom of the DNS part of path
resolution is just as fast as a successful resolution when the
authoritative answer is known.

I was concerned previously about even that one failure hit on the remote
server, since it must always occur for every path resolution, unless
the local caches remember the negative hit from previous attempts for
a similar path.  We had a workaround (described in the previous version of
the draft) to avoid that one negative hit, but it now seems not worth
the complexity, since it requires effectively caching that same
negative info in TXT form.  Also, we expect that most path name
resolution would happen in the same neighborhood as the URL resolution
to get the resource itself, so one extra UDP request is not that much
of a burden.  

> Are path: implementations expected to exploit parallelism, or is
> there some technique for avoiding failed DNS lookups?

Implementations are expected to make use of local caches via DNS at
least.  DNS resolution can exploit some parallelism and so path
resolution can use that too.  If path's turn out to be used alot,
then resolvers and DNS itself might be changed in various ways 
to facilitate even faster path resolution.

> In general, do you have any performance data? Estimates?

Good question.  We also wanted to announce availability of our
mod of the CERN proxy server to do path resolution, so people could
try it out and not just believe our data.  RSN.

dan