Re: [RRG] cache issues in LISP and CONS - it's bad . . .

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

Hi Bill,

Thanks for your response.  Even if most of the TRRP map lookups take
200ms or so, and if the ITRs hold the data packets and send them
when the mapping data arrives, the system will be slower than
LISP-NERD, eFIT-APT and Ivip.  As I understand LISP-CONS, packets
for which there are no mapping are dropped, which would be much
slower in general than TRRP holding packets to wait for mapping
data, since each attempt at establishing a TCP session will involve
multiple time-outs and retries.

What about the recursion of looking up such a depth of TRRP servers
with IPv6?  Each four bits requires a new level of nameserver.

I guess the ITR keeps drilling into this tree of nameservers until
it finds one which is authoritative for the address it is seeking
mapping for.  Assuming the TRRP-mapped address blocks (each
of which contains one or probably more micronets) are /32, this
still involves 8 levels of server recursion.  I understand the ITR
would probably have cached the addresses of the first few levels of
this, but it still involves a likely drilling into four or so
levels.  If so, then my example, showing two levels of recursion,
would be a better than average case.

If there was a single, unified, global system of anycast servers
(anycast on the same IP address), each with their nearby BGP
router advertising the one /24 in which all those servers have their
addresses, for the top level domains, then this would reduce the DNS
lookup time somewhat for far-flung hosts.  I think it would
partially solve the problem I point to in my example of each
nameserver farms relying on a caching ITR to send packets back to
the sending host.

From Australia, New Zealand and some other countries there might be
an anycast TLD server farm in Sydney.  The TRRP ITR there would
have a better chance of caching the mapping information for sending
responses back to hosts in the region for several reasons than an
ITR of the current TLD nameservers.

Firstly.  Most (all?) of the requests the farm handles would come
from the Australia-NZ region, which involves a relatively small
subset of the total address space.  Therefore, for a given memory
capacity and/or query traffic limit, the ITR of the farm can retain
the mapping details for longer for these addresses than could an ITR
of a single global (actually a few global) TLD nameserver.

Secondly, by implementing nameservers for most or all TLDs in these
anycast farms which share the one TRRP ITR, it is much more likely
that the ITR will already have cached an Australian sending host's
mapping information when the host is sent a response for the .ru
nameserver there, because the same host would have been recently
getting responses from the .au server in the same farm.

For many lookups, this would mean there is only one level of
recursion required - to find the .xxx.com.au server, and then to ask
it the IP address(es) of www.xxx.com.au.  I guess that most DNS
lookups today involve a depth of three or four - four for
www.xxx.com.au.

I will discuss your TRRP deployment plans in a separate message.

I had never heard of SWAG.  I figure you meant Scientific Wild Assed
Guess, but there are others to choose from:

http://slang.acronymfinder.com/af-query.asp?acronym=swag&string=exact&s=r

including "Still Wondering and Guessing"!

    - 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