Re: [RRG] Re: Delays inherent in TRRP's DNS-like lookup?

[Robin Whittle <rw@firstpr.com.au>]

Hi Bill,

Thanks for explaining TRRP in greater detail and improving my
understanding of DNS.  I will return to that below.

>>  Sure, but if a new kind of address space involves a new kind of
>>  delay, and you have the choice between this and the original
>>  kind of address space which has no such delays, then it is
>>  going to be hard to get many or most people to adopt the new
>>  kind.  As Marshall Eubanks wrote:
>>
>>     http://psg.com/lists/rrg/2008/msg00381.html
>
> Marshall wrote, 'the delays cannot be "significant," which
> [Marshall] would regard as meaning "being noticeably larger than
> typical DNS delays."'

I guess typical DNS delays for hosts in the USA for US-based
nameservers are probably well under 100msec.

What matters is not so much whether the actual delay is experienced
as significant by the client users of the servers of the end-users
who are considering map-encap space.  The real question is whether
the delays inherent in an ALT or TRRP based system are enough for at
least some marketing folks to trump it up to the broader end-user
population as being significant.

Even if the difference is believed by end-users to be minor, it is a
reason to avoid this kind of address space.  So I think we need to
keep delays really, really short, under all circumstances.  As far
as I can see, that precludes the reliance on global networks of any
kind for retrieving mapping or for delivering packets while waiting
for mapping to arrive.

Even if the global network was pretty optimal, it would add delay in
many instances - especially if you are out in the Colonies here in
Australia.  There is a 287ms round trip time from Melbourne to
Dallas TX, for instance.

ALT paths are likely to be much longer than optimal.


Looking at your IPv4 example, I understand the following would happen.

The ITR is looking up mapping for:

   111.22.33.44

so it sends a query about:

   44.33.22.111.v4.trrp.arpa

to one of the authoritative servers for:

            111.v4.trrp.arpa

- which it can do instantly, since it has already cached all such
authoritative servers xxx.v4.trrp.arpa.

So that is 8 of the 32 bits taken care of already.

In this example, this nameserver is run by an RIR and it knows about
65536 sub-domains - another 16 bits chewed through in one
request-response.  The answer comes back in the form:

  You should ask the server (IP addresses supplied) which is
  authoritative for:

      33.22.111.v4.trrp.arpa

The ITR now sends the same query to this server, and gets an
authoritative response with the mapping information it needs.

So for IPv4, you think the RIR's server would do this task of
handling up to 2^16 subdomains.  That sounds technically feasible,
but would the RIR really want to do this?

This would require administrative control of some aspect of the
RIR's server from a very large number of end-user organisations.

Wouldn't it be more likely that the RIR gave a /12 of this /8 to
some ISP, and would simply hand back an answer saying to ask the
nameserver of that ISP?  Then that server might delegate to another
one, which is authoritative.

I think your approach to reducing the delay time in finding the
mapping information depends very much on collapsing what would
normally be a multi-level delegation arrangement into a much flatter
model, which might be at odds with actual business relationships.

Another critique is that this RIR server is going to be very busy
indeed.  You could anycast these /8 level servers, but that would be
costly and harder to administer, since they all have to know so much
about the authoritative nameservers for up to 64k subdomains.

Broadly speaking, if there are about 220 /8s in use in IPv4, then
each such RIR server (really multiple servers) is going to get 1/220
of the total global ITR initial requests for mapping information.

This would not be the case if each such RIR nameserver only gave
answers which solved another 4 bits (for instance) of the ITR's
problem.  Then, many ITRs would have cached the locations of the
authoritative nameservers for some or many of these 16 subdomains.
That would greatly reduce the load on the /8 RIR server.

So I think your attempt to have the RIR server know about so many
subdomains dooms it to be asked far more often than would otherwise
be the case.  This creates a global performance bottleneck, in this
case, a separate one for each /8.

looking at your IPv6 example in the same light, the figures are more
extreme.

Your first asked server is authoritative for a whopping /12 of IPv6
space.  It gives an answer about what server to ask, solving another
 36 bits of the ITR's problem:  it tells the ITR the address of
another server to ask, which is authoritative for a /48.

Do you expect this /12 server to know about (a theoretical maximum)
of 2^36 subdomains?  That is an awful lot.

Again, this server is going to be hit for a large proportion of IPv6
initial mapping enquiries, because it doesn't delegate to other
servers which themselves cover a substantial fraction of its space -
such as 16 servers for /16 prefixes.   These would tend to be cached
by ITRs and most subsequent queries would go to them, rather than to
the /12 server.

In your example the /48 server knows enough about its subdomains to
give the full answer - right down to 112 bits.  That is a huge jump-
but I guess we can assume that the huge space this involves will be
only sparsely populated by actually used addresses, and therefore
sub-domains.

Overall, I question how your collapsing of what would otherwise be a
long series of lookups into two or three will be problematic in
terms of:

1 - The business and therefore trust relationships probably
    go in steps of fewer bits than the large jumps in bits
    you use in the examples - raising questions of how the
    short-prefix nameservers get to be reliably configured with
    so much detailed information which is actually controlled
    by so many ISPs or end-users.

2 - How this collapsing thwarts the ITR's ability to cache
    a larger number of nameservers which will actually be
    used in subsequent requests - thereby requiring it to
    keep asking the /8 (IPv4) or /12 (IPv6) servers time
    and again.  The same goes for the world's ITRs and so
    these servers get a hammering.

  - Robin



--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg