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

["William Herrin" <bill@herrin.us>]

On Sat, Feb 23, 2008 at 10:33 PM, Robin Whittle <rw@firstpr.com.au> wrote:
> Short version:  How TRRP's DNS system could be souped up to
>                 provide much faster response times.
>
>                 This involves integrating the nameservers and
>                 anycasting them all from multiple sites around the
>                 Net.  The result is a hybrid push-pull query server
>                 network.

Hi Robin,

In a word, yes. For all of the reasons you list in the long version of
your post, what you describe is a viable way of scaling up the middle
layers of the TRRP DNS hierarchy to handle pretty much any imaginable
projection of the routing system load. That scale-up is possible from
day-one, without needing to make any adjustments to the protocol.

There are at least a few other ways to scale the system up depending
on the balance between cost and performance that users are willing to
tolerate. Conveniently, these methods are all compatible with each
other so an AS who wants more performance can have it while an AS who
would prefer to push the cost down instead can have their wish too.
That moves the cost/benefit decision out of the architecture level and
in to the operations level where it belongs.

Here's some good news: it's unlikely that such a scale-up would ever
be necessary. The APT researchers report a miss rate under 1% for as
little as 4000 cached entries. Having worked with caching systems
before, this is not out of the ballpark. TRRP gains the same kind of
benefit, but deployed in COTS hardware with gigabytes of memory it can
maintain a substantially larger cache.

Even if caching failed us for some unforeseeable reason, we could
compose a v4.trrp.arpa consisting of the top 50k /24's and wildcards
to the /8 level NS servers for the rest. Such a cache-helper zone
could be pushed relatively cheaply to as many ASes as wanted it
without disturbing the protocol.

Here's some better news: the churn rate for these middle layers is low
enough that we could get away with pushing an update as rarely as once
a day. Once per hour is perhaps more likely for the sake of
convenience. Even if the operational realities incent us to push
updates to geographically dispersed servers, they'll be really cheap.

Remember, multihoming, traffic engineering and mobility happens at the
bottom layer of the TRRP hierarchy. The middle and top layers only
need to support major reconfiguration.

But even if we did end up having to push the data in the way you
describe, there is still no single device that has to handle move data
than COTS hardware is capable of. There are no $10M routers or map
servers required in TRRP's architecture no matter how far it scales.



>  The /8 and the /24 servers in the same racks - so why not modify the
>  /8 ones, and make them talk to the relevant /24 one, to return the
>  complete answer with the response to the first query?

I suspect for the same reason the GTLD servers aren't modified to
query the second-level servers on behalf of requesters. But if
performance is sufficiently enhanced by such an activity it could be
done without changing the protocol.


>  Around this time, you will probably be thinking . . . if we could
>  only speed up the rsync system, we could enable the end-users to
>  have fast enough control of the ITRs to provide Mobility.

That's already tackled in a different direction with preemptive change
notification (PCN). http://bill.herrin.us/network/trrp-preempt.html

Two key tasks for a mobility system are:

1. Manage disconnection so that the systems with which a mobile device
is communicating don't quit communication while waiting for the device
to become available again.

2. Quickly push knowledge that a change in location has occurred out
to the systems with which the mobile device is communicating.

TRRP partially addresses #1. My best guess is that #1 would require
either a significant change in the IP stack or some landed station
would need to take over for the mobile station upon detecting
disconnection so that it could close the TCP windows and do similar
tasks which cause the servers communicating with the mobile station to
pause their transmissions without disconnecting. TRRP makes the latter
process relatively straightforward: simply change the ETR entry for
that mobile device.

TRRP directly addresses #2 with PCN. Because of the authentication
complexity, PCN doesn't push the change out to the ITRs using it.
Instead, it pushes only the knowledge that the cached entry is stale
and must be updated with a new query.


>  > The worst case of this problem is precisely the dot-com zone
>  > problem which is already solved and deployed at an operations
>  > level.
>
>  Do you have any references on how they do this?  I couldn't easily
>  find technical information on what software they use for the
>  nameservers, or how the .com database is maintained and somehow made
>  accessible to multiple registrars.

Dot-com and dot-net are generated out of a central SQL database
maintained by Network Solutions if I remember right. The various
registries have access to an API that lets them add and remove
information. An hourly dump is done into a zone file which is
distributed to the contractors running the gtld servers, some anycast
some not.

The details are probably buried in NSI's contract with ICANN somewhere.


>  Ivip needs more protocol and software development and an up-front
>  deployment of servers by some sort of consortium to get started.
>  I like to think this can be done due to the enthusiasm generated by
>  a system which promises to fix the routing scalability problem,
>  provide many more end-users with multihoming, portability etc.

I'd like to think so too, but the pragmatist in me won't allow it.
We'd have safe, efficient autodrive cars if only we had a passenger
car-sized rail system for them to run on. It's not that we couldn't
build such rails or even that they'd be more expensive to build and
maintain than asphalt roads. It's that we have a massive deployed
infrastructure of asphalt roads and no deployed infrastructure of
passenger car-sized rails.

Ideas can be revolutionary but infrastructure construction must by
necessity be evolutionary. It's like the way to Millinocket, "You
can't get there from here."

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin@dirtside.com  bill@herrin.us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

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