Bill, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of William Herrin > Sent: Sunday, December 21, 2008 6:53 PM > To: John G. Scudder > Cc: PAPADIMITRIOU Dimitri; [email protected] > Subject: Re: [GROW] Operational experience with cache based mapping ID > > On Sun, Dec 21, 2008 at 10:29 AM, John G. Scudder > <[email protected]> wrote: > > On Dec 21, 2008, at 10:26 AM, William Herrin wrote: > >> Not so. Cisco fast switching implemented a cache coupled with the > >> router's FIB. The FIB was constructed in part from the BGP > RIB, but it > >> was its own full database. > > > > Seems like an unimportant difference in terms of system > dynamics but maybe > > I'm missing your point. > > Hi John, > > The point is that the methodology is incorrect. They're not coupled. > The BGP RIB-level activity implies nothing about the fast switching > cache-level activity and vice versa. If you want to understand the > operational characteristics of caching, you'd be looking in the wrong > place. > > Looking at cache to RIB, best case you glean no useful information. > Worst case you find correlations that imply a false causation matrix, > contaminating any decisions you make with the information. > > Think of it like a boxcar on a railroad. If you want to understand the > behavior of the boxcar, you don't look at its relationship to the > engine. You look at its relationship to the car in front, the car > behind and track below. > > > > On Sun, Dec 21, 2008 at 10:55 AM, PAPADIMITRIOU Dimitri > <[email protected]> wrote: > >> Are you aware of any examples of a cache coupled with a BGP RIB? > > Cisco Express Forwarding (CEF) to give one of the best > known example. > > No, CEF is an example of a full FIB database. Don't expand the > definition of a cache to the point where it is indistinguishable from > the database to which it is subservient. You would render any > conclusions you reach into gibberish and we'd be right back where we > started with no way to evaluate the efficacy of LISP's route caching > proposal.
I do not understand anymore where the objection is in your arguments: - is it the issue of whether CEF or alike itself is not associated to a caching system ? in my view a system that "routes the first packet and switches the next packet of a given data flow" relies on a mechanism where there is an intermediate entity storing a subset of the information and that can be accessed faster than from its initial location. As a matter of comparison in LISP: if the first packet arrives at the ITR but no local mapping entry in the mapping cache, lookup is performed to populate the mapping cache. - is it the issue of data traffic/packet-driven vs routing/control-driven replacement ? in my view the kernel of the problem of such system is the correlation between incomin traffic destination prefixes (that issues read operations) and reachability information dynamics (that performs write operations) and that problem is common to CEF or other similar systems that RRG is currently investigating. ... or is it the issue that we do not have any system coupled with routing information base ? > >> * Pull, pull with extra, speculative push. > > > > No difference here with the initial segmentation proposed, > you can add a > > pull with metadata but there is no fundamental difference. > > Would you argue that when I request the route for a particular > destination IP address, there would be no operational difference > between a caching system that returns the next hop for the requested > IP address and a caching system that returns the next hop for the > prefix containing that IP address? > > Meaning no disrespect, I think you've placed a conclusion ahead of the > research here. I don't mean this. I simply refer that the addition of metadata can be of importance it remains a pull operation. Dependency on the cache entry themselves may be analysed for sure. > >> Example of a local database: DRAM on a computer. > >> Example of a remote database: DNS. > > > > So, basically we have local and remote databases. Something > different > > from the above proposal ? > > This said local dabases do not resume to DRAM any Local > Information Base > > can be considered (the case with cache entries derived BGP routing > > entries is a good example). > > Yes, there is something different. With a local database, there is > little or no error recovery between the cache and the database. As a > result, error recovery is not a factor in evaluating the cache's > behavior. With a remote database, the impact of error recovery is a > huge factor. So I think you agree with the point made: there are local and remote databases. > >> * Central database, distributed database. > > I fail to see why we would have to consider non-colocated central > > databases for a networking system that is by definition > distributed - > > afaik the document does not intend to cover (e.g. file) caching for > > centralized IT systems. > > Elements of some of the proposed solutions on RRG place a supposed > cache at the top level of the database distribution hierarchy. In > reality, the top of the hierarchy ends up functioning as a remote > central database of routes from which each encoder caches a working > set. > > When evaluating those proposals, you will want to understand the > implications of a central versus distributed database. You'll also > want to be able to recognize when part of what the author has proposed > is not functionally a cache at all, even though he describes it that > way. I view this as a particular structure of a distributed set of remote databases (in the form of distributed hierarchy). By central database one usually refer to a single repository. > >> > -> Associativity (Direct mapping, Fully/N-Way/Skewed) > >> > >> Can you offer examples of associativity outside of CPU caches? The > >> ones you've mentioned here are all very specific to issues > that arise > >> when trying to deal with mapping CPU cache pages to DRAM pages. > > > > A routing cache differs from a DRAM because the former only requires > > Read from the Forwarding engine while the latter supports > R/W from the > > CPU. The application (routing) makes also the system > specific wrt to the > > dynamics of the routing table compared to the DRAM-CPU system. > > Maybe I didn't explain myself well. Let me try again: > > With routing algorithms, we use netmasks instead of specifying a > generic range of IP addresses with arbitrary starts and ends. We do > this because the hardware logic to implement netmasks is much simpler. > > CPU caches face a similar problem keeping track of which range of > memory a particular cache page represents and which range of memory a > nearby cache page should represent. This is called the associativity > issue. Fully, n-way and skewed are examples of constraints on the map > between CPU cache and DRAM which simplify the hardware logic that > implements the cache. The associativity (or equivalently the placement and location tracking of a cache entry) is a common trade-off in any caching system: on one end of the spectrum full associativity on the other end of the spectrum direct mapping. > I propose that this associativity issue is unique to the PC memory > management domain. Issues which appear in only one caching problem are > a property of that problem domain, not a general property of caching > systems. Because we don't want to confuse the issue with irrelevant > information, we should not consider associativity as part of the > report on caching systems. > > I ask you to falsify this proposal by offering a concrete example of > one associativity issue in a well known caching problem domain other > than PC memory management. Associative caches for IP routing is one example here among others. > > Imho such document can provide for an analysis grid of what > is currently > > ongoing at RRG (or even at other groups) based on experience. > > Refer to http://bill.herrin.us/network/rrgarchitectures.html for a > grid of current activity on RRG. Note that this document does not > address operational experience at all; it just describes the > architectures that have been proposed. I have read this document. It may serve as basis for such analysis. Regards, -dimitri. > Regards, > Bill Herrin > > p.s. Dimitri, I sent you another copy of my 12/3 message. If you > didn't receive it, please check your spam folder and/or your server > rejection logs. PS: i got it and will take a look at it. > -- > William D. Herrin ................ [email protected] [email protected] > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
