[RRG] thoughts on the design space 3: caching

[Jari Arkko <jari.arkko@piuha.net>]

One of the conclusions that I drew from our exercise was that caching 
mapping resolution is the culprit for many of the issues. Deterministic 
packet delay/drop, for instance. And the source of most of the 
complexity. Can we rethink some of the solutions in this light?

It seems that we have bundled the design of our encapsulation and 
mapping protocols with the way routers arrange their forwarding cache.

First, I am not at all convinced that we actually HAVE to employ a cache 
for the forwarding lookup. The designs such as LISP are based on the 
idea that a subset of routers has to do more work than most routers in 
the Internet. This may be all that is needed; build those routers with 
the capability to have a full table. The rest of the routers will only 
need minimal amount of memory. If you believe this, then something like 
LISP + NERD would be far simpler and efficient than the other alternatives.

Hasn't the industry built caching routers before, and what happened to 
them? Think we need a second try? I have not seen any ideas on how to 
remove the problems inherent with the caches, such as vulnerability to 
being hit by random destination addresses.

Second, even if you believe that we DO need a cache, there's really no 
reason why the cache design has to be cast into the rest of the 
architecture. Even if your forwarding ASIC can't employ enough memory 
for all the entries, I have a hard time convincing myself that we can't 
have a general purpose computer sitting next to it that holds the full 
table. I'm writing this on a laptop that has a 160G disk. That would be 
enough for several mapping tables containing EVERY IPV4 ADDRESS.

Third, if you believe we must use an alternate topology for routing the 
initial packets while we are fetching for the cache entry, is that 
alternate topology a global infrastructure or a local device? Again, I 
have hard time getting myself convinced that we need to build a global 
infrastructure. The cost of the infrastructure is immense, and if you 
use the current BGP infrastructure you end up keeping there precisely 
the information that you wanted to get rid of. My take is that if you 
cannot build an ITR/ETR that holds the entire mapping table in memory, 
maybe it would be better to attach it to a general purpose computer that 
can (slowly) handle the cache misses and hand the packets back to the 
router.

Jari


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