[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] thoughts on the design space 3: caching
- To: rrg <firstname.lastname@example.org>
- Subject: [RRG] thoughts on the design space 3: caching
- From: Jari Arkko <email@example.com>
- Date: Thu, 24 Jul 2008 15:23:10 +0300
- User-agent: Thunderbird 188.8.131.52 (X11/20080505)
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
to unsubscribe send a message to firstname.lastname@example.org 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