Hi Bill, > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of William Herrin > Sent: Sunday, December 21, 2008 4:16 PM > To: PAPADIMITRIOU Dimitri > Cc: [email protected] > Subject: Re: [GROW] Operational experience with cache based mapping ID > > On Sun, Dec 21, 2008 at 4:58 AM, PAPADIMITRIOU Dimitri > <[email protected]> wrote: > > I meant that the working set is extracted/derived from the > BGP routing > > database. > > > > To remove the confusion, I suggest to consider i) pull from local > > database (e.g. BGP RIB) - one could refer to local pull, > ii) pull from > > remote databases (e.g. DNS) - one could refer to remote > pull, and as I > > stated in my previous post iii) "hybrid pull-push" to cover > the case of > > proactive cases. > > > > Would that work for you ? > > Hi Dimitri, > > Not really, no. > > Are you aware of any examples of a cache coupled with a BGP RIB? > Generally we see a full database conversion to produce the local FIB > and we see direct queries for diagnostics such as a looking glass. On > occasion we also see defined database subsets propagated towards a > peering-only router. None of these activities exhibit the > characteristics commonly understood to be a cache.
Cisco Express Forwarding (CEF) to give one of the best known example. > If no such system exists, we can hardly report on its > operational properties. > > The key elements of the matrix seem to be: > > * Pull, pull with extra, speculative push. > > All caching systems exhibit pull, pull with extra or both. Some also > have speculative push. > > Example of pull: ARP request and response. > Example of pull with extra: DNS request and response with > "additional" section. > Example of speculative push: cache page invalidation due to a write to > another CPU's cache in a multi-CPU system. No difference here with the initial segmentation proposed, you can add a pull with metadata but there is no fundamental difference. > * Local database, remote database. > > The major difference between a local database and a remote database is > that lookups to a local database are expected to succeed with a high > enough probability of success that it can be considered a > critical-stop failure when they don't succeed. > > 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). > * Central database, distributed database. > > Example of a central database: A SQL server. > Example of a distributed database: Virtual memory: multiple swap files > on different hard disks. > > Note that some virtual memory architectures treat DRAM as a cache for > virtual memory while others treat DRAM as one element in a distributed > database. > > For the former, the swap must be at least as large as the DRAM and the > swap page is allocated at the same time as the DRAM page. In the > latter, space in the swap file is not allocated until you want to > remove a page from DRAM. 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. > > -> 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. Other than this DRAM-CPU and routing cache-RIB system are both driven by associativity, replacement and pre-load/pre-fetch Regards, -dimitri. > Regards, > Bill Herrin > > > -- > 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
