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