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
