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

["Tony Li" <tony.li@tony.li>]

Hi Bill,

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


True, I should have said for each connection...


|Doing a lookup for every packet would be asinine.


But that's no reason to be rude about it.


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


Good point.


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


The issue, IMHO, isn't the delay, it's the scalability, especially in front
of hot spots like Google.  In these cases, it would make sense to have a
hybrid mapping, where we can install full mappings at hot spots.  

Note that it's not exactly analogous, as hosts.txt (at least on some systems
;-) needed a manual update.  This would be more equivalent to a mapping
crawler, so that the cost would really be in the state being held.


But, we again digress into mechanism.

Tony


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