Bill, > Accordingly, Dimitri's section 3.4 push acquisition of cache data from > the BGP RIB is invalid. No such system ever existed, so any > description of it's operational properties would be false.
This is not what I suggest (referring to my previous post): "...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," Reason: the RIB is the source of information for where cache entries are derived whereas the pull operations are traffic driven from these "derived" entries. > What did exist was a destination address to next hop cache pulled from > the local-central FIB database. This would lead to an incomplete anaysis: by limiting caching system analysis to forwarding cache entries wrt traffic dynamics (e.g. exploration effects) one misses the impact resulting from routing topology changes for ongoing traffic flows. The latter point is exactly one of the issues that have been extensively discussed during last GROW meeting (another is the exploration effect). Thanks, -d. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of William Herrin > Sent: Sunday, December 21, 2008 9:36 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 1:09 PM, John G. Scudder > <[email protected]> wrote: > > On Dec 21, 2008, at 12:53 PM, William Herrin wrote: > >> 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. > > > > We have real-world operational experience that says otherwise. > > John, > > Maybe. The past two years of research on RRG suggest that conclusion > is in error, that you have in fact missed something. If we test with > the proper methodology, one possible outcome is that you're right and > RRG needs to exclude a whole set of solutions that are currently on > the table. If instead we make intuitive leaps in our methodology, only > one outcome is likely: garbage in, garbage out. > > The fast switching route cache talks to the FIB and the FIB talks to > the protocol RIBs. Those are the system boundaries. If you want to > examine the behavior of the cache, the function of the RIBs is out of > scope, hidden behind the behavior of the FIB. > > > >> 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. > > > > To extend the analogy, do you mean to assert that the engine has no > > relevance to the behavior of the boxcar? > > The boxcar is not pulled on the vector the engine travels. Instead, > the boxcar is pulled on the vector the car in front is traveling. Pay > attention to the engine and you'll incorrectly expect the boxcar to > derail at the first turn. > > Pay attention to the BGP RIB in caching systems that don't directly > interact with it and you'll deduce caching behavior in proposed > protocols which is not a credible result of those protocols' > operation. > > > > To expand on this comment slightly, I don't mean to assert > correlation > > between BGP activity and cache activity. What I do mean to > say is that > > experience with fast switching (and similar) is very > relevant to thinking > > about any other cache-based forwarding scheme, whether the > "engine" (to use > > your analogy) is BGP or some other map distribution scheme. > > Our experience with how the fast switching cache interacted with the > router's FIB is indeed very much on point. It is one of the very few > examples of pull-cache that is directly related to routing. But it > isn't related to BGP or Interdomain routing. > > Fast switching failed in much smaller configurations too. As we seek > to understand why, we should avoid confusing the issue with irrelevant > information. > > > I object to treating BGP as a source database which pushes information > into a cache unless an example of such a system in fact exists. Fast > switching is not such a system. It pulls, not pushes information from > the router FIB, and it interacts with the FIB, not the BGP RIB. > > Accordingly, Dimitri's section 3.4 push acquisition of cache data from > the BGP RIB is invalid. No such system ever existed, so any > description of it's operational properties would be false. > > What did exist was a destination address to next hop cache pulled from > the local-central FIB database. I think it's very important that we > learn why that failed when it's sister system, the DNS, has performed > so well. I think we'll find clues to that answer by examining other > successful and more importantly, unsuccessful pull-cache systems that > aren't necessarily related to the Internet. > > > My theory, by the way, is that the DNS did encounter the same problem > as fast switching around the same time. Because DNS caches operate > near the edge where cache miss loads aren't impossibly high and > because the DNS runs on general purpose hardware instead of > purpose-built appliances, the software developers were able to > quantify rogue behavior in a way that was efficiently detectable. > Rogue behavior was simply too many cache misses per second from the > same source. They implemented detection and blocking code, and the > problem went away almost before it began. > > We'll see if my theory pans out. > > 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
