Bill
> My objection is that you've expressed a misunderstanding of the > difference between a cache and a database. My point is to prevent from hiding the fundamental issues of caching behind system-/implementation specifics without looking at the broad picture. Leaving outside the problem of comparison with CEF for a moment (because I think it resulted in adding more confusion than add any clarification), I think we are in disagreement on the description of a cache: once a subset of entries from a full set is (re-)placed such that it can be accessed faster than the initial set (the requestor benefits from speed-up access/transfer of these entries), one speaks about a cache-based system. the cache implementation itself is not actually relevant at this level of description (it can be a set of records in a table, memory entries, etc.) > You're conclusions will be constrained by that definition. Because > you've made the terms equivalent, > > you won't be able to draw meaningful distinctions between them. > > >> 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. > > This is a subtle but very important point. If the top of the hierarchy > has a full database then it isn't a cache. And if the top of the > hierarchy is the only set of nodes with a full database then it isn't > a distributed database, it's a central database and the other levels > of the hierarchy are caches. We have a different definition of a centralized database and distributed database i think. A distributed database that includes temporarily or not the full information set does not result in a centralized system. So, I would leave people to comment here. > >> 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. > > Concrete example please. Is there an XYZ cache in IOS 12.9? Does JunOS > have a competing cache that works differently? There are past and ongoing experiments with such associative caches - does that make the case more real ? or is the reality limited to Cisco IOS or other commercial OS ? > If you replace 3.4 push/pull/hybrid with 3.4 pull local-central, pull > local-distributed, pull remote-central and pull remote-distributed, > you'll be closer. As said above pull local/remote from the forwarding point of view copes with the read operation. what about the operation needed in case of routing information change pushed downward onto the FIB (not triggered by a change in dest. addresses but routing topology) ? I would have better covered cases where the database either local or remote has an complete or an incomplete set (being a superset of the working set but smaller than the full set) rather than speak about central and distributed databases. > However, the BGP RIB still isn't an example of a database supplying a > local-central pull cache. > > In Cisco fast switching, the cache is pulled from the router FIB, > *not* the BGP RIB. Nor is the FIB a direct derivative of the BGP RIB. > The router FIB is constructed from *multiple* protocol RIBs including > the connected RIB, the static RIB, the OSPF RIB, etc. The point is known (forwarding cache entries are pulled from the FIB derived from RIB/s) and i don't think we disagree. Note: initially my assumption was to speak about mapping distribution independently on how they are used to build the working set e.g from FIB via one or multiple levels of indirection from RIB->FIB. By BGP it was meant they are known locally by DNS they are queried if unknown locally. We have been mixing the networking-level vs system-level description. So, I will use a system-level description to prevent us diverging from the real issues in cache-based systems. Indeed, once we agree on this description, we are left with the fundamental problems of caching: 1) impact of the variability of the information source itself (FIB). So, what is the dynamics of placement/replacement of the cache entries in addition to the traffic spatial distribution. 2) impact of the granularity of the entries that results in trade-offs between higher replacement rate vs working set size (and so cache size). 3) which strategy to populate an alternate cache (in case of failure of the primary cache): proactive (pre-fetch and keep re/placement as for the primary cache) or reactive (after failure and progressively populated). Thanks, -dimitri. _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
