Re: [RRG] thoughts on the design space 4: encapsulate vs. translate

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

On Fri, Jul 25, 2008 at 7:31 PM, Tony Li <tony.li@tony.li> wrote:
> Fair.  I think it's also fair to assert that the number of identifiers that
> we need to support is linear with the number of hosts (and thus hostnames)
> that we need to support.
>
> Further, we can assert that DNS supports mappings of this scale and does so
> in a caching fashion.  However, DNS is NOT invoked for anonymous
> transactions and if it was, it would not scale appropriately.  Imagine
> Google doing a reverse DNS lookup on every packet it receives, for example.
>
> Do folks agree?

Tony,

That's not an equivalent comparison for two reasons:

1. You don't do a lookup for every packet; you do a lookup for the
first packet in a time-bounded series. That's true for both the
query-cache map proposals and the DNS. Doing a lookup for every packet
would be asinine.

2. Reverse-DNS lookups are often -much- less efficient that forward
lookups. Hierarchy servers for forward lookups are typically held
together with glue to in-scope servers, so they go fast. Reverse
lookups are held together with servers from the forward hierarchies,
so for each level you descend in the reverse hierarchy you have to go
do a full traversal in the forward hierarchy to find the server
address. That's an operations deficiency rather than a protocol
deficiency. The reverse hierarchy could have been built with glue, but
no one perceived a need.

Despite that, you make a fair point.

The counterargument is this: for virtually every packet google
receives, the origin has already performed a DNS lookup in order to
get that far. If the first-packet time is already slowed to DNS-time,
what's the harm in a second lookup? Especially when the alternative is
hosts.txt.

There are counterexamples to that but they tend to cluster in three areas:

1. Local administrative access by IP address. That's out of scope
here: the map-encap protocol is used on non-local situations.

2. Protocols like bit torrent where the remote IP address has been
discovered through some other kind of lookup protocol. A mild lag in
bit torrent's initial connect to a new peer makes no difference to
anyone.

3. Worms hunting for machines to infect. No only don't we care if
these are delayed, we'd prefer that they be delayed. Forever if
possible. ;)

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