[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures




CEF was not created because caching failed. It was created because the way caching was implemented was not optimal.


Excuse me? Caching failed miserably. Per-host caching was growing to be larger than the number of prefixes in the RIB, and per-prefix caching would have covered 80% of the RIB.

Caching is NOT worthwhile when the working set is 80% of the full table.


It was not a question of having a partial table (i.e. cache) versus a full table (i.e. a RIB's worth of data), but how the forwarding table was populated.


The population was expensive, but originally it was deemed worthwhile because the cached lookups were faster and certain folks didn't know how to do a tree walk and there was no regard for the resulting space complexity when used in the core. The original host cache was simply designed for the enterprise and made no sense anywhere else. In fact, even in large enterprises, there were issues simply due to the number of hosts and the smallish number of cache buckets originally allocated.


1) Populate the mapping cache for active flows only.
2) Install a default mapping cache entry that points to an ETR that has more mapping
   entries.
3) Put all mapping entries from the Internet into the site ITR.

DNS does 1), CEF does 3), and 2) is done by doing a hybrid. We can swing on this pendulum based on traffic patterns. But here are the disadvantages of each:

1) Data-plane induced requests cause population. So latency is incurred. But latency
   is only for the first destination site request.
2) Stretch is increased to not require all ITRs must have a full table. 3) Requires lots of memory to store all mappings so latency can be eliminated. Solving
   this in one in scalable way will help scale xTRs in 2).

So choose your poison, you have to make a hard decision. So we start with caching and if the cache gets as large as full table, then we have moved the pendulum full swing.


Or.... you cache in some locations, where the working set is small and you can afford latency (which, as we've discussed many times, can be further eliminated by piggybacking the mapping request with the DNS request) and you have other locations that get a partial or full feed. [Sean Doran will note that this is Yet Another Problem That Was Already Solved Once For NNTP.]

The nice thing about this approach is that you make this "hard decision" on a per-box basis, so that you don't have to make one decision for the entire 'net. Ya pays your money and you get service proportional to the money that you put in...

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