From owner-Big-Internet@munnari.OZ.AU Fri Nov 3 08:45:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17060; Fri, 3 Nov 1995 08:45:19 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA00438; Fri, 3 Nov 1995 08:44:42 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00432; Fri, 3 Nov 1995 08:42:39 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17007; Fri, 3 Nov 1995 08:42:31 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22139; Thu, 2 Nov 95 16:14:18 -0500 Date: Thu, 2 Nov 95 16:14:18 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511022114.AA22139@ginger.lcs.mit.edu> To: flows@research.ftp.com Subject: "hard" and "soft" state Cc: ddc@ginger.lcs.mit.edu, jnc@ginger.lcs.mit.edu, jtw@lcs.mit.edu Precedence: bulk On reading "Architectural Considerations for Mobile Mesh Networking" draft-rfced-info-corson-00.txt), I suddenly realize that the terms "hard" and "soft" state were perhaps not as clearly defined as I'd be happy with. In fact, the lack of clear definitions seemed to be causing communication problems, as people used the terms to refer to different internal functional models, with the obvious result! I've had a number of conversations with people about this, and I thought I'd try and pass along the results, in the hope that they might prove useful. I hope everyone will find the time to read this, as I think the conclusion is fairly important to clear communication when using these terms and concepts. I'm using the "flows" mailing list as the primary channel for this, since it seems to be more appropriate than any other to this kind of generic question, but I will BCC it to "Big-Internet" to improve the coverage of what seems to me a fairly important point. The document startled me by seeming to use "soft" and "hard" to refer in part to the method by which state was maintained (i.e. probabilistically versus an explicitly reliable mechanism), and in part to refer to the duration of the state, viz: "hard-state" protocols, meaning that in the absence of some event to trigger a protocol response, the protocol's state will remain unchanged or "hard" for an unbounded time period. (The document does not define "soft state" explicity, or indicate which of the documents which does define that term it was using for the definition.) This all confused me, as I had always though "soft state" referred to state that could be discarded by the routers as a local decision (e.g. because it was out of room), and the user would continue to receive service, albeit perhaps at a degraded level. This always seemed to me the most important attribute of "soft state", since to me how one maintains state is a more mechanistic question, whereas the question of whether the state is needed for operation (at whatever level of quality) seemed more fundamental. So, I went to look at the relevant papers, to see what they said. The original paper which defined the term ("Design Philosophy of the Internet Protocols", by Clark), said: "the state information associated with the flow could be lost ... without permanent disruption of the service features being used." This did not clarify it for me, so I looked at RFC-1633 ("Integrated Services in the Internet Architecture: an Overview"), which defined them as: the "hard state" (HS) approach .. and the "soft state" (SS) approach ... Under the HS approach, this state is created and deleted in a fully deterministic manner by cooperation among the routers. Once a host requests a session, the "network" takes responsibility for creating and later destroying the necessary state. ... Since management of HS session state is completely deterministic, the HS setup protocol must be reliable, with acknowledgments and retransmissions. ... RSVP takes the SS approach, which regards the reservation state as cached information that is installed and periodically refreshed by the end hosts. Unused state is timed out by the routers. This left me wondering where my impression that "soft state" meant state that could be discarded without total loss of service came from. I then engaged in some side discussions with people working in this area (one of whom did agree explicitly with my characterization that "soft state" was "state that could be discarded without any warning, and the network could continue to operate"), and now have the following points to pass on. There seem to be a number of somewhat separate axes (there are obviously some connections between some of them, as you will see) along which one can characterize the state in the network. It is necessary to list them (at least, the ones that are relevant to this particular discussion, there are more :-): - How the state is maintained; i.e. whether a probabilistic mechanism is used, or a more powerful mechanism such as an explicit acknowledgement. - How consistent the state has to be among the various network nodes which have that state; this is related to the previous point, of course, since if the state can be less consistent, less powerful mechanisms can be used. - Which entity has the responsibility of maintaining that state; the network nodes the end user, or some combination thereof. - Which entity has the authority and responsibility to discard that state when it is no longer useful or needed; the network nodes, or the end user (and again, this is related to the question above). - Whether or not the state is critical to continued handling of user traffic; i.e. whether or not the user will continue to receive service, albeit perhaps at a degraded level, if the state is lost. There may be more, but those are the ones that seem to have come up so far. The term "soft state" seems to refer to a *particular* collection of choices along all these axes, and it is thus incorrect to try and characterize "soft state" along just one of them. As best I can gather, "soft state" refers to a *system* of choices in which: - State is maintained probabilistically; - State is not necessarily consistent; - The user bears the entire responsibility of maintaining the state; - The network bears the entire responsibility of discarding the state; - Existence of the state may or may not be critical to receiving service, that is likely to be a local administrative decision. If I have made any errors here, I hope some "soft-state" aficionado will correct me. I'm not sure which of this set is "more important" in terms of being a key underlying philosophical point of "soft state", and I'm not sure it really matter anyway. (I'd love to hear from some of the "soft state" aficionados any views they might have on which of these is more important to "soft state"; I wouldn't at all be suprised to hear that different people come up with different answers! :-) What does really matter is to understand that the term "soft state" seems to refer to a system with a *collection* of answers to basically disparate questions regarding state. More importantly, it is *critical* for clear communication that people realize that there are *multiple* potential systems which differ from this "soft state" model. I.e. there is no such thing, really, as "hard state", since two systems, neither of which is "soft state", may in fact be quite different from each other. For instance, I can think of one system (names withheld in the interests of preventing prejudice on the part of the readers) in which: - State is maintained explicitly; - State is necessarily consistent globally; - The network bears the responsibility of maintaining the state (if the network has a problem, the user's only option is to retry from the beginning); - The user bears the bulk of the responsibility of discarding the state (although the network must protect itself from broken users); - Existence of the state is critical to receiving service. whereas, for another: - State is maintained via a mixture of explicit and probabilistic means; - State is consistent in less global ways; - The user and network share the responsibility of maintaining the state, but with the ultimate burden falling on the user (much as the ultimate burden of retransmisison falls on TCP, although local unreliable links may do retransmission locally); - The network bears the responsibility of discarding the state, although the user will usually assist; - Existence of the state is critical to receiving service. These are clearly very different systems, but to call them both "hard state" is clearly confusing. Even more amusing, the latter system was described by one person I talked to as "close to soft-state" (or words to that effect), even though I'm not at all sure that description is warranted (as seen from the enumeration above). So, the bottom line is that "soft state" is not the name of a single characteristic, but a *package* of characteristics, and there is no *single* opposite to such a package, but many perhaps fundamentally quite different designs, all of which are "not-soft-state". Noel From owner-Big-Internet@munnari.OZ.AU Sun Nov 5 13:44:01 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02131; Sun, 5 Nov 1995 13:44:01 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21132 Sun, 5 Nov 1995 13:42:03 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA00813; Sun, 5 Nov 1995 13:39:11 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA00807; Sun, 5 Nov 1995 13:28:11 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01722; Sun, 5 Nov 1995 13:28:04 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA03020; Sat, 4 Nov 1995 18:27:54 -0800 Date: Sat, 4 Nov 1995 18:27:54 -0800 From: Tony Li Message-Id: <199511050227.SAA03020@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: IPv6 interdomain routing Precedence: bulk To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnzari.oz.au Subject: Re: New book on routing [Note: I've just moved the discussion.] > The intent for IPv6 is to extend IDRP to carry IPv6 prefixes. The AS > number is history and the "domain identifier" ;-) is simply an IPv6 Look's like, as usual I have some cat'in up do on IDRP.... I know that IDRP is planned to eventually replace the BGP development track, at least that is how the textbook reads. But, if I can step in dangerous waters, is it safe to assume that the IPv6 header is being designed to incorporate *only* currently advocated routing pardigms ? I think this is a little bit overboard. First, the design of the packet _header_ is almost orthogonal. What you care about is the design of the address and the addressing architecture. Yes, both are currently aimed at a (loosely) hierarchical addressing and routing architecture. Supposed some consulting engineer had $$$ in the bank, some time and all his bills paid and wanted to develop a super-netting paradigm (perhaps differnet than IDRP), less complex than NIMROD or IDPR [ generic note: IDPR and IDRP are not the same protocols :-)] that used prefixes in the same manner as the AS systems concept *but* was not a derivative of the BGP development track for super-netting and simplified policy routing. If that were to happen, perchance, the entire notion would be greatly aided by the exposition of a concrete proposal. This is, for example, exactly how NIMROD started... Since the idea of using 'AS style' prefixes might be (or is) considered a generic IP concept and not necessarily a BGP concept, is it appropriate to discuss IPv6 header fields in a BGP WG? Strictly speaking BGP is for doing all interdomain routing, so discussing alternative interdomain routing there _to start_ is certainly appropriate. If you want to discuss IPv6 addressing and architecture, that should be done in the IPng WG. It seems, on the surface that the 'final version' of the IPv6 header should be flexible enough that numerous inter-domain routing paradigms (there is that word again ;-) would be possible. As we've seen even IPv4 had that flexibility. ;-) In an private note, it was implied that to put these prefixes in the IP header a routing protocol that required these fields in the IPv6 header would need to be in the standards track. I can't parse this, sorry. >From this, I inferred that there is currently no IPv6 header fields that exist for supernetting IP address space. Why should there be? This assumption, perhaps wrong, leads to another assumption that the only valid future inter-domain routing protocol on the board are derivates of the IDRP development track which in turn is a derivative of the BGP development track. That's overstating the case. Certainly IDRP is the current inter-domain routing paradigm. However, it is certainly not the only "valid future". It _is_ however, by far the most likely thing to be deployed, as it has a very strong history and we cannot afford a gigantic risk in the routing architecture. Tony --SAA03000.815538383/greatdane.cisco.com-- From owner-Big-Internet@munnari.OZ.AU Sun Nov 5 15:19:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04341; Sun, 5 Nov 1995 15:19:24 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA00851; Sun, 5 Nov 1995 15:19:14 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA00840; Sun, 5 Nov 1995 15:08:21 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04104; Sun, 5 Nov 1995 15:08:14 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id XAA01281; Sat, 4 Nov 1995 23:01:13 -0500 From: Tim Bass Message-Id: <199511050401.XAA01281@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Sat, 4 Nov 1995 23:01:13 -0500 (EST) Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511050343.TAA03815@greatdane.cisco.com> from "Tony Li" at Nov 4, 95 07:43:28 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1651 Precedence: bulk Side question: my last group reply to big-internet bounced 'unknown host' Is this happening to everyone? Thanks Tony. After putting down my goofy novel and picking up the IPv6 part of the new IPNG book, I see that the Z domain is only one of a possible myriad possibilities based on the Table "Initial IPv6 Prefix Allocation' on page 222. Provider-based Unicast Addressing seems to imply renumering when providers are changed. In addition, the Provider-based Unicast Addressing infers ( unless this is wrong ) that multi-homing sites with multiple providers is a problem. All architectures that I have seen to date still presuppose that inter-domain forwarding will be a derivative of current IPv4/BGP models and development tracks. I better read the entire chapter before making this assumption, but a brief 'quick look' at the chapter appears to discuss BGP derivative forwarding. Is this because there has been no concrete 'significant other' forwarding models? Or, is the community still waiting? Thanks Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Nov 5 23:23:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17686; Sun, 5 Nov 1995 23:23:48 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA00991; Sun, 5 Nov 1995 23:22:16 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA00935; Sun, 5 Nov 1995 23:00:39 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17147; Sun, 5 Nov 1995 23:00:32 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id GAA04185; Sun, 5 Nov 1995 06:43:16 -0500 From: Tim Bass Message-Id: <199511051143.GAA04185@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Sun, 5 Nov 1995 06:43:16 -0500 (EST) Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511050716.XAA07028@greatdane.cisco.com> from "Tony Li" at Nov 4, 95 11:16:29 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3963 Precedence: bulk > > I better read the entire chapter before making this assumption, > but a brief 'quick look' at the chapter appears to discuss > BGP derivative forwarding. > > Please get this straight: BGP has nothing to do with forwarding. BGP > is the means for distributing the routing information. The forwarding > algorithm given the routes is an orthogonal issue. > > Sorry everyone, but I am not sure than the forwarding and route processing symantics in BGP are 100 percent orthogonal. Maybe I'm missing something (like brains for waking up and responding to this at this time of the morning.. Yawn ...). That may be why I am not clear on this. BGP exchanges routing tables (information).....correct? Devices using BGP to derive forwarding information forward packets by communicating with a "map" or "look-up-table" that is created by an algorithm or process loosely coupled with BGP, huh? After all, if a packet is hanging out in some buffer somewhere waiting to be forwarded and the device has no clue to where to zing the little bit stream, then the device has two choices, consult a process to get the info, or get the garbage out of the buffer, assuming no default, no last chance place to zing. Hence, (and I'm probally way off base here) but the technique for forwarding packets is loosely coupled with the way routing information is exchanged and stored. If they are loosely coupled, it is difficult to grasp how they are orthogonal; being orthogonal implies to me that the process of using a forwarding table and creating a forwarding table are completely 100 decoupled. This assumption, if correct based on a mutual understanding of terms, then leads one to believe that the choice must always be a loss of packets when the BGP process fails ( for any reason ) to create a nice warm table for the forwarding function to enjoy. In this loosely coupled process, the requirement then is to have a large forwarding table AND for devices to exchange and process a large amount of routing information to maintain the nice, robust look-up-tables. This further implies that even if a device is not forwarding packets for a particular network range at any given time, the loosely coupled processes must both exchange routing information for the idle range of networks AND maintain a look-up entry for that idle range of networks in the forwarding tables, right? This, is my mental problem with the BGP method of exchanging routing information and BGP loosely coupled sister forwarding table. What am I missing (besides a 'life' and my fiancee to be up at this hour contemplating this stuff) ? In my mind, this algorithm is inefficient (treading on land mines here, and trying to stay alive.... :-) because the devices must exchange and process information on all possible destinations even when a statistical number or range of networks are not active and my not be active in that particular device for a considerable time interval ( minutes, maybe even days....) not only are the idle networks in the exchange, but they exist in the forwarding table as well. This implies that the forwarding table is also significantly larger than necessary at a particular function of time. This also implies that this loosely coupled technique or method can never scale upward efficiently. Hmmmm. Confusion of terms? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Nov 5 23:24:16 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17708; Sun, 5 Nov 1995 23:24:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07180 Sun, 5 Nov 1995 23:22:17 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA00947; Sun, 5 Nov 1995 23:19:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA00941; Sun, 5 Nov 1995 23:12:24 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17395; Sun, 5 Nov 1995 23:12:15 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA25881; Sun, 5 Nov 1995 04:11:37 -0800 Date: Sun, 5 Nov 1995 04:11:37 -0800 From: Tony Li Message-Id: <199511051211.EAA25881@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511051143.GAA04185@dune.silkroad.com> (message from Tim Bass on Sun, 5 Nov 1995 06:43:16 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk BGP exchanges routing tables (information).....correct? Of course. Devices using BGP to derive forwarding information forward packets by communicating with a "map" or "look-up-table" that is created by an algorithm or process loosely coupled with BGP, huh? After all, if a packet is hanging out in some buffer somewhere waiting to be forwarded and the device has no clue to where to zing the little bit stream, then the device has two choices, consult a process to get the info, or get the garbage out of the buffer, assuming no default, no last chance place to zing. Hence, (and I'm probally way off base here) but the technique for forwarding packets is loosely coupled with the way routing information is exchanged and stored. Yes, but you miss the fact that it's not BGP specific. Any protocol can supply routes. OSPF works too. The forwarding algorithm is the same for OSPF routes and BGP routes. The forwarding algorithm is frequently known as "longest match". This assumption, if correct based on a mutual understanding of terms, then leads one to believe that the choice must always be a loss of packets when the BGP process fails ( for any reason ) to create a nice warm table for the forwarding function to enjoy. Basically correct, however you fail to allow for the possibility of other routing protocols. For example, it's almost a necessity to run an IGP along with BGP... In this loosely coupled process, the requirement then is to have a large forwarding table AND for devices to exchange and process a large amount of routing information to maintain the nice, robust look-up-tables. Yup, this is just hop-by-hop forwarding... This further implies that even if a device is not forwarding packets for a particular network range at any given time, the loosely coupled processes must both exchange routing information for the idle range of networks AND maintain a look-up entry for that idle range of networks in the forwarding tables, right? The latter is the practical result, not a functional requirement. One could in theory (but not in practice) not inject a route into the forwarding table until there was traffic. This, is my mental problem with the BGP method of exchanging routing information and BGP loosely coupled sister forwarding table. What am I missing (besides a 'life' and my fiancee to be up at this hour contemplating this stuff) ? In my mind, this algorithm is inefficient (treading on land mines here, and trying to stay alive.... :-) because the devices must exchange and process information on all possible destinations even when a statistical number or range of networks are not active and my not be active in that particular device for a considerable time interval ( minutes, maybe even days....) not only are the idle networks in the exchange, but they exist in the forwarding table as well. This implies that the forwarding table is also significantly larger than necessary at a particular function of time. I agree with all of the above, under the assumption that there are a significant number of idle routes in the default free portion of the BGP mesh. Note that this is a major assumption which would not be true if aggreessive aggregation is in place. I'm happy to stipulate that the status quo is not efficient, but then again, no one is really happy with the status quo, either. This also implies that this loosely coupled technique or method can never scale upward efficiently. The logic to get here needs explanation. Aren't you just begging the question? You've defined it as inefficient (with no proof) and then stated that it's not efficient as it grows. There are systems which become more efficient as they grow (e.g., a hash table becomes more memory efficient as it's more densely populated). Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 00:41:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20105; Mon, 6 Nov 1995 00:41:00 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA01098; Mon, 6 Nov 1995 00:39:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01085; Mon, 6 Nov 1995 00:25:35 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19730; Mon, 6 Nov 1995 00:25:22 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id IAA04776; Sun, 5 Nov 1995 08:19:31 -0500 From: Tim Bass Message-Id: <199511051319.IAA04776@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Sun, 5 Nov 1995 08:19:31 -0500 (EST) Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511051211.EAA25881@greatdane.cisco.com> from "Tony Li" at Nov 5, 95 04:11:37 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4137 Precedence: bulk Tim: > This also implies that this loosely coupled technique or method can never > scale upward efficiently. > Tony: > The logic to get here needs explanation. Aren't you just begging the > question? You've defined it as inefficient (with no proof) and then > stated that it's not efficient as it grows. There are systems which Yes, I have made a very big assumption that at any given point in time there is a statistically significant number of destinations in the forwarding table that are not active. I cannot prove this from where I sit. To prove that we would have to have access to a router(s) with a full forwarding table and time series snapshots of all the active connections. Then we would have to look at a large and varied sample of time to maximize the accuracy of the estimate. My assumption is based on a 'best guess' or maybe just a 'creative engineering feel', but I certainly recognize the leap in logic and the fact that I'm forwarding a big assumption. In telecommunications, from my understanding, at any given time, only a fraction of the number of possible of calls in the world populate a given switch ( I am not a switch person....) and when a big business sets up a modem bank for dial-in customers, I have been told by those who design the system that the modem/subscriber ratio is quite small because of the statistical probability of the events. I have just applied the logic of these and other communications systems, not completely without reason but assuming that at any given time in a forwarding table, their exists a similar scalar that is statistically significant in the IP world as well; and as we move into bigger address space, this scalar is possibly more statistically important. I would like to quantify this, with help from an interested service provider, but that may prove difficult. > become more efficient as they grow (e.g., a hash table becomes more > memory efficient as it's more densely populated). > I am not familiar with the relationship between hash table density and memory efficiency. Again, I am making more assumptions that seem to be natural extensions of our physical world: 1) Exchanging very large tables of routing information in order to process and create a ubiquitious forwarding table requires more processing power than exchanging statistically significantly smaller tables; and 2) The physical memory required for the above ubiquitious forwarding table also is significantly smaller based on (1); I think that it is relatively safe to assume that at any given moment in time (t), that a single device in the IP realm does not enjoy the pleasure of a datagram bound for all destinations in the IPv4 realm. This f(t) will be much smaller for IPv6. I admit that the logic might be considered weak and is based on an unproven assumption. On the other hand, it is counter intuitive to visualize a connectionless datagram network with single devices requiring ubiquitious forwarding tables at any particular moment in time. What is intuitive is the requirement that the forwarding table be able to operate as some function of time f(t). Also, please notice that I intentionally avoided the concept of both aggregation and super-netting. To explain why, consider a world with a perfectly aggregated, provider or geographical based, schema. I would advocate, it is also statistically significant, assuming forwarding is based on a simple 'not-flat' function, that the forwarding table of a 'non-flat' routing model also operates with an f'(t) similar to f(t) as in the flat model. It is intuitive, again I am asking you to believe without proof, that a more organized routing model (either provider based, geographically based, or admin-domain based....) has less entropy than a flat, less organized address space. This implies, that the fowarding table efficiency of the more organized model is greater than the less organized flat model relative to f(t). But, none the less, it is certainly possible than both models have statistically significantly inactive entries in the set of forwarding entries. -Tim From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 15:02:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23389; Mon, 6 Nov 1995 15:02:59 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01219; Mon, 6 Nov 1995 14:59:58 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01213; Mon, 6 Nov 1995 14:57:10 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23044; Mon, 6 Nov 1995 14:56:37 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA09111; Sun, 5 Nov 1995 19:54:56 -0800 Date: Sun, 5 Nov 1995 19:54:56 -0800 From: Tony Li Message-Id: <199511060354.TAA09111@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511051319.IAA04776@dune.silkroad.com> (message from Tim Bass on Sun, 5 Nov 1995 08:19:31 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk Tim, I have just applied the logic of these and other communications systems, not completely without reason but assuming that at any given time in a forwarding table, their exists a similar scalar that is statistically significant in the IP world as well; and as we move into bigger address space, this scalar is possibly more statistically important. I would like to quantify this, with help from an interested service provider, but that may prove difficult. I guess you missed my point. I will happily stipulate the point for the routing system as it exists today. Note that what occurs in practice is not pretty, but this is because we still have many exceptions to the architecture. Even so, we're making inroads. In fact, Yakov did a study some years ago that showed that only 25% was utilized. Thanks to the aggregation that we've already done, we're roughly around 40% (I just checked one backbone router). Notice this nice property: as we aggregate, the aggregate subsumes more destination hosts. As a result, you combine the probabilities of the components to obtain the probability of the aggregate being used. The resulting probability grows as the aggregate covers more sites. None of the other systems that you site have this property. Further, if we can assume a distant future where all sites participate in CIDR, then we can clearly see that we asymptotically approach perfect utilization, assuming every aggregate subsumes at least one interesting host. 1) Exchanging very large tables of routing information in order to process and create a ubiquitious forwarding table requires more processing power than exchanging statistically significantly smaller tables; and Exactly. So let's just aggregate and exchange smaller tables. ;-) Exactly what we've been asking for... 2) The physical memory required for the above ubiquitious forwarding table also is significantly smaller based on (1); True. I get the impression that you're arguing for demand population of a router's forwarding tables, which is a noble goal. However, you should ask yourself if you're willing to pay the cost of a route fault: you have to either buffer/dump the packet that caused the fault, plus you have a high latency to get the route, plus, there's overhead in installing the route in the forwarding table. As a data point, you might note that ciscos do something similar, carrying around a switching cache. Let's just say that the performance of this system in the backbone is not wonderful for the above reasons, and that's only faulting across a backplane. Imagine the ramifications of a remote fault... On the other hand, it is counter intuitive to visualize a connectionless datagram network with single devices requiring ubiquitious forwarding tables at any particular moment in time. !!! Having a least one (possibly distributed) device with a complete routing table is intrinsically a requirement of hop-by-hop routing. What is intuitive is the requirement that the forwarding table be able to operate as some function of time f(t). Also, please notice that I intentionally avoided the concept of both aggregation and super-netting. To explain why, consider a world with a perfectly aggregated, provider or geographical based, schema. I would advocate, it is also statistically significant, assuming forwarding is based on a simple 'not-flat' function, that the forwarding table of a 'non-flat' routing model also operates with an f'(t) similar to f(t) as in the flat model. I can't parse that, or follow it. I certainly disagree with your intuition. It is intuitive, again I am asking you to believe without proof, that a more organized routing model (either provider based, geographically based, or admin-domain based....) has less entropy than a flat, less organized address space. I believe the principle. I'll point out that we're talking utopian ideals here. Perhaps the most important question is the permissible amount of entropy. I certainly believe that aggregation wins over flat routing... but then again, isn't that what we've been getting at. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:00:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04988; Mon, 6 Nov 1995 20:00:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01305; Mon, 6 Nov 1995 20:00:03 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA01293; Mon, 6 Nov 1995 19:57:06 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03743; Mon, 6 Nov 1995 19:57:05 +1100 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12745 Mon, 6 Nov 1995 18:19:36 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA13245; Sun, 5 Nov 1995 23:19:17 -0800 Date: Sun, 5 Nov 1995 23:19:17 -0800 From: Tony Li Message-Id: <199511060719.XAA13245@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511060706.CAA12164@dune.silkroad.com> (message from Tim Bass on Mon, 6 Nov 1995 02:06:20 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk I was hoping you wouldn't ask Tony. I 'recoil' as you say, because you have make a statement that implies the current cisco architecture is just *bridging* to use you own words. No, not at all! I'm simply pointing out that the benefit of _routing_ is to provide scalability through hierarchy. If you've got the scalability problem licked, then there's no need for the additional complexity. ;-) More to the point, this is a reductio ad absurdum argument: if it scales well enough to support flat routing today, then it has to be able to support bridging tommorrow to handle the size of table we should expect with flat routing tomorrow. And the addresses will be smaller with bridging too. ;-) I can't argue your point without running the risk of turning this discussion into a folly. Trying to convince you that further decoupling a portion of the forwarding table from the physical limitations of a box, which is the exact same architecture that cisco has now, is futile, my friend. It should be intuitively obvious to the casual observer. Good. We agree. Then what was this entire thread about, anyways...? Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:03:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05752; Mon, 6 Nov 1995 20:03:44 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01325; Mon, 6 Nov 1995 20:03:36 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA01299; Mon, 6 Nov 1995 19:58:34 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04386; Mon, 6 Nov 1995 19:58:34 +1100 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09910 Mon, 6 Nov 1995 17:15:06 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA11661; Sun, 5 Nov 1995 22:14:43 -0800 Date: Sun, 5 Nov 1995 22:14:43 -0800 From: Tony Li Message-Id: <199511060614.WAA11661@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511060442.XAA11073@dune.silkroad.com> (message from Tim Bass on Sun, 5 Nov 1995 23:42:43 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk Can we assume that, the nice blue cisco boxes could communicate with an adjunct processor in a nice robust manner? Robust, certainly. However, that implies reliability, which implies retransmission... and the performance is an issue. [... hackery ...] I have shifted the discussion from technical details to internal cisco architecture and marketing issues and I apology for shifting gears. It is probally futile for us to discuss cisco architectural issues, so I'll take a break and get out of cisco's business :-) And I won't touch it. I'd still like to understand what you hope to accomplish by this. Yes, you can underpopulate the switching table. We've proven beyond a shadow of a doubt that this is not a good thing to do in the middle of the Internet. If I understand your proposal, it's to continue this design, increase the separation (and thus latency) and then perform flat routing. If this truly does scale, perhaps this should be a bridge, not a router. Because then you can bridge the entire Internet... And as with a telco switch, you only need to cache the addresses for the conversations that are currently occurring. Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:06:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03090; Mon, 6 Nov 1995 20:06:15 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01356; Mon, 6 Nov 1995 20:06:05 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA01296; Mon, 6 Nov 1995 19:58:12 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04265; Mon, 6 Nov 1995 19:58:12 +1100 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23315 Sun, 5 Nov 1995 14:46:18 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA03815; Sat, 4 Nov 1995 19:43:28 -0800 Date: Sat, 4 Nov 1995 19:43:28 -0800 From: Tony Li Message-Id: <199511050343.TAA03815@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511050321.WAA01021@dune.silkroad.com> (message from Tim Bass on Sat, 4 Nov 1995 22:21:38 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk I've just received an IPv6 header education, very kindly privately, and have been informed that the IPv6 basic header option field can point to an optional routing header that basically can specify just about any whiz-bang routing protocol we can dream of. Yes, as far as a forwarding decision goes... Please recall that forwarding and routing are two _separate_ functions which interact. This being the case, then my concerns for lack of flexiblity in the IPv6 header for routing are moot and unfounded. The 8 bit next-header option field provides great flexibility and appears to be perfectly simple as well. Now, on to Tony's statement that: "... Strictly speaking BGP is for doing all interdomain routing ..." Because BGP is 'current best practice' for inter-domain routing today, then any shift in inter-domain routing must, until full transition, exchange routing information with BGP peers, (I assume this is just common sense)? Yup. When changing the tires on a moving vehicle, it's vital that at least some of the tires continue to touch the road. This leads me to this question, the answer is for an unknown engineer interested in this :-): If a subset of routing domains (call the Z domains) were to peer with BGP peers ( the BGP domain ) and then map that routing information into a 'Z domain database' then: 1) Domains that peered with the Z domain and not the BGP domain could route using the 'AS domain style' mapping within the Z domain ; 2) Datagrams routing between the Z domain and the BGP domain would not need the the Z domain option field so it would be just simply dropped in the BGP domain; I would not assume that anyone every performs packet surgery. Instead, carry it and ignore it. 3) Datagrams moving between the BGP domain into the Z domain would require routers, of course that is added the Z domain header in the Z world; 4) If the concept worked well and was generally acceptable in the Internet routing community then BGP domains could (if they had good reason, of course) to transition or peer with Z domain NAPS; 5) There would be no disruption to BGP domain services, of course and BGP routing could evolve nicely to IDRP without disruption from Z domain development; This is assuming that you have interaction between BGP and Z with mutual exchange of routes. This is a key capability which you haven't mentioned yet. 6) Z domain routing protocols could develop based on the lesson learned from IPv4 and BGP routing into a TBD Z domain based protocol without interfering with the BGP domain; 7) Both Z domain routers and BGP domain routers could co-exist at NAPS as needed. Hmmmm. Besides details of the Z domain protocol and Z domain to BGP interchange, any reason why a new IPv6 Z domain could not be created? Nope. That's basically the way that we've changed tires on the car before. That's the way that it'll happen again. Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:20:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08853; Mon, 6 Nov 1995 20:20:23 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01393; Mon, 6 Nov 1995 20:20:04 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01378; Mon, 6 Nov 1995 20:11:00 +1100 Received: from zocalo.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07455; Mon, 6 Nov 1995 20:10:58 +1100 (from woody@zocalo.net) Received: by zocalo.net (4.1/Zocalo-4.0) id AA04743; Mon, 6 Nov 95 01:12:23 PST Date: Mon, 6 Nov 95 01:12:23 PST From: woody@zocalo.net (Bill Woodcock) Message-Id: <9511060912.AA04743@zocalo.net> To: bass@dune.silkroad.com, tli@cisco.com Subject: Re: New book on routing Cc: HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, sob@newdev.harvard.edu Precedence: bulk > cisco boxes could communicate with an adjunct processor in a > nice robust manner... ...currently undefined interface card that > generic unix vendors could market. Ah, but cisco sells 7500s, not Unix boxes. :-) -Bill ________________________________________________________________________________ bill woodcock woody@zocalo.net woody@applelink.apple.com user@host.domain.com From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:23:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08751; Mon, 6 Nov 1995 20:23:15 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01418; Mon, 6 Nov 1995 20:23:03 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01387; Mon, 6 Nov 1995 20:19:52 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08783; Mon, 6 Nov 1995 20:19:52 +1100 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29409 Sun, 5 Nov 1995 18:19:33 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA07028; Sat, 4 Nov 1995 23:16:29 -0800 Date: Sat, 4 Nov 1995 23:16:29 -0800 From: Tony Li Message-Id: <199511050716.XAA07028@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511050401.XAA01281@dune.silkroad.com> (message from Tim Bass on Sat, 4 Nov 1995 23:01:13 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk Side question: my last group reply to big-internet bounced 'unknown host' Is this happening to everyone? No, my typo on the first message. Sorry. Provider-based Unicast Addressing seems to imply renumering when providers are changed. In addition, the Provider-based Unicast Addressing infers ( unless this is wrong ) that multi-homing sites with multiple providers is a problem. Define "problem". It's certainly doable. All architectures that I have seen to date still presuppose that inter-domain forwarding will be a derivative of current IPv4/BGP models and development tracks. Correct. I better read the entire chapter before making this assumption, but a brief 'quick look' at the chapter appears to discuss BGP derivative forwarding. Please get this straight: BGP has nothing to do with forwarding. BGP is the means for distributing the routing information. The forwarding algorithm given the routes is an orthogonal issue. Is this because there has been no concrete 'significant other' forwarding models? Or, is the community still waiting? The sole 'significant other' is NIMROD, so far. Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:26:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09193; Mon, 6 Nov 1995 20:26:06 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01438; Mon, 6 Nov 1995 20:25:54 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01335; Mon, 6 Nov 1995 20:05:18 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06043; Mon, 6 Nov 1995 20:05:18 +1100 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11538 Mon, 6 Nov 1995 17:50:55 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA12379; Sun, 5 Nov 1995 22:49:11 -0800 Date: Sun, 5 Nov 1995 22:49:11 -0800 From: Tony Li Message-Id: <199511060649.WAA12379@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511060631.BAA11921@dune.silkroad.com> (message from Tim Bass on Mon, 6 Nov 1995 01:31:31 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk I certainly do not believe that 100 percent flat routing is the answer, yet on the other hand, I am not convinced that a 100 percent aggregated Internet is in the best interest of the Internet community. I believe that no one is arguing for either. But, as we have discussed, the issues are not technical, they are social and geo-political.... I have a feeling that steering clear of this diversion will make life more pleasant around the net ;-) > If this truly does scale, perhaps this should be a bridge, not a > router. Because then you can bridge the entire Internet... And as > with a telco switch, you only need to cache the addresses for the > conversations that are currently occurring. I disagree with your last paragraph strongly. cisco Systems currently decouples the route processing and forwarding bimodal functions... decoupling the functions physically and opening up the architecture is not congruent at all with your last paragraph and to call it bridging is quite a quantum leap in logic. I'm referring to a distributed architecture, not bridging... The fact that it's a distributed architecture is orthogonal to the layer at which you want to perform the switching decision. The point being that if it does scale the way you want, we can completely eliminate this pesky network layer. Without knowledge of the architecture described in a few paragraphs above and failing to communiate to the point of seeing the *bridge* word come up quite unexpectedly (ugh!).... You should ask yourself why you recoil. Is it bigotry or is it intuition that it's not a viable solution. Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:29:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09881; Mon, 6 Nov 1995 20:29:40 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01460; Mon, 6 Nov 1995 20:29:18 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01341; Mon, 6 Nov 1995 20:05:23 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06051; Mon, 6 Nov 1995 20:05:23 +1100 (from bass@dune.silkroad.com) Received: from dune.silkroad.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12437 Mon, 6 Nov 1995 18:10:05 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id CAA12164; Mon, 6 Nov 1995 02:06:20 -0500 From: Tim Bass Message-Id: <199511060706.CAA12164@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Mon, 6 Nov 1995 02:06:20 -0500 (EST) Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511060649.WAA12379@greatdane.cisco.com> from "Tony Li" at Nov 5, 95 10:49:11 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1729 Precedence: bulk > > You should ask yourself why you recoil. Is it bigotry or is it > intuition that it's not a viable solution. > I was hoping you wouldn't ask Tony. I 'recoil' as you say, because you have make a statement that implies the current cisco architecture is just *bridging* to use you own words. When the forwarding table is decoupled in the cisco chassis, the cisco box is a router.... but by moving part of the fowarding table two feet to the left or right... you imply that all other cisco software functions are reduced to *bridging*.... ?? This are your words and not mine. It is impossible to carry on a technical discussion when a cisco guru starts calling his main software product minus a portion of the forwarding table a 'bridge'. I can't argue your point without running the risk of turning this discussion into a folly. Trying to convince you that further decoupling a portion of the forwarding table from the physical limitations of a box, which is the exact same architecture that cisco has now, is futile, my friend. It should be intuitively obvious to the casual observer. Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:33:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10689; Mon, 6 Nov 1995 20:33:02 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA01484; Mon, 6 Nov 1995 20:32:49 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01338; Mon, 6 Nov 1995 20:05:20 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05946; Mon, 6 Nov 1995 20:05:19 +1100 (from bass@dune.silkroad.com) Received: from dune.silkroad.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10853 Mon, 6 Nov 1995 17:35:41 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id BAA11921; Mon, 6 Nov 1995 01:31:31 -0500 From: Tim Bass Message-Id: <199511060631.BAA11921@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Mon, 6 Nov 1995 01:31:31 -0500 (EST) Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511060614.WAA11661@greatdane.cisco.com> from "Tony Li" at Nov 5, 95 10:14:43 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2514 Precedence: bulk ...... the saga continues .... > > And I won't touch it. I'd still like to understand what you hope to > accomplish by this. Yes, you can underpopulate the switching table. > We've proven beyond a shadow of a doubt that this is not a good thing > to do in the middle of the Internet. If I understand your proposal, > it's to continue this design, increase the separation (and thus > latency) and then perform flat routing. It is hard to agree or disagree since I do not have intimate knowledge of the architecture that was " proven beyond a shadow of a doubt ..." in your claim above. I certainly do not believe that 100 percent flat routing is the answer, yet on the other hand, I am not convinced that a 100 percent aggregated Internet is in the best interest of the Internet community. But, as we have discussed, the issues are not technical, they are social and geo-political.... I have a feeling that steering clear of this diversion will make life more pleasant around the net ;-) > > If this truly does scale, perhaps this should be a bridge, not a > router. Because then you can bridge the entire Internet... And as > with a telco switch, you only need to cache the addresses for the > conversations that are currently occurring. I disagree with your last paragraph strongly. cisco Systems currently decouples the route processing and forwarding bimodal functions... decoupling the functions physically and opening up the architecture is not congruent at all with your last paragraph and to call it bridging is quite a quantum leap in logic. I'm referring to a distributed architecture, not bridging... Without knowledge of the architecture described in a few paragraphs above and failing to communiate to the point of seeing the *bridge* word come up quite unexpectedly (ugh!).... I'll concede that it's time to take a break on the subject at hand. Regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Nov 6 20:39:15 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12223; Mon, 6 Nov 1995 20:39:15 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07242 Sun, 5 Nov 1995 23:24:00 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA00971; Sun, 5 Nov 1995 23:21:23 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA00937; Sun, 5 Nov 1995 23:00:40 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17149; Sun, 5 Nov 1995 23:00:33 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id GAA04185; Sun, 5 Nov 1995 06:43:16 -0500 From: Tim Bass Message-Id: <199511051143.GAA04185@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Sun, 5 Nov 1995 06:43:16 -0500 (EST) Cc: sob@newdev.harvard.edu, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU In-Reply-To: <199511050716.XAA07028@greatdane.cisco.com> from "Tony Li" at Nov 4, 95 11:16:29 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3963 Precedence: bulk > > I better read the entire chapter before making this assumption, > but a brief 'quick look' at the chapter appears to discuss > BGP derivative forwarding. > > Please get this straight: BGP has nothing to do with forwarding. BGP > is the means for distributing the routing information. The forwarding > algorithm given the routes is an orthogonal issue. > > Sorry everyone, but I am not sure than the forwarding and route processing symantics in BGP are 100 percent orthogonal. Maybe I'm missing something (like brains for waking up and responding to this at this time of the morning.. Yawn ...). That may be why I am not clear on this. BGP exchanges routing tables (information).....correct? Devices using BGP to derive forwarding information forward packets by communicating with a "map" or "look-up-table" that is created by an algorithm or process loosely coupled with BGP, huh? After all, if a packet is hanging out in some buffer somewhere waiting to be forwarded and the device has no clue to where to zing the little bit stream, then the device has two choices, consult a process to get the info, or get the garbage out of the buffer, assuming no default, no last chance place to zing. Hence, (and I'm probally way off base here) but the technique for forwarding packets is loosely coupled with the way routing information is exchanged and stored. If they are loosely coupled, it is difficult to grasp how they are orthogonal; being orthogonal implies to me that the process of using a forwarding table and creating a forwarding table are completely 100 decoupled. This assumption, if correct based on a mutual understanding of terms, then leads one to believe that the choice must always be a loss of packets when the BGP process fails ( for any reason ) to create a nice warm table for the forwarding function to enjoy. In this loosely coupled process, the requirement then is to have a large forwarding table AND for devices to exchange and process a large amount of routing information to maintain the nice, robust look-up-tables. This further implies that even if a device is not forwarding packets for a particular network range at any given time, the loosely coupled processes must both exchange routing information for the idle range of networks AND maintain a look-up entry for that idle range of networks in the forwarding tables, right? This, is my mental problem with the BGP method of exchanging routing information and BGP loosely coupled sister forwarding table. What am I missing (besides a 'life' and my fiancee to be up at this hour contemplating this stuff) ? In my mind, this algorithm is inefficient (treading on land mines here, and trying to stay alive.... :-) because the devices must exchange and process information on all possible destinations even when a statistical number or range of networks are not active and my not be active in that particular device for a considerable time interval ( minutes, maybe even days....) not only are the idle networks in the exchange, but they exist in the forwarding table as well. This implies that the forwarding table is also significantly larger than necessary at a particular function of time. This also implies that this loosely coupled technique or method can never scale upward efficiently. Hmmmm. Confusion of terms? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 01:20:19 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03981; Tue, 7 Nov 1995 01:20:19 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA01680; Tue, 7 Nov 1995 01:20:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA01674; Tue, 7 Nov 1995 01:18:45 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03926; Tue, 7 Nov 1995 01:18:41 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id JAA14515; Mon, 6 Nov 1995 09:16:11 -0500 From: Tim Bass Message-Id: <199511061416.JAA14515@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Mon, 6 Nov 1995 09:16:11 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511060719.XAA13245@greatdane.cisco.com> from "Tony Li" at Nov 5, 95 11:19:17 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2530 Precedence: bulk > > Good. We agree. > > Then what was this entire thread about, anyways...? > > Tony > We were exploring the idea ...... "Is there a better architecture for forwarding tables, i.e. cacheing with a adjunct processor, based on the agreed fact that at any given moment in time the 75-60 percent of the forwarding table entries are not actively being forwarded..... I thought :-)" You asked me to believe, without proof based on your experience with this type of architecture, that it will not work. With all due respects for your experience and knowledge, it might be helpful to explore the technical details of the methods used, the experiment(s) themselves, and the optimizations used. One the other hand, I assume that the details are proprietary or considered intellectual property by cisco, hence your reasoning for asking me to have faith in you, blindly without supporting evidence. Given your deserved excellent reputation as one of the leaders in inter-domain routing, Tony. I believe that it is highly possible that you are 100 percent correct in your opinion that there is *no way* adjunct processing will help the forwarding table scaling issue. I hope you understand as well, that asking someone to believe in the results of an undocumented, perhaps secret architecture, does not create the glowing confidence that ones heart would aspire. Personally, as a man who only believes in causality , you can understand why asking me to 'have faith' is something that is generally difficult. You have asked me to 'become a believer' based on my 'faith in Tony Li' which puts me in a mystical quandary. That is why I have 'backed down' or 'recoiled' from this thread. I do not wish to be in the position of debating with a expert who has asked me to 'believe in him and his words' and offers no concrete proof. It is a no-win situation. Why pursue it? Respectfully, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 02:20:18 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07022; Tue, 7 Nov 1995 02:20:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA01722; Tue, 7 Nov 1995 02:20:09 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA01718; Tue, 7 Nov 1995 02:14:55 +1100 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06692; Tue, 7 Nov 1995 02:14:52 +1100 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id KAA18239; Mon, 6 Nov 1995 10:14:29 -0500 Date: Mon, 6 Nov 1995 10:14:27 -0500 (EST) From: Nathan Stratton To: Tim Bass Cc: Tony Li , big-internet@munnari.OZ.AU Subject: Re: New book on routing In-Reply-To: <199511061416.JAA14515@dune.silkroad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 6 Nov 1995, Tim Bass wrote: > > Good. We agree. > > > > Then what was this entire thread about, anyways...? > > > > Tony > > You have asked me to 'become a believer' based on my 'faith > in Tony Li' which puts me in a mystical quandary. That is > why I have 'backed down' or 'recoiled' from this thread. > I do not wish to be in the position of debating with a > expert who has asked me to 'believe in him and his words' > and offers no concrete proof. > > It is a no-win situation. Why pursue it? > > Respectfully, > > Tim Because there are other people who are reading this list and are looking for other ways. I and others reading this list do think that moving the bridge a few feet may work and save us thousands of $ and increases performance. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 02:22:59 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07099; Tue, 7 Nov 1995 02:22:59 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA01750; Tue, 7 Nov 1995 02:22:52 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA01712; Tue, 7 Nov 1995 02:04:30 +1100 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06338; Tue, 7 Nov 1995 02:04:27 +1100 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA17283; Mon, 6 Nov 95 09:05:06 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA25859; Mon, 6 Nov 95 09:04:51 CST Date: Mon, 6 Nov 95 09:04:51 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9511061504.AA25859@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: New book on routing Precedence: bulk Tony's already given out the important number, which is (I think) that 40 percent of the forwarding table is 'hot', in some sense, which probably means something on the order of 'in use in any typical 1 second timeslice'. This is ample evidence, for me. In an ideal world, Tony would develop an experimental model, and submit a 200 page report which we would all print out and file on our desks in the 'must read some time' pile, but we're stuck with the '40 percent' thing. It certainly is clear that to support the current somewhat hokey hop-by-hop FORWARDING (which I remind the audience has nothing whatsoever to do with routing protocols) model, a radically different router architecture is required. There's no really viable choice other than to stuff the forwarding table into whatever's doing your forwarding (switching, if you prefer), and that means a pile of fast RAM. This is quite the opposite of decoupling the forwarding table from the switching hardware. I think Tony has also already pointed out that efforts to decrease routing database size (i.e. the amount of information pushed around by routing protocols, and the size of the table derived therefrom) and the forwarding table will, by necessity, make more of the forwarding table hot, thereby making the decoupled architecture even worse. It's intuitively obvious to the casual observer. I think I can probably also prove it. Isn't this the same thread we had a few months ago? Andrew From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 02:24:40 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07145; Tue, 7 Nov 1995 02:24:40 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA01772; Tue, 7 Nov 1995 02:24:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA01715; Tue, 7 Nov 1995 02:07:03 +1100 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06567; Tue, 7 Nov 1995 02:07:01 +1100 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id KAA18089; Mon, 6 Nov 1995 10:06:38 -0500 Date: Mon, 6 Nov 1995 10:06:37 -0500 (EST) From: Nathan Stratton To: Bill Woodcock Cc: bass@dune.silkroad.com, tli@cisco.com, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, sob@newdev.harvard.edu Subject: Re: New book on routing In-Reply-To: <9511060912.AA04743@zocalo.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 6 Nov 1995, Bill Woodcock wrote: > > cisco boxes could communicate with an adjunct processor in a > > nice robust manner... ...currently undefined interface card that > > generic unix vendors could market. > > Ah, but cisco sells 7500s, not Unix boxes. :-) Well, why not use Unix boxes and cisco's? We are just getting up a connection to MAE-East and have a T1 into sprint, and MCI. We are doing full bgp4 with everybody. Our network was cisco 4000, but only 16 megs in each router. We looked at going to 4500-M with 32 meg, but that would be close. We called up cisco they said we needed to get a few cisco 7000 or 7500's. The problem with this is our fastest link right now is 10 meg why do I need the 7000 right now? Well the answer is RAM, so what we did is went out and get 4 P133 PCI with 64 megs of ram. We have 2 100 Base T ethernet cards in each router (with the 4000 we only had 10 meg ethernet into a ethernet switch) and 3 Emerging Tech T1 cards in each router. We run gated on all of them and do external and internal bgp4. It works great, no problems at all. Ya sure we will need a 7000 some day when we start working with 0c3's and such and want a FDDI into the gigaswitch. Or do we DEC makes a PCI FDDI card for a PC :-) Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 02:41:36 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07725; Tue, 7 Nov 1995 02:41:36 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA01797; Tue, 7 Nov 1995 02:40:12 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA01736; Tue, 7 Nov 1995 02:21:24 +1100 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07043; Tue, 7 Nov 1995 02:21:21 +1100 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA17502; Mon, 6 Nov 95 09:22:10 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA26136; Mon, 6 Nov 95 09:21:55 CST Date: Mon, 6 Nov 95 09:21:55 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9511061521.AA26136@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: New book on routing Precedence: bulk That said, I suppose it's worth pointing out that there's no essential reason to not separate the routing protocol talker from the forwarding device, *given* that the forwarding device has a complete forwarding table. There's also no obvious reason to bother, since the two devices must scale (in terms of memory size) together, one must contain a complete routing database and forwarding table, the other must contain a complete forwarding table. This might be how some of the 'route server' things that have been proposed or built work, and it's completely different from separating the forwarding table from the forwarding hardware. Andrew From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 02:41:59 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07749; Tue, 7 Nov 1995 02:41:59 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA01825; Tue, 7 Nov 1995 02:41:51 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA01743; Tue, 7 Nov 1995 02:21:56 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07056; Tue, 7 Nov 1995 02:21:53 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id KAA14944; Mon, 6 Nov 1995 10:18:07 -0500 From: Tim Bass Message-Id: <199511061518.KAA14944@dune.silkroad.com> Subject: Re: New book on routing To: nathan@netrail.net (Nathan Stratton) Date: Mon, 6 Nov 1995 10:18:07 -0500 (EST) Cc: woody@zocalo.net, tli@cisco.com, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, sob@newdev.harvard.edu In-Reply-To: from "Nathan Stratton" at Nov 6, 95 10:06:37 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1422 Precedence: bulk Nathan: > Ya sure we will need a 7000 some day when we start working with 0c3's and > such and want a FDDI into the gigaswitch. Or do we DEC makes a PCI FDDI > card for a PC :-) This is getting off the 'big internet' charter a bit, but for the sake of charity: There is a school in New Jersey with a linux box, and a DEC PCI FDDI card and a free FDDI pop donated by AT&T. They called me, but I could not find a FDDI driver for linux. Do you know of one for another flavor of unix? If so, let me know and I'll pass the word along to this high school. I'm helping them without charging them, being a high school with a small budget, I encouraged them to take the money they were willing to pay me and buy more toys for the kids. The FDDI/Linux problem was a 'no solution' dead end. Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 03:20:24 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08818; Tue, 7 Nov 1995 03:20:24 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA01868; Tue, 7 Nov 1995 03:20:11 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA01862; Tue, 7 Nov 1995 03:17:02 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08475; Tue, 7 Nov 1995 03:16:57 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id LAA15370; Mon, 6 Nov 1995 11:14:27 -0500 From: Tim Bass Message-Id: <199511061614.LAA15370@dune.silkroad.com> Subject: Re: New book on routing To: amolitor@anubis.network.com (Andrew Molitor) Date: Mon, 6 Nov 1995 11:14:27 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9511061504.AA25859@anubis.network.com> from "Andrew Molitor" at Nov 6, 95 09:04:51 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2527 Precedence: bulk > > Tony's already given out the important number, which is (I think) > that 40 percent of the forwarding table is 'hot', in some sense, which You are absolutely right ! If 40 percent of the table is hot, then 60 percent is cold or maybe lukewarm. If the cache algorithm (which Tony states is not the best way to do things) has the potential to gain between 40 to 60 percent, this in itself is a significant engineering gain, especially since many believe that RAM is a problem they would like to solve, in it and of itself. I disagree that the 25-40 percent 'hot' numbers make it obvious to the casual observer that an efficient well planned forwarding table cache is not a good idea. In fact, the intuitively obvious part is that the active/inactive bimodal states in the forwarding table do have a potential for significant improvements in RAM utilization. The part that is not obvious and is difficult to swallow is the claim that 'latency' nullifies any potential gain in RAM because of an unspecified, undetailed performance hit and the algorithm and system issues are unknown. Without a profound understanding of the algorithm and architecture is is virtually impossible to either agree or disagree. There is nothing obvious to the casual observer that I have read that would lead one to come to the conclusion that improvements in latency and performance are not possible and that the systems architecture being explored has reached a dead end. I choose to recoil from asking cisco to prove this, and accept the fact that the work could be and probally correctly considered their intellectual property. On the other hand, others are free to accept that conclusion as fact without question if they so choose. Faith is not what Einstein considered to be good science. I am no Einstein, but we do share the same opinion toward scientist based on faith and not facts. Regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 04:40:20 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17894; Tue, 7 Nov 1995 04:40:20 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA01909; Tue, 7 Nov 1995 04:40:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA01902; Tue, 7 Nov 1995 04:31:16 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17071; Tue, 7 Nov 1995 04:31:13 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05261; Mon, 6 Nov 95 12:29:50 -0500 Date: Mon, 6 Nov 95 12:29:50 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511061729.AA05261@ginger.lcs.mit.edu> To: amolitor@anubis.network.com, big-internet@munnari.OZ.AU Subject: Re: New book on routing Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: amolitor@anubis.network.com (Andrew Molitor) there's no essential reason to not separate the routing protocol talker from the forwarding device, *given* that the forwarding device has a complete forwarding table. ... the two devices must scale (in terms of memory size) together, one must contain a complete routing database and forwarding table, the other must contain a complete forwarding table. At least in the current Internet architecture.... :-) Noel From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 04:41:57 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17844; Tue, 7 Nov 1995 04:41:57 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA01933; Tue, 7 Nov 1995 04:41:49 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA01905; Tue, 7 Nov 1995 04:31:57 +1100 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17138; Tue, 7 Nov 1995 04:31:55 +1100 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id JAA03376; Mon, 6 Nov 1995 09:30:35 -0800 Message-Id: <199511061730.JAA03376@hubbub.cisco.com> To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-internet@munnari.OZ.AU Subject: Re: New book on routing In-Reply-To: Your message of "Mon, 06 Nov 95 09:04:51 CST." <9511061504.AA25859@anubis.network.com> Date: Mon, 06 Nov 95 09:30:35 PST From: Yakov Rekhter Precedence: bulk Andrew, > Isn't this the same thread we had a few months ago? There was a message from Dennis Ferguson ~2 months ago on the same thread (see attached). Yakov. P.S. Ih his message Dennis is referring to "work done by Bilal Chinoy and Hans-Werner Braun some time ago using data sampled on the T1 NSFnet, which suggested that forwarding-path caching was indeed attractive with respect to the size of the full forwarding table.". Just to clarify, the work was done by myself and Bilal (there was a paper in ACM CCR that presented the work). Important to stress that the work was done in a pre-CIDR days. Aggressive aggregation of reachability information seemed to change the conclusions reached in the paper. ----------------------------------cut here---------------------------- Date: Mon, 11 Sep 95 12:23:49 EDT To: avg@sprint.net (Vadim Antonov) cc: michael@junction.net, tli@cisco.com, asp@uunet.uu.net, bass@cais.cais. ***com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, jnc@ginger.lcs.mit.edu, smd@cesium.clock.org From: Dennis Ferguson Subject: Re: Distributed systems Return-Path: owner-Big-Internet@munnari.OZ.AU In-Reply-To: Your message of "Sun, 10 Sep 1995 17:58:23 EDT." <199509102158.RAA12416@titan.sprintlink.net> Precedence: bulk >>The route processor is supposed to stop this from happening by feeding >>the SSP a subset of the full routing table. > > Yet another myth. The cache footprint for core routes is at about 40% > of the full table. It may as well be that *not* doing cacheing will > actually save memory in the forwarding tables (and would certainly make > the whole design a lot more robust). The bugs in software seem to > be in the top three reasons for the Internet's unrealiability. > > SL-MAE-E#sh ip ca > IP routing cache 12686 entries, 1859004 bytes > Minimum invalidation interval 2 seconds, maximum interval 5 seconds, MCI's hottest routers run with closer to 80% of the full table in the cache, e.g. core.wtn#show ip ca IP routing cache 23911 entries, 3545372 bytes This fraction has continuously grown over the 6 months I've been paying attention, from about 65% in April. Not that this necessarily tells you a whole lot, since that number does depend critically on the strategy used for flushing entries out of the cache as well, but I do have another data point. If you stay up until the wee hours of the morning (to avoid breaking anything), and flush the cache on one of those routers, the load won't come off the RP until over 50% of the full forwarding table is back in the cache. This result is a direct contradiction to work done by Bilal Chinoy and Hans-Werner Braun some time ago using data sampled on the T1 NSFnet, which suggested that forwarding-path caching was indeed attractive with respect to the size of the full forwarding table. The fact that this has changed may be a result of changing characteristics of applications people use, or may be a consequence of the relative success of CIDR at keeping the growth rate of the forwarding table below the growth rate of the Internet as a whole. We're getting increasingly less dead weight in forwarding tables. In any case suggesting a scheme which relies on forwarding-path demand caching for some benefit, without presenting supporting data concerning the traffic carried by the network being designed for, is engineering something without any evidence of it being useful. All the indications I have suggest that forwarding-path caching is no longer of any benefit when building high-end routers, and has considerable drawbacks. Dennis Ferguson P.S. I also agree about the software complexity of caching. Despite having burned months, or years, of good quality programmer time in efforts to keep it functioning I think the fact that Cisco 7000's do demand caching in the forwarding path is the root cause of about 80% of all evils with those boxes for high-end uses. Life is too short... From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 06:01:39 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27052; Tue, 7 Nov 1995 06:01:39 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA01992; Tue, 7 Nov 1995 06:00:12 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA01986; Tue, 7 Nov 1995 05:59:39 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26739; Tue, 7 Nov 1995 05:59:35 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id NAA16630; Mon, 6 Nov 1995 13:56:14 -0500 From: Tim Bass Message-Id: <199511061856.NAA16630@dune.silkroad.com> Subject: Re: New book on routing To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 6 Nov 1995 13:56:14 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9511061729.AA05261@ginger.lcs.mit.edu> from "Noel Chiappa" at Nov 6, 95 12:29:50 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1864 Precedence: bulk > > At least in the current Internet architecture.... :-) > > Noel > Noel, So nice to hear from you. I would like to shift gears, if possible and get you to talk about your work on flows and states in Chapt. IV of the IPNG Addison-Wesley book on the shelves. Scott kindly recommended that I read Chapter IV in particular, your contribution. I put down my goofy Pulitzer Prize winner _A Confederacy of Dunces_ to enjoy the Noel-isms of the IPNG world. This is no reflection on your work, only on my ignorance of the subject matter to be sure, but I found your thoughts on flows and states more confusing than the Einstein books I've been reading on General Relativity. Lorentz and Heisenburg, I assume have been stuffed into our way of thinking since the undergraduate days.... I guess that explains why space-time and universal singularities are more intuitive that IPNG flow-state paradigms. Is there some hardback reference material that would help me understand your concepts easier, or is this a 'pure' Noel Theory? Also, is this a good place to discuss this, or is there a better group to discuss IPNG flow? I subscibed to the NIMROD WG but have yet to get a reply from the server or any NIMROD traffic. Thanks, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 09:41:36 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14676; Tue, 7 Nov 1995 09:41:36 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02095; Tue, 7 Nov 1995 09:40:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02089; Tue, 7 Nov 1995 09:23:42 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11487; Tue, 7 Nov 1995 09:23:41 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA02223; Mon, 6 Nov 1995 14:23:13 -0800 Date: Mon, 6 Nov 1995 14:23:13 -0800 From: Tony Li Message-Id: <199511062223.OAA02223@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511061416.JAA14515@dune.silkroad.com> (message from Tim Bass on Mon, 6 Nov 1995 09:16:11 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk We were exploring the idea ...... "Is there a better architecture for forwarding tables, i.e. cacheing with a adjunct processor, based on the agreed fact that at any given moment in time the 75-60 percent of the forwarding table entries are not actively being forwarded..... I thought :-)" You asked me to believe, without proof based on your experience with this type of architecture, that it will not work. No, I don't ask you to believe that at all. I simply am trying to point out to you that the cisco 7000 implements what you've proposed already. You're welcome to purchase a 7000 ;-), and try it out for yourself. The cache is plainly visible with the "show ip cache" command. You're welcome to test its performance under route flaps and compute the cost of a route fault. This solution clearly does not scale sufficiently. The cache is a significant fraction of the full table. And growing. If the full table grows exponentially, then so does the cache. We're still stuck with the same problem. A factor of 2-3X improvement is not enough. What I'm trying to tell you is: "Been there, done that, got the battle scars to prove it." You're certainly welcome to go through the battle again... but please don't expect us to follow you into a battle we've already fought. We know how it turns out. Tony From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 10:03:23 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15700; Tue, 7 Nov 1995 10:03:23 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA02128; Tue, 7 Nov 1995 10:02:05 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02115; Tue, 7 Nov 1995 09:48:49 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11677; Tue, 7 Nov 1995 09:48:46 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id RAA18040; Mon, 6 Nov 1995 17:46:16 -0500 From: Tim Bass Message-Id: <199511062246.RAA18040@dune.silkroad.com> Subject: Re: New book on routing To: tli@cisco.com (Tony Li) Date: Mon, 6 Nov 1995 17:46:16 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511062223.OAA02223@greatdane.cisco.com> from "Tony Li" at Nov 6, 95 02:23:13 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1970 Precedence: bulk > You asked me to believe, without proof based on your experience > with this type of architecture, that it will not work. > > No, I don't ask you to believe that at all. I simply am trying to > point out to you that the cisco 7000 implements what you've proposed > already. You're welcome to purchase a 7000 ;-), and try it out for > yourself. The cache is plainly visible with the "show ip cache" > command. You're welcome to test its performance under route flaps and > compute the cost of a route fault. > I was really hoping we would not bring the 7000 into the discussion. All you are really saying is " been there, done that, got the battle scars, and the cisco 7000 did not cache well ". Sorry..... did not begin the discussion to get into specific implementation of off-the-shelf devices. I was hoping to stay in the theoretical, pedantic mathematical realm and avoid discussing individual vendors products and implementations. But, while we are on the subject...... is it possible to publish the algorithm that cisco uses to implement it's cache function? I would be interested, as an Electrical Engineer, to take a look at the actual implementation and learn a few lessons. I find it very interesting that you claim this technique will not work based on one particular vendors "lessons learned". Thanks, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 10:21:24 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09053; Tue, 7 Nov 1995 10:21:24 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA02155; Tue, 7 Nov 1995 10:20:12 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA02130; Tue, 7 Nov 1995 10:02:06 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16519; Tue, 7 Nov 1995 10:02:05 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id PAA04280; Mon, 6 Nov 1995 15:01:46 -0800 Date: Mon, 6 Nov 1995 15:01:46 -0800 From: Tony Li Message-Id: <199511062301.PAA04280@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511062246.RAA18040@dune.silkroad.com> (message from Tim Bass on Mon, 6 Nov 1995 17:46:16 -0500 (EST)) Subject: Re: New book on routing Precedence: bulk All you are really saying is " been there, done that, got the battle scars, and the cisco 7000 did not cache well ". No, not at all. The 7000 caches just fine. I'm trying to warn you about the cost of the cache _miss_. But, while we are on the subject...... is it possible to publish the algorithm that cisco uses to implement it's cache function? The caching algorithm isn't the issue... Tony From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 10:41:22 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19690; Tue, 7 Nov 1995 10:41:22 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA02190; Tue, 7 Nov 1995 10:40:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA02180; Tue, 7 Nov 1995 10:24:32 +1100 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12960; Tue, 7 Nov 1995 10:24:25 +1100 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA25262; Mon, 6 Nov 95 17:25:17 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA05309; Mon, 6 Nov 95 17:25:02 CST Date: Mon, 6 Nov 95 17:25:02 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9511062325.AA05309@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: New book on routing Precedence: bulk I would be fascinated to know just how turning the various knobs on a cache management scheme could substantially help the cache hit ratio? You can probably get things a little better or a little worse by fiddling with timers, but I strongly suspect that any non-idiotic algorithms are going to yield roughly similar hit ratios. Experience with CPU memory caches and virtual memory paging algorithms suggests that improvements in hit ratios tend to be minor (or at least not dramatic, not orders of magnitude), algorithm tinkering tends to yield improvements in management overhead. In any case, it is most certainly the case that if your working set doesn't fit in cache, you will thrash. I think that what Tony has been trying to tell us, without outright saying 'our products tend to thrash when used in application XYZ', is that the core routers are thrashing their cache, or are real close to doing so, or are beginning to. To be quite clear, this is how I am reading his remarks, I have NO evidence of this, and this may be sheer petty competitor bigotry at work in my subconscious. Again: If your working set exceeds cache size, you *will* thrash. Andrew From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 12:01:32 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27341; Tue, 7 Nov 1995 12:01:32 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA02236; Tue, 7 Nov 1995 12:00:14 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA02230; Tue, 7 Nov 1995 11:53:42 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25755; Tue, 7 Nov 1995 11:53:39 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id TAA19170; Mon, 6 Nov 1995 19:51:07 -0500 From: Tim Bass Message-Id: <199511070051.TAA19170@dune.silkroad.com> Subject: Re: New book on routing To: amolitor@anubis.network.com (Andrew Molitor) Date: Mon, 6 Nov 1995 19:51:07 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9511062325.AA05309@anubis.network.com> from "Andrew Molitor" at Nov 6, 95 05:25:02 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1206 Precedence: bulk Andrew: > > Again: If your working set exceeds cache size, you *will* thrash. > Now, you have stimulated my interest in cache algorithms, because I do not have the technical background writing cache algorithms to add anything useful to the hit-miss-thrash issue. Practically every system level idea that I have advocated, in this area, points to problems in the cache subsystem. Hmmmm. Is their a technical reference on the subject available, for example a textbook entitled _Implementing Cache Algorithms in Real Time Systems_ or something similar to read? Thanks, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 17:41:25 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB06462; Tue, 7 Nov 1995 17:41:25 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA02293; Tue, 7 Nov 1995 17:40:21 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA02287; Tue, 7 Nov 1995 17:31:40 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03657; Tue, 7 Nov 1995 17:31:39 +1100 (from nathan@netrail.net) Received: from netrail.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05301 Tue, 7 Nov 1995 17:31:34 +1100 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id BAA15216; Tue, 7 Nov 1995 01:24:55 -0500 Date: Tue, 7 Nov 1995 01:24:55 -0500 (EST) From: Nathan Stratton To: Tim Bass Cc: woody@zocalo.net, tli@cisco.com, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, sob@newdev.harvard.edu Subject: Re: New book on routing In-Reply-To: <199511061518.KAA14944@dune.silkroad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 6 Nov 1995, Tim Bass wrote: > > Nathan: > > > Ya sure we will need a 7000 some day when we start working with 0c3's and > > such and want a FDDI into the gigaswitch. Or do we DEC makes a PCI FDDI > > card for a PC :-) > > This is getting off the 'big internet' charter a bit, but for the > sake of charity: > > There is a school in New Jersey with a linux box, and a DEC PCI FDDI > card and a free FDDI pop donated by AT&T. They called me, but I could > not find a FDDI driver for linux. Do you know of one for another > flavor of unix? If so, let me know and I'll pass the word along > to this high school. > > I'm helping them without charging them, being a high school with a > small budget, I encouraged them to take the money they were willing > to pay me and buy more toys for the kids. The FDDI/Linux problem > was a 'no solution' dead end. > Yes, well I was not able to get a Linxu driver, I have been using FreeBSD and it has drivers for the EIAS and PCI DEC FDDI cards. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite 5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Tue Nov 7 21:00:38 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21478; Tue, 7 Nov 1995 21:00:38 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA02336; Tue, 7 Nov 1995 21:00:23 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA02330; Tue, 7 Nov 1995 20:51:05 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08781; Tue, 7 Nov 1995 20:51:02 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA05087; Tue, 7 Nov 1995 01:50:57 -0800 Date: Tue, 7 Nov 1995 01:50:57 -0800 From: Tony Li Message-Id: <199511070950.BAA05087@greatdane.cisco.com> To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-internet@munnari.OZ.AU Subject: Caching Precedence: bulk In any case, it is most certainly the case that if your working set doesn't fit in cache, you will thrash. I think that what Tony has been trying to tell us, without outright saying 'our products tend to thrash when used in application XYZ', is that the core routers are thrashing their cache, or are real close to doing so, or are beginning to. To be quite clear, this is how I am reading his remarks, I have NO evidence of this, and this may be sheer petty competitor bigotry at work in my subconscious. Again: If your working set exceeds cache size, you *will* thrash. Andrew, For the record, no, that's NOT what I'm saying. Our cache is not thrashing. Since I still don't seem to be communicating, I'll try again: Tim seemed to be proposing that a remote route server with only a cache under the switching engine was a viable, scalable, alternative architecture for backbone routers. I'm trying to make the following points: 1) We have evidence that indicates that the working set is a very large percentage of the entire table. This would reduce (or more likely, negate) the savings obtained by caching. 2) That the percentage is increasing, not decreasing. This implies that the above savings is decreasing over time. This further implies that the switching table grows proportionately to the full routing table, or possibly worse. 2a) The corollary is that the proposed architecture scales AT BEST no better than the existing architectures. And we _are_ trying to do better... 2b) In the face of exponential growth of the full routing table, it implies that the switching table will need to grow exponentially. 2c) This puts us right back in the situation that Tim was trying to avoid: having to renumber to support CIDR. Thus, this does not seem to be a logical alternative. 3) The cost of a cache miss in a 7000 is painful. A cache miss which requires remote access is highly likely to be worse. This would only exacerbate the problems that we see today. Consider the case when you lose a significant neighbor at one of the interconnects. Bye, bye cache. Now, as I don't care to spoonfeed the competition TOO much... I'll just shut up. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 01:00:40 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03447; Wed, 8 Nov 1995 01:00:40 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02494; Wed, 8 Nov 1995 01:00:25 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02482; Wed, 8 Nov 1995 00:41:44 +1100 Received: from betelgeuse.advanced.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01478; Wed, 8 Nov 1995 00:41:42 +1100 (from almes@advanced.org) Received: from canopus by betelgeuse.advanced.org via SMTP (940816.SGI.8.6.9/940406.SGI) id IAA22972; Tue, 7 Nov 1995 08:41:20 -0500 Message-Id: <199511071341.IAA22972@betelgeuse.advanced.org> X-Sender: almes@betelgeuse.advanced.org X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Nov 1995 08:42:51 -0500 To: Tony Li From: Guy T Almes Subject: Re: Caching Cc: amolitor@anubis.network.com (Andrew Molitor), big-internet@munnari.OZ.AU Precedence: bulk Tony, Be careful about contradicting Andrew on this point... At 01:50 AM 11/7/95 -0800, Tony Li wrote: > In any case, it is most certainly the case that if your working set > doesn't fit in cache, you will thrash. I think that what Tony has been > trying to tell us, without outright saying 'our products tend to thrash > when used in application XYZ', is that the core routers are thrashing their > cache, or are real close to doing so, or are beginning to. To be quite > clear, this is how I am reading his remarks, I have NO evidence of this, > and this may be sheer petty competitor bigotry at work in my subconscious. > Again: If your working set exceeds cache size, you *will* thrash. > >Andrew, > On the one hand you say you are not thrashing: >For the record, no, that's NOT what I'm saying. Our cache is not >thrashing. > . . . And on the other hand you give an almost textbook definition of thrashing: >I'm trying to make the following points: > >1) We have evidence that indicates that the working set is a very >large percentage of the entire table. This would reduce (or more >likely, negate) the savings obtained by caching. > >2) That the percentage is increasing, not decreasing. This implies >that the above savings is decreasing over time. This further implies >that the switching table grows proportionately to the full routing >table, or possibly worse. . . . >3) The cost of a cache miss in a 7000 is painful. . . . . . . > >Tony > The term thrashing arose in the mid-60s when time-sharing systems were beginning to use demand paging to allow multiple processes to share a limited amount of physical memory. Within a fairly short period of time, most of the clever algorithms were thought of and implemented with a varying degree of elegance, but the systems ran more slowly than their designers had hoped. Peter Denning made his initial splash on the Operating Systems community by coining the term 'thrashing' to characterize the situations being encountered and by pointing out that all the caching algorithm cleverness in the world would not save you *if you tried to support too many processes with too little physical memory*. His thesis worked to characterize what 'enough physical memory' for a given process might mean, and he coined the term 'working set' to capture this. Putting the two ideas together, you get (more or less by definition) Andrew's statement that: > Again: If your working set exceeds cache size, you *will* thrash. This is not a criticism of the idea of a cache or of the Cisco design. Thrashing can happen, quite simply, because the cache size is not as big as it needs to be avoid the situation that you correctly characterize. -- Guy From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 01:40:46 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06485; Wed, 8 Nov 1995 01:40:46 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA02537; Wed, 8 Nov 1995 01:40:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02523; Wed, 8 Nov 1995 01:34:15 +1100 Received: from ns.Newbridge.Com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04536; Wed, 8 Nov 1995 01:34:11 +1100 (from jhalpern@Newbridge.COM) Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id JAA20615 for ; Tue, 7 Nov 1995 09:34:09 -0500 Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma020596; Tue Nov 7 09:34:04 1995 Received: from mako.us.Newbridge.com (mako.us.newbridge.com [138.120.85.99]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with SMTP id JAA10029 for ; Tue, 7 Nov 1995 09:34:03 -0500 Received: from lobster.Newbridge.COM by mako.us.Newbridge.com (4.1/SMI-4.0) id AA05521; Tue, 7 Nov 95 09:28:53 EST Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA19532; Tue, 7 Nov 1995 09:33:06 +0500 Date: Tue, 7 Nov 1995 09:33:06 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9511071433.AA19532@lobster.Newbridge.COM> To: big-internet@munnari.OZ.AU Subject: re: Distributed Routers X-Sun-Charset: US-ASCII Content-Length: 1834 Precedence: bulk To paraphrase the ongoing discussion between Tim Bass and Tony Li, the question is whether there are other ways to build routers. The answer, of course, is yes. Now, lets look at a more interesting specific question. If one is considering building a router where the routing protocol engine (with full forwarding tables) is connected to the forwarding enging by some "network" and the forwarder cache is filled "on demand" (either by query from the forwarder, push from the router, or by magic does not matter for this discussion), where would such a collection of boxes be useful. Tony has provided statistics which suggest that the proportion of the table in use in the core of the network is 40%. I am inclined to accept that number for discussion purposes. ANd I believe it proves his point. In the core of a "big-internet", such a distributed device would not be a big advantage. Factors of two in table size are irrelevant. You need at least factors of ten for alternative engineering designs to make sense. Having said that, I will observe that a lot of companies are trying to figure out how to build boxes like that. In fact, the ATM Forum has a working group to standardize the elements of protocol used so that the forwarders and routers could even come from different vendors. I don't expect to use such a box on the internet backbone. But I expect that it is useful in other contexts. It does not change the fundemental routing paradigm, just the implementation. (If there were not a need for local interoperability between pieces from different vendors, this would not even be a problem worthy of standardization.) Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. PS The working group in the ATM Forum, for those who are members, is the Multi-Protocol Over ATM working group. From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 03:00:41 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08659; Wed, 8 Nov 1995 03:00:41 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02621; Wed, 8 Nov 1995 03:00:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02615; Wed, 8 Nov 1995 02:46:42 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25637; Wed, 8 Nov 1995 02:46:37 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id KAA24357; Tue, 7 Nov 1995 10:44:26 -0500 From: Tim Bass Message-Id: <199511071544.KAA24357@dune.silkroad.com> Subject: Cache Math 101 To: big-internet@munnari.OZ.AU Date: Tue, 7 Nov 1995 10:44:26 -0500 (EST) X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3810 Precedence: bulk Before we do this cache math, let me point out that the end goal of these discussions, from my perspective, is *not* (a) to make a point for or against CIDR and renumbering or (b) to bash a particular vendor or their product. It is to explore the benefit that an adjunct processor could bring to the forwarding subsystem. Having cleared my conscious on that..... Andrew and I have been having a sidebar discussion on basic cache math. Neither of us claim to be a cache math guru, so we started with a nice back of the envelope, simplified model: Let T be the cache or the forwarding table in the switch; Let T' be the remained of the forwarding table in the AP; Let L1 be the latency throught the box with a cache hit; Let L2 be the additional latency to take a cache miss ( T to T' time) Let M be the probability of a cache miss; The average latency of the box ( a very simple model ) is: (credit to Andrew for the initial model, Eq.1) ( 1 - M ) * L1 + M * ( L1 + L2 ) (Eq.1) This further reduces to: L1 + M * L2 or just L1 + ML2 (need TeX ascii :-) Now, this is where Andrew and I begin to diverge a little: To me, looking at a purely mathematical sense, it appears that the limiting constraint is L1 if the probability of a cache miss is much less than 1, say 10 or 20 percent. Furthermore, if the system architecture and processing algorithms are designed well, there does not appear to be to many reasons why this cannot happen..... L2 ----> L1 So the limiting factor, even if L2 !----> L1 is that the ratio: L2/L1 is critical. And this is a systems architecuture issue, and not hopeless, in theory. If we further look at L1 and L2, again very simple: ( the Tim overly simple model of L1 and L2 ) Let: L1 = S1 + H1 + F1 ; and Let: L2 = S2 + H2 + F2 ; where S1 = Time to get the packet, grap the destination address; H1 = Time to search the forwarding cache for a hit; F1 = Time to send the hit to the forwarding queue; and S2 = Time to initialize the AP; H2 = Time to search the forwarding table in the AP; and F2 = Time to send the results back to the cache. (again this is a simple model, there are many other variables to consider, but we have to start somewhere, right? ) Then the simple L2/L1 limiting factor now becomes: S2 + H2 + F2 ------------ S1 + H1 + F1 These are 'out of the blue' assumptions, that in theory: S1 == S2; (or at least it *could*) H1 > H2 (for miss); F1 == F2; (again, it is *possible*) The reason that I set H1 > H2 is I assume that to search T completely for a miss takes the longest time ... " the real cost of a miss". This leads to a simple conclusion, based simple basic calculations and assumptions, that the system architecture and hash algorithms are the key to a successful cache.... and not the laws of physics. Admittedly, this is a simplifed model.... any suggestions on how to graduate from "Cache Math 101" to "Cache Math 201" is welcome and appreciated. Thanks for reading this far ! Tim PS: My advisor at Tulane always told me that an audience would fall asleep on these discussions and advised me not to be so mathematical ......... is anyone awake :-) -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 03:40:41 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10819; Wed, 8 Nov 1995 03:40:41 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA02651; Wed, 8 Nov 1995 03:40:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02645; Wed, 8 Nov 1995 03:30:47 +1100 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01502; Wed, 8 Nov 1995 03:30:44 +1100 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA03361; Tue, 7 Nov 95 10:31:38 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA13255; Tue, 7 Nov 95 10:31:22 CST Date: Tue, 7 Nov 95 10:31:22 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9511071631.AA13255@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Caching Precedence: bulk If Tony says the 7000s in the core are not thrashing, I will go with that. 'Thrashing' implies 'excessive' and I reckon if the 7000s are working, they're not doing excessive cache faulting, in some sense. I think there's a concern that due to the way the internet is growing, thrashing (in the excessive sense) is more or less doomed to happen in any caching system with cache substantially smaller than the full forwarding table, simply because better aggregation yields a working set equal to a progressively better proportion of the forwarding table. Darn good thing I stuck that disclaimer in, I say. Andrew (as always, not speaking for my employer) From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 05:41:30 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05624; Wed, 8 Nov 1995 05:41:30 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA02707; Wed, 8 Nov 1995 05:40:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02701; Wed, 8 Nov 1995 05:37:35 +1100 Received: from sjf-ums.sjf.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17540; Wed, 8 Nov 1995 05:37:32 +1100 (from tae@na.SJF.Novell.COM) Received: by sjf-ums; Tue Nov 7 10:08 PST 1995 Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA12322; Tue, 7 Nov 95 10:09:10 PST From: tae@novell.com (Tae Kyong Song) Message-Id: <9511071809.AA12322@na.SJF.Novell.COM> Subject: Re: Distributed Routers To: jhalpern@Newbridge.COM (Joel Halpern) Date: Tue, 7 Nov 1995 10:09:08 -0800 (PST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9511071433.AA19532@lobster.Newbridge.COM> from "Joel Halpern" at Nov 7, 95 09:33:06 am X-Mailer: ELM [version 2.4 PL22] Original-Content-Type: text Content-Type: text/plain Content-Length: 692 Precedence: bulk This is probably tangential to the main debate of cash'n thrash, but I wonder if the possibility of distributed static routing has been brought up in conjuntion with distributed routers. In distributed static routing, the routing engine could be fed with a static topology map, compute the right set of routes, and feed them to the forwarding engines. (Not withstanding the chicken and egg problem of having to have the route to the route server first, etc) Feel free to trash me, but I happen to be one who believes static routing is not the evil that some people think it is... Ok, now I'll go back to my Windows programming corner and be a quiet person that I usually am... Tae. From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 07:00:54 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13114; Wed, 8 Nov 1995 07:00:54 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA02750; Wed, 8 Nov 1995 07:00:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02743; Wed, 8 Nov 1995 06:46:22 +1100 Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20845; Wed, 8 Nov 1995 06:46:19 +1100 (from valdis@black-ice.cc.vt.edu) Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.1/8.7.1) with ESMTP id OAA27190; Tue, 7 Nov 1995 14:43:57 -0500 Message-Id: <199511071943.OAA27190@black-ice.cc.vt.edu> To: Tim Bass Cc: big-internet@munnari.OZ.AU Subject: Re: Cache Math 101 In-Reply-To: Your message of "Tue, 07 Nov 1995 10:44:26 EST." <199511071544.KAA24357@dune.silkroad.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ Date: Tue, 07 Nov 1995 14:43:51 -0500 Precedence: bulk On Tue, 07 Nov 1995 10:44:26 EST, you said: > Let T be the cache or the forwarding table in the switch; > Let T' be the remained of the forwarding table in the AP; > Let L1 be the latency throught the box with a cache hit; > Let L2 be the additional latency to take a cache miss ( T to T' time) > Let M be the probability of a cache miss; Here, you say L2 is " additional latency", but later you seem to use L2 as "the total latency on a cache miss".. > Furthermore, if the system architecture and processing algorithms > are designed well, there does not appear to be to many reasons > why this cannot happen..... > > L2 ----> L1 There's not too many reasons to assume this *can* happen. Here, you seem to be using L2 as "total latency on cache miss" -- there's no reason to think that the *added* latency should have a lower bound exactly equal to the latency of a cache hit... Now, let's look at the logic here. Assume that L2 drops until it's exactly equal to L1 - in other words, on a cache miss, we can do all the *added* latency in exactly zero time. Why are we bothering with a cache then? A cache is only useful when, for a large percentage of attempts, it increases performance sufficiently to (a) offset the additional delay on a failure *AND* (b) produce an overall performance improvement sufficient to justify the added expense. Real Life Example: Price standard 8M 70ns SIMMs sometime, figure the cost per megabyte, and then repeat for a 256K cache card for a machine that doesn't have one. Valdis Kletnieks Computer Systems Engineer Virginia Tech From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 07:02:52 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB14637; Wed, 8 Nov 1995 07:02:52 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA02774; Wed, 8 Nov 1995 07:02:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA02746; Wed, 8 Nov 1995 06:54:24 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23608; Wed, 8 Nov 1995 06:54:20 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id OAA26023; Tue, 7 Nov 1995 14:51:28 -0500 From: Tim Bass Message-Id: <199511071951.OAA26023@dune.silkroad.com> Subject: Re: Distributed Routers To: tae@novell.com (Tae Kyong Song) Date: Tue, 7 Nov 1995 14:51:28 -0500 (EST) Cc: jhalpern@Newbridge.COM, big-internet@munnari.OZ.AU In-Reply-To: <9511071809.AA12322@na.SJF.Novell.COM> from "Tae Kyong Song" at Nov 7, 95 10:09:08 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2479 Precedence: bulk Tae: > > This is probably tangential to the main debate of cash'n thrash, > but I wonder if the possibility of distributed static routing has been > brought up in conjuntion with distributed routers. This idea has come up in a couple of different manifestations and others can talk about the ideas they have advocated ... I can only talk to the model that I enjoy discussing. But first let me point out that this idea is *generally* not accepted, it is very controversial, and completely unproven as far as I know. My logic tells me that the mapping of networks to AS style prefixes changes very slowly with respect to time, since networks usually hang off a particular AS. By mapping this and distributing this information to NAPs and routing inter-AS using AS style prefixes and not networks a different routing paradigm is created. The end goal is to minimize the effect that route flap has on the route processor and to attempt to stablize the switch forwarding table. The details have not been worked out and no vendor currently is currenly interested (right ?) for various reasons. Maybe because it is a radical departure from the 'way it is being done' today; and the current practice works and has considerable support and momentum. There is no evidence that this paradigm is not workable, but because no one has produced a router that routes even one packet this way, it has very little support. Plus, with IPv6 heading down the pipe, many agree, including myself, that it is a waste of precious time and energy to depart from the best current practice in the IPv4 world. IPv6 routing paradigms are very interesting and I suspect that the issue will be discussed again in the IPv6 realm. -Tim Disclaimer: My views are not the majority view of big-internet but then again, they are not the majority view of any group :-) -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 08:41:04 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25713; Wed, 8 Nov 1995 08:41:04 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA02823; Wed, 8 Nov 1995 08:40:50 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA02813; Wed, 8 Nov 1995 08:39:14 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27937; Wed, 8 Nov 1995 08:39:06 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id QAA26671; Tue, 7 Nov 1995 16:36:26 -0500 From: Tim Bass Message-Id: <199511072136.QAA26671@dune.silkroad.com> Subject: Re: Cache Math 101 To: Valdis.Kletnieks@vt.edu Date: Tue, 7 Nov 1995 16:36:26 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511071943.OAA27190@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Nov 7, 95 02:43:51 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2469 Precedence: bulk > > > Furthermore, if the system architecture and processing algorithms > > are designed well, there does not appear to be to many reasons > > why this cannot happen..... > > > > L2 ----> L1 > > There's not too many reasons to assume this *can* happen. Here, you > seem to be using L2 as "total latency on cache miss" -- there's no > reason to think that the *added* latency should have a lower bound > exactly equal to the latency of a cache hit... Now, let's look at the > logic here. Assume that L2 drops until it's exactly equal to L1 - in > other words, on a cache miss, we can do all the *added* latency in > exactly zero time. > > Why are we bothering with a cache then? > Exactly, that's agood question. If L2 ----> L1; the simple model reduces to L1(1+M) which now has the additional cost of M so the question why bother with M at all is valid, indeed. On the other hand, if we had a single cache then L1 must be larger because the cache is bigger..... (consider the last entry found by a hash function in the forwarding table) My "Cache Math 101" point is simply this: If we can agree on the simple Cache Math 101 at least in principal, the we can explore the cost-benefits of designing a routed architecture with the agreed model. Maybe the overly simply model presented is not practical: L1 + M*L2 overly simple caching model My claim is that if we agree, in theory, on the underlying mathematic foundations of caching, even in a simple model, then exploring system architecture's, algorithms, and real-life examples are meaningful and; I would hope that we would agree, as a next step, on the elementary elements of L1 and L2. I would be very interested to see any mathematical models of caching that provide a more accurate simple representation of the foundations of a bimodal cache system. Regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 09:20:40 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20571; Wed, 8 Nov 1995 09:20:40 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02861; Wed, 8 Nov 1995 09:20:28 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02852; Wed, 8 Nov 1995 09:11:32 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB20918; Wed, 8 Nov 1995 09:11:29 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id RAA27031; Tue, 7 Nov 1995 17:08:53 -0500 From: Tim Bass Message-Id: <199511072208.RAA27031@dune.silkroad.com> Subject: Re: Cache Math 101 To: Valdis.Kletnieks@vt.edu Date: Tue, 7 Nov 1995 17:08:53 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511072202.RAA34104@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Nov 7, 95 05:02:07 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1824 Precedence: bulk > > On Tue, 07 Nov 1995 16:36:26 EST, you said: > > Exactly, that's agood question. If L2 ----> L1; the simple model > > reduces to L1(1+M) which now has the additional cost of M so the > > question why bother with M at all is valid, indeed. > > Make up your mind. Is L2 the *added* latency, or the *total* latency? Choose > one and stick with it. Here you seem to be saying it's the total (as there > is no reason for *added* latency's lower bound to be the same as a cache hit). > There is no confusion in my mind, sorry if my symbolism is not clear. L2 is and always has been the added latency. L2 ----> L1 means that the value of L2 approaches the value of L1. L1 + ML2 is the total latency. If M=0 and there is no probability that their is a miss then the total latency = L1. Is this clear? L2 ---> L1 does not mean that L2 becomes L1, it means: " the value of L2 approaches the value of L1 " similar to other mathematical symbols such as A ----> 0 and B ----> Infinity. Patience with asciii math symbols is appreciated. There is no confusion in my mind over the simple meaning. If the symbols to express the idea is not clear, then let's discuss the symbolism. Thanks, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 09:21:34 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA31107; Wed, 8 Nov 1995 09:21:34 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02883; Wed, 8 Nov 1995 09:21:24 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02849; Wed, 8 Nov 1995 09:02:33 +1100 Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29068; Wed, 8 Nov 1995 09:02:32 +1100 (from valdis@black-ice.cc.vt.edu) Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.1/8.7.1) with ESMTP id RAA34104; Tue, 7 Nov 1995 17:02:07 -0500 Message-Id: <199511072202.RAA34104@black-ice.cc.vt.edu> To: Tim Bass Cc: big-internet@munnari.OZ.AU Subject: Re: Cache Math 101 In-Reply-To: Your message of "Tue, 07 Nov 1995 16:36:26 EST." <199511072136.QAA26671@dune.silkroad.com> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ Date: Tue, 07 Nov 1995 17:02:07 -0500 Precedence: bulk On Tue, 07 Nov 1995 16:36:26 EST, you said: > Exactly, that's agood question. If L2 ----> L1; the simple model > reduces to L1(1+M) which now has the additional cost of M so the > question why bother with M at all is valid, indeed. Make up your mind. Is L2 the *added* latency, or the *total* latency? Choose one and stick with it. Here you seem to be saying it's the total (as there is no reason for *added* latency's lower bound to be the same as a cache hit). > On the other hand, if we had a single cache then L1 must be larger > because the cache is bigger..... (consider the last entry found by > a hash function in the forwarding table) Multiple parse errors encountered. L1 must be larger than what? And what should I be considering about the last entry? > My "Cache Math 101" point is simply this: > > If we can agree on the simple Cache Math 101 at least in principal, the We can agree when you start using variables in a consistent manner. > we can explore the cost-benefits of designing a routed > architecture with the agreed model. Maybe the overly simply model > presented is not practical: > > L1 + M*L2 overly simple caching model Here, you're back to using L2 as added latency. > I would be very interested to see any mathematical models of > caching that provide a more accurate simple representation > of the foundations of a bimodal cache system. It's easy to make a model that provides a more accurate representation. Unfortunately, you seem to be lacking the basic mathematical and logical tools needed to follow such a discussion. Learn some algebra. Study some queuing theory. Learn something. Come back when you have a clue. In the meantime, go square the circle, or prove that 1 = 2, or any of the other great mathematical challenges you seem very well suited to pursue.... /Valdis From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 09:40:44 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB00758; Wed, 8 Nov 1995 09:40:44 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA02909; Wed, 8 Nov 1995 09:40:28 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02903; Wed, 8 Nov 1995 09:34:10 +1100 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA30100; Wed, 8 Nov 1995 09:34:05 +1100 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id RAA03012; Tue, 7 Nov 1995 17:33:35 -0500 Date: Tue, 7 Nov 1995 17:33:35 -0500 From: Vadim Antonov Message-Id: <199511072233.RAA03012@titan.sprintlink.net> To: bass@dune.silkroad.com, big-internet@munnari.OZ.AU Subject: Re: Cache Math 101 Precedence: bulk Tim Bass wrote: >This leads to a simple conclusion, based simple basic calculations >and assumptions, that the system architecture and hash algorithms >are the key to a successful cache.... and not the laws of physics. Not. You can't fool the rule that working sets exceeding cache size cause trashing. The size of working set in this case is the characteristic of traffic and does not depend on the cacheing algorithm used. >Admittedly, this is a simplifed model.... any suggestions on how >to graduate from "Cache Math 101" to "Cache Math 201" is welcome >and appreciated. I would say the model is oversimplified, as it takes into account the trivial and computationally simple component, i.e. population of the cache and completely ignores the hard part -- invalidation of cache entries on changes in routing table. With moderate flap the cost of invalidation far exceeds the cost of loading. Incidentally, the route cache invaliadtion algorithms are so hairy that OFRV counldn't get it right for quite a time. --vadim From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 10:00:43 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01686; Wed, 8 Nov 1995 10:00:43 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA02950; Wed, 8 Nov 1995 10:00:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02935; Wed, 8 Nov 1995 09:45:48 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB32185; Wed, 8 Nov 1995 09:45:44 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id RAA27415; Tue, 7 Nov 1995 17:43:13 -0500 From: Tim Bass Message-Id: <199511072243.RAA27415@dune.silkroad.com> Subject: Re: Cache Math 101 To: avg@sprint.net (Vadim Antonov) Date: Tue, 7 Nov 1995 17:43:13 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511072233.RAA03012@titan.sprintlink.net> from "Vadim Antonov" at Nov 7, 95 05:33:35 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1750 Precedence: bulk Vadim writes: > I would say the model is oversimplified, as it takes into account > the trivial and computationally simple component, i.e. population > of the cache and completely ignores the hard part -- invalidation > of cache entries on changes in routing table. With moderate flap > the cost of invalidation far exceeds the cost of loading. > > Incidentally, the route cache invaliadtion algorithms are so hairy > that OFRV counldn't get it right for quite a time. Vadim, as a math major from a respected uni, perhaps you would care to make the model more accurate. The lead in statement..."Not"... on your part is very expressive, but I would venture to say the "Not" is much more of an oversimplification than; L1 + M*L2 As a math major and respectable algorithm developer, it would be interesting and enlightening to see your first approximation of a bimodal cache. Your background and experience would be very helpful. Could you please assist us with your mathematical translation of "Not" ? Just one step forward, mathematically speaking of course, would be helpful and appreciated :-) Thanks, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 10:40:45 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02146; Wed, 8 Nov 1995 10:40:45 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA02989; Wed, 8 Nov 1995 10:40:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA02977; Wed, 8 Nov 1995 10:22:52 +1100 Received: from stilton.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB00367; Wed, 8 Nov 1995 10:22:51 +1100 (from fred@cisco.com) Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id PAA22390; Tue, 7 Nov 1995 15:21:52 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 7 Nov 1995 15:21:55 -0800 To: Vadim Antonov From: fred@cisco.com (Fred Baker) Subject: Re: Cache Math 101 Cc: bass@dune.silkroad.com, big-internet@munnari.OZ.AU Precedence: bulk At 5:33 PM 11/7/95, Vadim Antonov wrote: >Not. You can't fool the rule that working sets exceeding cache >size cause trashing. The size of working set in this case is the >characteristic of traffic and does not depend on the cacheing >algorithm used. While I generally agree with that statement, permit the footnote that the hashing algorithm and cache architecture are indeed relevant. Taking the worst case, if the hash algorithm is hash(address) { return 0; } a bidirectional traffic stream will exceed the size of the representable working set. Good hashing algorithms do in fact work better than bad ones, and more memory or good lookup organization is better than less memory and bad organization. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 10:42:03 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05750; Wed, 8 Nov 1995 10:42:03 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA03012; Wed, 8 Nov 1995 10:41:54 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA02980; Wed, 8 Nov 1995 10:33:14 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02545; Wed, 8 Nov 1995 10:33:12 +1100 (from mn@tremere.ios.com) Received: from tremere.ios.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06505 Wed, 8 Nov 1995 10:14:12 +1100 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.12/8.6.9) id SAA04369; Tue, 7 Nov 1995 18:11:34 -0500 Date: Tue, 7 Nov 1995 18:11:33 -0500 (EST) From: Mike Subject: Re: Cache Math 101 To: Valdis.Kletnieks@vt.edu Cc: Tim Bass , big-internet@munnari.OZ.AU In-Reply-To: <199511072202.RAA34104@black-ice.cc.vt.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 7 Nov 1995 Valdis.Kletnieks@vt.edu wrote: > On Tue, 07 Nov 1995 16:36:26 EST, you said: > > Exactly, that's agood question. If L2 ----> L1; the simple model > > reduces to L1(1+M) which now has the additional cost of M so the > > question why bother with M at all is valid, indeed. > > Make up your mind. Is L2 the *added* latency, or the *total* latency? Choose > one and stick with it. Here you seem to be saying it's the total (as there > is no reason for *added* latency's lower bound to be the same as a cache hit). > > > On the other hand, if we had a single cache then L1 must be larger > > because the cache is bigger..... (consider the last entry found by > > a hash function in the forwarding table) well, I just suffered and deleted until now: man, hash is not scaling with data volume, if the function is ok it just does more bins. Hash is certainly sublinear with data volume, if the data is diverse enough, or if the function is adapted to the data contents. The last entry can be found first, btw! ... things are not what they seem to be .... it is not fair Bowie 'Labyrinth' > > Multiple parse errors encountered. L1 must be larger than what? And what > should I be considering about the last entry? > > > My "Cache Math 101" point is simply this: > > > > If we can agree on the simple Cache Math 101 at least in principal, the > > We can agree when you start using variables in a consistent manner. > > > we can explore the cost-benefits of designing a routed > > architecture with the agreed model. Maybe the overly simply model > > presented is not practical: > > > > L1 + M*L2 overly simple caching model > > Here, you're back to using L2 as added latency. > > > I would be very interested to see any mathematical models of > > caching that provide a more accurate simple representation > > of the foundations of a bimodal cache system. > > It's easy to make a model that provides a more accurate representation. > Unfortunately, you seem to be lacking the basic mathematical and logical > tools needed to follow such a discussion. > > Learn some algebra. Study some queuing theory. Learn something. Come back > when you have a clue. In the meantime, go square the circle, or prove that > 1 = 2, or any of the other great mathematical challenges you seem very well > suited to pursue.... > > /Valdis > ---------------------------------------------------------- IDT Michael F. Nittmann --------- Senior Network Architect \ / (201) 928 1000 xt 500 ------- (201) 928 1888 FAX \ / mn@ios.com --- V IOS From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 11:00:38 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA31967; Wed, 8 Nov 1995 11:00:38 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA03037; Wed, 8 Nov 1995 11:00:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA03007; Wed, 8 Nov 1995 10:41:35 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01514; Wed, 8 Nov 1995 10:41:32 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id SAA27775; Tue, 7 Nov 1995 18:38:53 -0500 From: Tim Bass Message-Id: <199511072338.SAA27775@dune.silkroad.com> Subject: Re: Cache Math 101 To: Valdis.Kletnieks@vt.edu Date: Tue, 7 Nov 1995 18:38:53 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511072202.RAA34104@black-ice.cc.vt.edu> from "Valdis.Kletnieks@vt.edu" at Nov 7, 95 05:02:07 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1418 Precedence: bulk Valdis, it takes extreme patience to discuss math with you. My math is very clear. I suggest you study some basic math.... but one last time, just for you and to try to practice extreme patience. L1 is the latency of the system without a miss. L2 is the ADDITIONAL latency with a miss. L2 + ML1 is the TOTAL latency. Valdis.... please explain what you do not understand about this ??? Now, showing more than the patience of a normal technical person.... L1 ----> L2 Valdis, what does the above expression mean in your mind ?? It means the value of L1 approaches the value of L2.... do you Valdis understand what I will answer no more "Valdis is confused on L1 and L2", hope you understand, everyone. I do not profess to be a teacher of basic math to lost college students. Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 12:20:40 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB11344; Wed, 8 Nov 1995 12:20:40 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03085; Wed, 8 Nov 1995 12:20:28 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03081; Wed, 8 Nov 1995 12:02:09 +1100 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05896; Wed, 8 Nov 1995 12:01:54 +1100 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id UAA03266; Tue, 7 Nov 1995 20:01:33 -0500 Date: Tue, 7 Nov 1995 20:01:33 -0500 From: Vadim Antonov Message-Id: <199511080101.UAA03266@titan.sprintlink.net> To: avg@sprint.net, fred@cisco.com Subject: Re: Cache Math 101 Cc: bass@dune.silkroad.com, big-internet@munnari.OZ.AU Precedence: bulk fred@cisco.com (Fred Baker) wrote: >While I generally agree with that statement, permit the footnote that the >hashing algorithm and cache architecture are indeed relevant. Taking the >worst case, if the hash algorithm is > hash(address) { > return 0; > } >a bidirectional traffic stream will exceed the size of the representable >working set. Good hashing algorithms do in fact work better than bad ones, >and more memory or good lookup organization is better than less memory and >bad organization. Yes, sure. That is the whole can of worms, however for most hit patterns you cannot get much better than simple random entry replacement. Internet traffic appears to have that property, as it is basically the aggregation of a large number of relatively low-speed streams, not one high-speed stream like instruction fetches in CPUs following some pre-defined pattern. I.e. during a reasonable interval of time you'll get hits to most destinations, although individual destinations are not frequent. There are no "tight loops" (or sequenced trains of packets scanning the relatively small range of destinations) in the Internet :) Also, the number of destinations (or "main memory cells") is by two-three orders of magnitude less than the number of memory cells of a vanilla computer, while the cache sizes are comparable. I.e. the benefit of maintainig cache vs using cache as the "memory" is two-three orders of magnitude less, while costs are the same. Anyway, the most important factor in cache/no-cache decision is so far not the cost but rather reliability. Cacheing of dynamically changing routing tables proved to be quite a challenge. Being in the skin of an ISP operator i would spend more money but get a box which won't go banana now and then. No fancy algorithms, thank you. --vadim From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 13:20:50 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16376; Wed, 8 Nov 1995 13:20:50 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03130; Wed, 8 Nov 1995 13:20:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03124; Wed, 8 Nov 1995 13:12:53 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15270; Wed, 8 Nov 1995 13:12:48 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id VAA28823 for big-internet@munnari.OZ.AU; Tue, 7 Nov 1995 21:09:48 -0500 From: Tim Bass Message-Id: <199511080209.VAA28823@dune.silkroad.com> Subject: Re: Cache Math 101 To: big-internet@munnari.OZ.AU Date: Tue, 7 Nov 1995 21:09:48 -0500 (EST) In-Reply-To: <199511072338.SAA27775@dune.silkroad.com> from "Tim Bass" at Nov 7, 95 06:38:53 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2087 Precedence: bulk Big-Internet Gurus I thought that I was clear that "Cache Math 101" was created to be basis for working together to create a mathematical model for a bimodal cache. Just like any engineering model, first you build a simple model, then massage it, then create a more complex model, and so forth. (Maybe some of you have never done this....... sorry) When we offer a simple FIRST BABY STEP, like " L1 + L2 * M " one would expect interested parties to respond... "You stated the total latency is L1 + L2 * M, but I think is it L1 + M * L2 + K * L3, where K is the blah blah blah, and L3 is the nah nah nah...." and so forth. It was my hope that we could work on this in a civilized, intellectual manner and that people would offer constructive mathematical ideas and building blocks to the model. Perhaps in certain cultures or countries, the "standard way of doing business" is to hurl insults even at simple things like L1 and L2, but I find it childish, immature, and very unproductive. If any of these insulting individuals care to enlighten us with their mathematical ability to: 1) Start with a simple concept; 2) Express it in mathematical terms; 3) Define and agree on the symbols; 4) Evaluate and add to the model (repeating steps 2 - 4) Then by all means, please be constructive. thank you. Anything mathematically constructive to add is of value to a discussion related to mathematics. Please leave your egos and insults somewhere else. Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 20:40:56 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10096; Wed, 8 Nov 1995 20:40:56 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA03185; Wed, 8 Nov 1995 20:40:38 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03179; Wed, 8 Nov 1995 20:23:19 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08166; Wed, 8 Nov 1995 20:23:17 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA15228; Wed, 8 Nov 1995 01:23:11 -0800 Date: Wed, 8 Nov 1995 01:23:11 -0800 From: Tony Li Message-Id: <199511080923.BAA15228@greatdane.cisco.com> To: almes@advanced.org Cc: amolitor@anubis.network.com, big-internet@munnari.OZ.AU In-Reply-To: <199511071341.IAA22972@betelgeuse.advanced.org> (message from Guy T Almes on Tue, 07 Nov 1995 08:42:51 -0500) Subject: Re: Caching Precedence: bulk Guy, Be careful about contradicting Andrew on this point... Thank you, but I'm _very_ secure in what I'm saying. I understand thrashing VERY well. In addition to being a Unix sysadmin for a major university, I used to teach Operating Systems. Betcha didn't know that.... ;-) On the one hand you say you are not thrashing: >For the record, no, that's NOT what I'm saying. Our cache is not >thrashing. > . . . And on the other hand you give an almost textbook definition of thrashing: I'm sorry, but you're the one that doesn't understand thrashing. Fact: today, the working set fits in cache. Depending on where you look, there's a factor of 2-6 to spare. [No, this is not comfortable, but then again, this hardware is scheduled to be rotated out fairly shortly, I hope...] >I'm trying to make the following points: > >1) We have evidence that indicates that the working set is a very >large percentage of the entire table. This would reduce (or more >likely, negate) the savings obtained by caching. This says that the working set is 40% of the "memory" used by the "process". This does NOT imply that it doesn't fit in the cache. >2) That the percentage is increasing, not decreasing. This implies >that the above savings is decreasing over time. This further implies >that the switching table grows proportionately to the full routing >table, or possibly worse. That's to say, the working set is growing as a proportion of the "memory" used. >3) The cost of a cache miss in a 7000 is painful. . . . And that we "page fault" to a verra slow disk.... ;-) Fortunately, because there IS lotsa free space in the cache, the invalidation policy is EXTREMELY generous. Thus we "page fault" only for extreme circumstances. The term thrashing arose in the mid-60s when time-sharing systems were beginning to use demand paging to allow multiple processes to share a limited amount of physical memory. Within a fairly short period of time, most of the clever algorithms were thought of and implemented with a varying degree of elegance, but the systems ran more slowly than their designers had hoped. Peter Denning made his initial splash on the Operating Systems community by coining the term 'thrashing' to characterize the situations being encountered and by pointing out that all the caching algorithm cleverness in the world would not save you *if you tried to support too many processes with too little physical memory*. His thesis worked to characterize what 'enough physical memory' for a given process might mean, and he coined the term 'working set' to capture this. Putting the two ideas together, you get (more or less by definition) Andrew's statement that: > Again: If your working set exceeds cache size, you *will* thrash. This is not a criticism of the idea of a cache or of the Cisco design. Thrashing can happen, quite simply, because the cache size is not as big as it needs to be avoid the situation that you correctly characterize. Yer preachin' to the Bishop. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 23:40:50 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05970; Wed, 8 Nov 1995 23:40:50 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA03235; Wed, 8 Nov 1995 23:40:39 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA03229; Wed, 8 Nov 1995 23:32:18 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05727; Wed, 8 Nov 1995 23:32:18 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA24074; Wed, 8 Nov 1995 04:31:44 -0800 Date: Wed, 8 Nov 1995 04:31:44 -0800 From: Tony Li Message-Id: <199511081231.EAA24074@greatdane.cisco.com> To: avg@sprint.net (Vadim Antonov) Cc: avg@sprint.net, fred@cisco.com, bass@dune.silkroad.com, big-internet@munnari.OZ.AU Subject: Re: Cache Math 101 Precedence: bulk Being in the skin of an ISP operator i would spend more money but get a box which won't go banana now and then. No fancy algorithms, thank you. Too bad you couldn't get your former employer to agree with you. Tony From owner-Big-Internet@munnari.OZ.AU Wed Nov 8 23:42:39 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06120; Wed, 8 Nov 1995 23:42:39 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA03257; Wed, 8 Nov 1995 23:42:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA03226; Wed, 8 Nov 1995 23:27:35 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05298; Wed, 8 Nov 1995 23:27:34 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA23990; Wed, 8 Nov 1995 04:26:58 -0800 Date: Wed, 8 Nov 1995 04:26:58 -0800 From: Tony Li Message-Id: <199511081226.EAA23990@greatdane.cisco.com> To: avg@sprint.net (Vadim Antonov) Cc: bass@dune.silkroad.com, big-internet@munnari.OZ.AU Subject: Re: Cache Math 101 Precedence: bulk I would say the model is oversimplified, as it takes into account the trivial and computationally simple component, i.e. population of the cache and completely ignores the hard part -- invalidation of cache entries on changes in routing table. With moderate flap the cost of invalidation far exceeds the cost of loading. More to the point, the "soliton" properties of a flap introduce a _transient_ into the system which no one here has considered. This is the problem to focus on... Incidentally, the route cache invaliadtion algorithms are so hairy that OFRV counldn't get it right for quite a time. Indeed. And I should point out that it's not the invalidation algorithms per-se so much as where to apply them. There turn out to be many cases... While I have the floor: it was postulated that L2 ----> L1 in fact, the observed phenomena is closer to L1 -- ---> 0 L2 Which is to say: the fast hardware gets faster, the messy case gets messier, and the slower hardware doesn't get sped up faster than the mess grows. Which is to also to say: thermodynamics is still enforced here. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 00:40:48 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08269; Thu, 9 Nov 1995 00:40:48 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA03395; Thu, 9 Nov 1995 00:40:38 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA03388; Thu, 9 Nov 1995 00:25:14 +1100 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07818; Thu, 9 Nov 1995 00:25:11 +1100 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA14581; Wed, 8 Nov 95 07:26:02 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA24582; Wed, 8 Nov 95 07:25:45 CST Date: Wed, 8 Nov 95 07:25:45 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9511081325.AA24582@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Cache Math 101 Precedence: bulk By way of contributing, or something. Perhaps just adding fuel to the fire? The latency model (which I wash my hands of completely, by the way) completely ignores service rates. The wretchedly simple equations for throughput look a lot like the wretchedly simple equations for latency. You see more amusing results, though. If you get the biggest baddest fire-breathingest Unix box money can buy today, and set it up as some sort of route server, it's not going to be able to service more than a few thousand cache faults per second. So if you're moving 50K pps, you cannot tolerate a miss ratio of more than about 10 percent (5K faults/sec). You might be able to do something strange and wonderful with your favorite flavor of Big NFS server and forwarding-databases-as-files, which would be sort of cute, and might give you a good service rate. You'd need good salesmen to sell the customer on the idea of the top of the line auspex as a co-processor. Andrew From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 00:41:42 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08403; Thu, 9 Nov 1995 00:41:42 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA03419; Thu, 9 Nov 1995 00:41:33 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA03391; Thu, 9 Nov 1995 00:25:56 +1100 Received: from betelgeuse.advanced.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07831; Thu, 9 Nov 1995 00:25:51 +1100 (from almes@advanced.org) Received: from canopus by betelgeuse.advanced.org via SMTP (940816.SGI.8.6.9/940406.SGI) id IAA28583; Wed, 8 Nov 1995 08:25:43 -0500 Message-Id: <199511081325.IAA28583@betelgeuse.advanced.org> X-Sender: almes@betelgeuse.advanced.org X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 08 Nov 1995 08:27:26 -0500 To: Tony Li From: Guy T Almes Subject: Re: Caching Cc: almes@advanced.org, amolitor@anubis.network.com, big-internet@munnari.OZ.AU Precedence: bulk Your holiness, :-) At 01:23 AM 11/8/95 -0800, Tony Li wrote: >Guy, > Be careful about contradicting Andrew on this point... >Thank you, but I'm _very_ secure in what I'm saying. I understand >thrashing VERY well. In addition to being a Unix sysadmin for a major >university, I used to teach Operating Systems. Betcha didn't know >that.... ;-) I'm *not* surprised. It was precisely because the note came from someone of your background that I was shocked by the contradictions. > On the one hand you say you are not thrashing: > >For the record, no, that's NOT what I'm saying. Our cache is not > >thrashing. > And on the other hand you give an almost textbook definition of thrashing: >I'm sorry, but you're the one that doesn't understand thrashing. It's looking like we might both understand thrashing, but I'm still not sure I understand your note to Andrew. > >Fact: today, the working set fits in cache. Depending on where you >look, there's a factor of 2-6 to spare. [No, this is not comfortable, >but then again, this hardware is scheduled to be rotated out fairly >shortly, I hope...] > >I'm trying to make the following points: > >1) We have evidence that indicates that the working set is a very > >large percentage of the entire table. This would reduce (or more > >likely, negate) the savings obtained by caching. > >This says that the working set is 40% of the "memory" used by the "process". >This does NOT imply that it doesn't fit in the cache. What is your definition of a working set here? By the way, I'm impressed that you manage to have 40% of your entire routing table's entries in the cache with a factor of 2 to 6 to spare (or did I misunderstand you again). And does this statement of having a factor of 2 to 6 to spare hold for 7000s at exchange points where full routing tables combine with comparitively low locality of reference of destination IP address (at least compared with the better locality of reference you get with, say, a campus router)? And don't take this as a sarcastic attack, I'm genuinely interested. > > >2) That the percentage is increasing, not decreasing. This implies > >that the above savings is decreasing over time. This further implies > >that the switching table grows proportionately to the full routing > >table, or possibly worse. >That's to say, the working set is growing as a proportion of the >"memory" used. By the way, I believe this, and *especially* at the exchange points. > > >3) The cost of a cache miss in a 7000 is painful. . . . >And that we "page fault" to a verra slow disk.... ;-) > >Fortunately, because there IS lotsa free space in the cache, the >invalidation policy is EXTREMELY generous. Thus we "page fault" only >for extreme circumstances. I believe this too, but let me make one point and ask one question: [p] When Denning defined 'working set' the slowness of the disk was taken into account. Thus, if the disk is slower, then the working set (for the same program execution) would be bigger. Thus, if the cost of a cache miss is large, then so also is the corresponding working set. [q] If there's so much free space left in the cache, what is the cause of what 'page faults' you do experience? > > The term thrashing arose in the mid-60s when time-sharing systems were > beginning to use demand paging to allow multiple processes to share a > limited amount of physical memory. Within a fairly short period of time, > most of the clever algorithms were thought of and implemented with a varying > degree of elegance, but the systems ran more slowly than their designers had > hoped. Peter Denning made his initial splash on the Operating Systems > community by coining the term 'thrashing' to characterize the situations > being encountered and by pointing out that all the caching algorithm > cleverness in the world would not save you *if you tried to support too many > processes with too little physical memory*. His thesis worked to > characterize what 'enough physical memory' for a given process might mean, > and he coined the term 'working set' to capture this. Putting the two ideas > together, you get (more or less by definition) Andrew's statement that: > > Again: If your working set exceeds cache size, you *will* thrash. > This is not a criticism of the idea of a cache or of the Cisco design. > Thrashing can happen, quite simply, because the cache size is not as big as > it needs to be avoid the situation that you correctly characterize. > >Yer preachin' to the Bishop. ;-) And I'm just a lowly Augustinian :-) -- Guy > >Tony > > From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 02:00:54 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11634; Thu, 9 Nov 1995 02:00:54 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03518; Thu, 9 Nov 1995 02:00:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA03512; Thu, 9 Nov 1995 01:57:42 +1100 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11570; Thu, 9 Nov 1995 01:57:39 +1100 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA15621; Wed, 8 Nov 95 08:58:34 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA25991; Wed, 8 Nov 95 08:58:18 CST Date: Wed, 8 Nov 95 08:58:18 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9511081458.AA25991@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Caching Precedence: bulk I think I see the *real* problem! Now: no problem, the cisco 7000s work. Short term: new ciscos Long term: cost of new ciscos goes up exponentially, persuasiveness of cisco sales force goes up linearly(?) So what's really needed is a scalable sales force, not a scalable routing architecture ;) Andrew From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 03:00:50 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14468; Thu, 9 Nov 1995 03:00:50 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA03552; Thu, 9 Nov 1995 03:00:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03546; Thu, 9 Nov 1995 02:42:21 +1100 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13484; Thu, 9 Nov 1995 02:42:19 +1100 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA16288; Wed, 8 Nov 95 09:43:11 CST Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA26773; Wed, 8 Nov 95 09:42:53 CST Date: Wed, 8 Nov 95 09:42:53 CST From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9511081542.AA26773@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Caching Precedence: bulk Let me take a serious tack, and have a stab at a guess as to what current problems might be. From the murmerings, it looks like the cache behavior is fine, except under routing flaps. It's the (regular, frequent) pain involved in have a wad of cache invalidated underfoot that causes problems. Note that if 30% of cache goes POOF, your instantaneous miss rate goes from 0% to 30% (assuming the cache was fat happy and perfect before the event). If you're running 50K pps, suddenly 15K cache misses/sec slam into your route-server board thingie, and it tips over with its little feet in the air while things get sorted out. Well, it's not quite that bad, but it's surely not pretty. If you're getting this sort of .3 second OW THAT HURT things several times a minute, the cumulative effect, while not agony, would be uncomfortable. All numbers invented out'n my own fuzzy lil haid. Andrew From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 04:20:52 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16409; Thu, 9 Nov 1995 04:20:52 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03592; Thu, 9 Nov 1995 04:20:43 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03581; Thu, 9 Nov 1995 04:09:39 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18288; Thu, 9 Nov 1995 04:09:37 +1100 (from roque@oberon.di.fc.ul.pt) Received: from oberon.di.fc.ul.pt by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25402 Thu, 9 Nov 1995 04:09:27 +1100 (from roque@oberon.di.fc.ul.pt) Received: from localhost (roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) with SMTP id SAA29515 for ; Wed, 8 Nov 1995 18:01:30 +0100 Message-Id: <199511081701.SAA29515@oberon.di.fc.ul.pt> X-Authentication-Warning: oberon.di.fc.ul.pt: Host localhost didn't use HELO protocol X-Authentication-Warning: oberon.di.fc.ul.pt: roque owned process doing -bs X-Mailer: exmh version 1.6.1 5/23/95 To: Big-Internet@munnari.OZ.AU Subject: IPAE From: roque@di.fc.ul.pt Reply-To: roque@di.fc.ul.pt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 08 Nov 1995 18:01:29 +0100 Sender: roque@oberon.di.fc.ul.pt Precedence: bulk Sorry about the silly question but it's ratter important for me... I was looking into the minutes of the "Big Ten Retreat" of may 94 ( IPng area directors comments on proposals ) and the minutes show that a lot of people consider IPAE to be "completely broken" ... the key issue is that "it would require global coordenation".... I'm reading IPAE draft from March 16, 1994 and it cleary states that one of the transition mechanims key features is: - Both hosts and routers may be upgraded to SIPP incrementally. Upgrading one host or router to SIPP is not dependent on any other system being upgraded. Users and network operators may upgrade their systems at their own pace, and without coordinating with each other. This feature is extremely important in the Internet, which has no central operations authority. why is that so that people consider that the transition would require global coordenation ? I did a light reading on the above mentioned draft and i could not find the reason for that criticism... well guess I'm going to have to read it in detail. thanks... PS: please cc the (possible) replys to me since my subscription request hasn't been answered yet... Pedro Roque ( roque@di.fc.ul.pt ) Faculdade de Cijncias da Universidade de Lisboa Departamento de Informatica From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 04:40:48 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20800; Thu, 9 Nov 1995 04:40:48 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03616; Thu, 9 Nov 1995 04:40:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03612; Thu, 9 Nov 1995 04:29:19 +1100 Received: from stilton.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19792; Thu, 9 Nov 1995 04:29:17 +1100 (from fred@cisco.com) Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id JAA27000; Wed, 8 Nov 1995 09:29:10 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Nov 1995 09:29:13 -0800 To: amolitor@anubis.network.com (Andrew Molitor) From: fred@cisco.com (Fred Baker) Subject: Re: Cache Math 101 Cc: big-internet@munnari.OZ.AU Precedence: bulk At 7:25 AM 11/8/95, Andrew Molitor wrote: >So if you're moving 50K pps, you cannot tolerate a >miss ratio of more than about 10 percent (5K faults/sec). Kim Claffy's numbers say that you're an optomist. Try 2% before a noticable slowdown occurs. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 05:02:59 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22779; Thu, 9 Nov 1995 05:02:59 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03648; Thu, 9 Nov 1995 05:00:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03644; Thu, 9 Nov 1995 04:55:28 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22120; Thu, 9 Nov 1995 04:55:25 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id MAA01541; Wed, 8 Nov 1995 12:53:10 -0500 From: Tim Bass Message-Id: <199511081753.MAA01541@dune.silkroad.com> Subject: Re: Cache Math 101 To: bass@dune.silkroad.com (Tim Bass) Date: Wed, 8 Nov 1995 12:53:10 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511071544.KAA24357@dune.silkroad.com> from "Tim Bass" at Nov 7, 95 10:44:26 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 816 Precedence: bulk Tony, Sorry, I lost your post on this expression ( too much beer last night after a bad day yesterday :-) Did you claim that L2/L1 ------> 0; or L1/L2 ------> 0; Thanks. Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 05:22:13 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24340; Thu, 9 Nov 1995 05:22:13 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03684; Thu, 9 Nov 1995 05:20:41 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA03667; Thu, 9 Nov 1995 05:03:55 +1100 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22827; Thu, 9 Nov 1995 05:03:52 +1100 (from ses@tipper.oit.unc.edu) Received: from chivalry (chivalry.eit.COM [192.100.58.30]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id NAA21643; Wed, 8 Nov 1995 13:02:05 -0500 Date: Wed, 8 Nov 1995 10:04:27 -0800 (PST) From: Simon Spero X-Sender: ses@chivalry To: Tony Li Cc: Vadim Antonov , bass@dune.silkroad.com, big-internet@munnari.OZ.AU Subject: Re: Cache Math 101 In-Reply-To: <199511081226.EAA23990@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk [If Big Internet is going to go boom again, I at least want to make sure I understand what's filling up my spool disk :-)] Just to check my understanding of what's being said here- would it be correct to say that they main problem with having outboard route calculation with a cache is that in the busiest routers, the amount of data that needs to be transferred to the forwarding processor to server a typical set of active connections is the same order of magnitude as the size of the entire routing table, and that as a conseqence of this, everytime the routes change, the forwarder would have to fetch the entire table, piece by piece. Further, the amount of data that would be fetched by a caching system is only ~50% less than would be needed to transfer the entire table, and that this 50% savings would be lost by the need to wait for each individual entry to be fetched, as opposed to transferring the entire table en-masse? Simon From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 06:00:53 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26413; Thu, 9 Nov 1995 06:00:53 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03722; Thu, 9 Nov 1995 06:00:41 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA03713; Thu, 9 Nov 1995 05:42:04 +1100 Received: from stilton.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25745; Thu, 9 Nov 1995 05:42:03 +1100 (from fred@cisco.com) Received: from [171.69.128.114] (fred-mac-fr.cisco.com [171.69.128.114]) by stilton.cisco.com (8.6.8+c/8.6.5) with SMTP id KAA00325; Wed, 8 Nov 1995 10:41:28 -0800 X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Nov 1995 10:41:31 -0800 To: Simon Spero From: fred@cisco.com (Fred Baker) Subject: Re: Cache Math 101 Cc: big-internet@munnari.OZ.AU Precedence: bulk At 10:04 AM 11/8/95, Simon Spero wrote: >everytime the routes change, the forwarder would have to fetch the entire >table, piece by piece. > >Further, the amount of data that would be fetched by a caching system is >only ~50% less than would be needed to transfer the entire table, and that >this 50% savings would be lost by the need to wait for each individual >entry to be fetched, as opposed to transferring the entire table en-masse? Yup, that's pretty much it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Some ideas are so crazy that only an intellectual could believe them... George Orwell From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 06:20:49 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB28306; Thu, 9 Nov 1995 06:20:49 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03751; Thu, 9 Nov 1995 06:20:42 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03745; Thu, 9 Nov 1995 06:09:58 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27632; Thu, 9 Nov 1995 06:09:55 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id OAA01941; Wed, 8 Nov 1995 14:06:32 -0500 From: Tim Bass Message-Id: <199511081906.OAA01941@dune.silkroad.com> Subject: Re: Cache Math 101 To: ses@tipper.oit.unc.edu (Simon Spero) Date: Wed, 8 Nov 1995 14:06:32 -0500 (EST) Cc: tli@cisco.com, avg@sprint.net, big-internet@munnari.OZ.AU In-Reply-To: from "Simon Spero" at Nov 8, 95 10:04:27 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1363 Precedence: bulk Simon says: :-) > ... typical set of active connections is the same order of magnitude as the > size of the entire routing table, and that as a conseqence of this, > everytime the routes change, the forwarder would have to fetch the entire > table, piece by piece. > This is a cache implementation issue at best. The more efficient simplified miss algorithm might be: 1) Search cache for a hit; 2) Miss; 3) Send address to adjunct processor; 4) Hit; 5) Return hit to cache. 6) Move cold entry (entries) to AP (parallel process). There is no reason to thrash, crash, or mash if the implementation is done 'intelligently' and the system architecuture and algorithms are well developed for this application. Regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 11:01:02 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13049; Thu, 9 Nov 1995 11:01:02 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA03811; Thu, 9 Nov 1995 11:00:43 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA03805; Thu, 9 Nov 1995 10:41:26 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB18925; Thu, 9 Nov 1995 10:41:25 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id PAA05796; Wed, 8 Nov 1995 15:40:50 -0800 Date: Wed, 8 Nov 1995 15:40:50 -0800 From: Tony Li Message-Id: <199511082340.PAA05796@greatdane.cisco.com> To: ses@tipper.oit.unc.edu Cc: avg@sprint.net, bass@dune.silkroad.com, big-internet@munnari.OZ.AU In-Reply-To: (message from Simon Spero on Wed, 8 Nov 1995 10:04:27 -0800 (PST)) Subject: Re: Cache Math 101 Precedence: bulk [If Big Internet is going to go boom again, I at least want to make sure I understand what's filling up my spool disk :-)] Just to check my understanding of what's being said here- would it be correct to say that they main problem with having outboard route calculation with a cache is that in the busiest routers, the amount of data that needs to be transferred to the forwarding processor to server a typical set of active connections is the same order of magnitude as the size of the entire routing table, and that as a conseqence of this, everytime the routes change, the forwarder would have to fetch the entire table, piece by piece. Further, the amount of data that would be fetched by a caching system is only ~50% less than would be needed to transfer the entire table, and that this 50% savings would be lost by the need to wait for each individual entry to be fetched, as opposed to transferring the entire table en-masse? Simon, Most of this is correct. I would differ by saying that the savings is inconsequential given the rate of growth and given the deleterious effects of L1 >> L2. Tony From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 12:41:13 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB19517; Thu, 9 Nov 1995 12:41:13 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA03847; Thu, 9 Nov 1995 12:40:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03841; Thu, 9 Nov 1995 12:28:52 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19456; Thu, 9 Nov 1995 12:28:50 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA14518; Wed, 8 Nov 1995 17:28:41 -0800 Date: Wed, 8 Nov 1995 17:28:41 -0800 From: Tony Li Message-Id: <199511090128.RAA14518@greatdane.cisco.com> To: almes@advanced.org Cc: almes@advanced.org, amolitor@anubis.network.com, big-internet@munnari.OZ.AU In-Reply-To: <199511081325.IAA28583@betelgeuse.advanced.org> (message from Guy T Almes on Wed, 08 Nov 1995 08:27:26 -0500) Subject: Re: Caching Precedence: bulk >Fact: today, the working set fits in cache. Depending on where you >look, there's a factor of 2-6 to spare. [No, this is not comfortable, >but then again, this hardware is scheduled to be rotated out fairly >shortly, I hope...] > >I'm trying to make the following points: > >1) We have evidence that indicates that the working set is a very > >large percentage of the entire table. This would reduce (or more > >likely, negate) the savings obtained by caching. > >This says that the working set is 40% of the "memory" used by the "process". >This does NOT imply that it doesn't fit in the cache. What is your definition of a working set here? My working set is the set of prefixes that have to be in the cache at an interconnect before I see the CPU unpeg itself. ;-) By the way, I'm impressed that you manage to have 40% of your entire routing table's entries in the cache with a factor of 2 to 6 to spare (or did I misunderstand you again). I don't think you misunderstand. And does this statement of having a factor of 2 to 6 to spare hold for 7000s at exchange points where full routing tables combine with comparitively low locality of reference of destination IP address (at least compared with the better locality of reference you get with, say, a campus router)? And don't take this as a sarcastic attack, I'm genuinely interested. Yes, the factor of 2 (actually a tad more) is what happens at the interconnects. Note that a factor of 2-6x is not long at all in the face of exponential growth. >Fortunately, because there IS lotsa free space in the cache, the >invalidation policy is EXTREMELY generous. Thus we "page fault" only >for extreme circumstances. I believe this too, but let me make one point and ask one question: [p] When Denning defined 'working set' the slowness of the disk was taken into account. Thus, if the disk is slower, then the working set (for the same program execution) would be bigger. Thus, if the cost of a cache miss is large, then so also is the corresponding working set. This is assuming that you're doing LRU cache invalidation or some kind of on-demand invalidation. Because the working set is smaller than the cache, we don't need to... [q] If there's so much free space left in the cache, what is the cause of what 'page faults' you do experience? Route flaps. Tony From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 13:00:54 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21269; Thu, 9 Nov 1995 13:00:54 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03874; Thu, 9 Nov 1995 13:00:43 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03870; Thu, 9 Nov 1995 12:48:21 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20764; Thu, 9 Nov 1995 12:48:18 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA15519; Wed, 8 Nov 1995 17:47:46 -0800 Date: Wed, 8 Nov 1995 17:47:46 -0800 From: Tony Li Message-Id: <199511090147.RAA15519@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511090139.UAA04418@dune.silkroad.com> (message from Tim Bass on Wed, 8 Nov 1995 20:39:37 -0500 (EST)) Subject: Re: Cache Math 101 Precedence: bulk > Most of this is correct. I would differ by saying that the savings is > inconsequential given the rate of growth and given the deleterious > effects of L1 >> L2. Let L1 be the latency throught the box with a cache hit; Let L2 be the additional latency to take a cache miss ( T to T' time) My apologies, that's a typo. L2 >> L1. Tony From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 13:02:05 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22274; Thu, 9 Nov 1995 13:02:05 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03901; Thu, 9 Nov 1995 13:01:56 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03865; Thu, 9 Nov 1995 12:42:29 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20569; Thu, 9 Nov 1995 12:42:23 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id UAA04418; Wed, 8 Nov 1995 20:39:37 -0500 From: Tim Bass Message-Id: <199511090139.UAA04418@dune.silkroad.com> Subject: Re: Cache Math 101 To: tli@cisco.com (Tony Li) Date: Wed, 8 Nov 1995 20:39:37 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511082340.PAA05796@greatdane.cisco.com> from "Tony Li" at Nov 8, 95 03:40:50 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3707 Precedence: bulk Tony, thanks for this approximation: > Most of this is correct. I would differ by saying that the savings is > inconsequential given the rate of growth and given the deleterious > effects of L1 >> L2. > Quick review: Let L1 be the latency throught the box with a cache hit; Let L2 be the additional latency to take a cache miss ( T to T' time) Let M be the probability of a cache miss; The average latency of the box ( a very simple model ) is: ( 1 - M ) * L1 + M * ( L1 + L2 ) (Eq.1) This further reduces to: L1 + M * L2 Tony claims that L1 >> L2. Let: L1 = S1 + H1 + F1 (the switch latency); and Let: L2 = S2 + H2 + F2 (the cache miss latency) ; where S1 = Time to get the packet, grab the destination address; H1 = Time to search the forwarding cache for a hit; F1 = Time to send the hit to the forwarding queue; and S2 = Time to initialize the adjunct processor (AP); H2 = Time to search the forwarding table in the AP; and F2 = Time to send the results back to the cache. [ note: if you don't agree with the components of L1 and L2 please feel free to enlighten us with other symbols or expressions , but it does not really matter, L1 remains L1 and L2 remains L2 ! ] Tony claims that L1 >> L2 and; If L1 is much greater than L2 and, as Tony points out, L2/L1 ----> ZERO Then we can take a first order approximation of Eq. 1 to reduce, very straight forward and easily to: L1 + M*L2 -----> L1 when L1 >> L2; L2/L1 ----> 0 Given the first order components of L1 and L2 above. Simple elementary precalculus tells us that this is only possible if: S + F >>> H And it simply follows that: S1 + F1 >> S2 + F2 This simple means that the hash function, if designed properly, is not an important term (I think Tony might have said something to this effect earlier....) and that latency in the forwarding switch is the technically limiting factor. The only logical conclusion is that a properly designed systems architecture can work no better than the speed of the switch processing function and that a well designed cache and hash has only low orders effects. I can easily believe this. It should be intuitively obvious to the casual observer that this is correct. Given a reliable and fast means of caching and hashing, the latency is dominated by the speed of the switch. If the entire table is not cached, and only hot and cold routes are cached in and out in fast RAM and not to disk, then there is no reason what-so-ever to conclude that trashing must occur. Then again, it is easily inferred by observations from OFRV than caching is not the issue when the cache subsystem is designed with optimal system components and algorithms. Hence, to move decouple the fowarding function (switch) and fowarding table (cache) from either an adjunct or internal ubiquitious routing table has and is technically possible because the switching latency is the limiting component of the system in todays (1995) switches. Regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 13:20:56 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23326; Thu, 9 Nov 1995 13:20:56 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA03926; Thu, 9 Nov 1995 13:20:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03892; Thu, 9 Nov 1995 13:01:47 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22151; Thu, 9 Nov 1995 13:01:39 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id UAA04567; Wed, 8 Nov 1995 20:59:01 -0500 From: Tim Bass Message-Id: <199511090159.UAA04567@dune.silkroad.com> Subject: Re: Cache Math 101 To: tli@cisco.com (Tony Li) Date: Wed, 8 Nov 1995 20:59:01 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511090147.RAA15519@greatdane.cisco.com> from "Tony Li" at Nov 8, 95 05:47:46 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1333 Precedence: bulk > > My apologies, that's a typo. L2 >> L1. > > Tony > Well, that sure throws a wet blanket on my last post :-) Sure would be nice if SMTP had a 'search, replace, and delete' capability ! elm -vi":g/L1 >> L2/s/L1 >> L2/L2 >> L1/g" big-internet < latest_blurb Thanks Tony for your swift reply.. I was headed out to have a beer by the fireplace in the local pub, engineering notebook in hand, to sketch out a new architecture. Not now !! Think I'll leave the pens and pocket protectors at home tonight. ( although I have noticed a certain fashion statement for the 'slide rule' hanging off my 501 look.... the opposite sex really goes for the 'slide rule' statement days :-) :-) Best regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 14:21:02 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27226; Thu, 9 Nov 1995 14:21:02 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA03978; Thu, 9 Nov 1995 14:20:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03969; Thu, 9 Nov 1995 14:14:07 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25023; Thu, 9 Nov 1995 14:13:30 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id WAA05030; Wed, 8 Nov 1995 22:10:55 -0500 From: Tim Bass Message-Id: <199511090310.WAA05030@dune.silkroad.com> Subject: Cache Math 102 To: tli@cisco.com (Tony Li) Date: Wed, 8 Nov 1995 22:10:55 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511090147.RAA15519@greatdane.cisco.com> from "Tony Li" at Nov 8, 95 05:47:46 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3443 Precedence: bulk Tony, Big-I Here is the revised version, thanks for the Correction given: L2 >> L1. Quick review: Let L1 be the latency throught the box with a cache hit; Let L2 be the additional latency to take a cache miss ( T to T' time) Let M be the probability of a cache miss; The average latency of the box ( a very simple model ) is: (Note: Andrew has washed his hands of Eq.1) ( 1 - M ) * L1 + M * ( L1 + L2 ) (Eq.1) This further reduces to: L1 + M * L2 or just L1 + ML2 (need TeX ascii :-) Tony claims that from observation L2 >> L1. If L2 is much greater than L1 and, as Tony points out, L1/L2 ----> ZERO Then we can take a first order approximation of Eq. 1 to reduce, very straight forward and easily to: L1 + M*L2 -----> M*L2, L2 >> L1; L1/L2 ----> 0 With the correction from Tony, L2 >> L1, things change dramatically, and obviously, L2 is the limiting factor. The next step, is to look at these dominate terms: Let: L2 = S2 + H2 + F2 ; where S2 = Time to initialize the AP; H2 = Time to search the forwarding table in the AP; and F2 = Time to send the results back to the cache. [ note: if anyone doesen't agree with the components of L1 or L2 please feel free to enlighten us with other symbols or expressions as well as special case variables] In the first approximation, it is save to assume that S2 ~ F2, effectly the speed of transfering the data between the cache and the complete table and back, call it B2, a function of the speed of the I/O process between the forwarding table cache and the entire table. Obviously, this can be sigificantly *decreased* by optimizing the transfer algorithm between the bimodal systems. It is probally safe to assume, in the first order approximation, that B2 >> H2, simple stating that the transfer time is much slower than the hash function in the adjunct process. So it would seem obvious that a high speed bus between the forwarding table and the complete routing table is necessary and that the only situation where this architecuture might work is when L2 ----> L1, and this (not knowing the system details) seems extremely difficult. Thanks Tony for helping me out on this and letting me know that you observe L2 >> L1, and as you point out, L1/L2 ----> 0, in your practical experience. In this architecture, as many have pointed out in various ways, caching is not practical, indeed. The $1,000,000,000 question that begs an answer is ..... " how can we decrease the transfer time between between the forwarding table and the full routing table ??" Whomever solves this problem wins the Big Routing Prize. Sounds like a project for someone to put that high IQ to work on ! Or, are significant improvements in B2 technically unfeasible ? Best regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 15:00:54 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29451; Thu, 9 Nov 1995 15:00:54 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA04005; Thu, 9 Nov 1995 15:00:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03999; Thu, 9 Nov 1995 14:50:12 +1100 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29144; Thu, 9 Nov 1995 14:50:06 +1100 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Thu, 9 Nov 1995 12:42:12 +0900 From: Masataka Ohta Message-Id: <199511090342.MAA15873@necom830.cc.titech.ac.jp> Subject: Re: Cache Math 102 To: bass@dune.silkroad.com (Tim Bass) Date: Thu, 9 Nov 95 12:42:11 JST Cc: tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <199511090310.WAA05030@dune.silkroad.com>; from "Tim Bass" at Nov 8, 95 10:10 pm X-Mailer: ELM [version 2.3 PL11] Precedence: bulk > Let: L2 = S2 + H2 + F2 ; where > > S2 = Time to initialize the AP; > H2 = Time to search the forwarding table in the AP; and > F2 = Time to send the results back to the cache. > It is probally > safe to assume, in the first order approximation, that B2 >> H2, simple > stating that the transfer time is much slower than the hash function > in the adjunct process. If B2 >> H2, and H2 is small enough, just not having the cache is the solution. Unfortunately, as H2 include time to access large amount of (that is, off-chip) memory, latency to access the memory makes B2 ~ H2. But, of course, it is also true that we can't have sufficiently large cache. The currently viable solution, it seems to me, is to use high-end SRAM for the full routing table. Note that, the main memory of current super computers is SRAM. So will that of super routers. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 16:41:18 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05039; Thu, 9 Nov 1995 16:41:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04047; Thu, 9 Nov 1995 16:40:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04041; Thu, 9 Nov 1995 16:34:13 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03680; Thu, 9 Nov 1995 16:34:12 +1100 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA24961 Thu, 9 Nov 1995 16:34:10 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id VAA22123; Wed, 8 Nov 1995 21:32:29 -0800 Date: Wed, 8 Nov 1995 21:32:29 -0800 From: Tony Li Message-Id: <199511090532.VAA22123@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511090310.WAA05030@dune.silkroad.com> (message from Tim Bass on Wed, 8 Nov 1995 22:10:55 -0500 (EST)) Subject: Re: Cache Math 102 Precedence: bulk L1 + M*L2 -----> M*L2, L2 >> L1; L1/L2 ----> 0 With the correction from Tony, L2 >> L1, things change dramatically, and obviously, L2 is the limiting factor. That's one possible conclusion. As we seem to be delving back into reality rather than theory, you need to make your model just a bit more complex. For example M is not a constant. It's a function of time t. Thus, since M(t) * L2 is our first order factor, we need to cummulatively both decrease M(t) and L2. Note that in the face of a route flap, M(t) ---> 1, so limiting route flap is a very good thing. Thanks Tony for helping me out on this and letting me know that you observe L2 >> L1, and as you point out, L1/L2 ----> 0, in your practical experience. In this architecture, as many have pointed out in various ways, caching is not practical, indeed. The $1,000,000,000 question that begs an answer is ..... " how can we decrease the transfer time between between the forwarding table and the full routing table ??" Hint: Drive M(t) or L2 to zero. Preferably both. The currently viable solution, it seems to me, is to use high-end SRAM for the full routing table. Note that, the main memory of current super computers is SRAM. So will that of super routers. Ding ding ding. We have a winner. L2 == 0. Please collect your $1e9 from Mr. Bass. ;-) Note that we're now back to the CIDR argument: given that we have a wodge of SRAM which grows linearly with the size of the routing table, which can grow exponentially and at a faster rate than we can build new SRAM technology. Tony From owner-Big-Internet@munnari.OZ.AU Thu Nov 9 17:41:18 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10134; Thu, 9 Nov 1995 17:41:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA04075; Thu, 9 Nov 1995 17:40:45 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA04069; Thu, 9 Nov 1995 17:40:22 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07413; Thu, 9 Nov 1995 17:40:20 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17255; Thu, 9 Nov 95 01:40:14 -0500 Date: Thu, 9 Nov 95 01:40:14 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511090640.AA17255@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Cache Math 102 Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li Note that we're now back to the CIDR argument: given that we have a wodge of SRAM which grows linearly with the size of the routing table, which can grow exponentially and at a faster rate than we can build new SRAM technology. Can I have $.05 for every time we go around this loop? I don't have anough Lotii yet... :-) Noel From owner-Big-Internet@munnari.OZ.AU Fri Nov 10 03:21:54 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17071; Fri, 10 Nov 1995 03:21:54 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA04316; Fri, 10 Nov 1995 03:21:12 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA04310; Fri, 10 Nov 1995 03:04:30 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17105; Fri, 10 Nov 1995 03:04:10 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id LAA09305; Thu, 9 Nov 1995 11:01:02 -0500 From: Tim Bass Message-Id: <199511091601.LAA09305@dune.silkroad.com> Subject: Re: Cache Math 102 To: tli@cisco.com (Tony Li) Date: Thu, 9 Nov 1995 11:01:02 -0500 (EST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511090532.VAA22123@greatdane.cisco.com> from "Tony Li" at Nov 8, 95 09:32:29 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1324 Precedence: bulk Tony, If our simple little model reduces to M(t) * L2 There are a number of ways, as you point out, to optimize this to: M(t) * L2 -----> L1 -----> 0; If we assume that BGP often flaps M(t) ----> 1 then L2 is still the limiting factor. It is not possible to design an L2 AP function that approaches the speed of L1? Is it safe to assume that O#1FRV would have have already implemented this if they considered it possible? Maybe it simply boils down to CPU cycles and number of instructions..... Thanks again. I find it much easier to understand concepts when they are represented symbolically, like our little model, and I appreciate your patience. Best regards, -Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Fri Nov 10 06:21:26 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25727; Fri, 10 Nov 1995 06:21:26 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA04417; Fri, 10 Nov 1995 06:21:05 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04411; Fri, 10 Nov 1995 06:16:37 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16524; Fri, 10 Nov 1995 06:16:35 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id LAA29586; Thu, 9 Nov 1995 11:15:59 -0800 Date: Thu, 9 Nov 1995 11:15:59 -0800 From: Tony Li Message-Id: <199511091915.LAA29586@greatdane.cisco.com> To: bass@dune.silkroad.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199511091601.LAA09305@dune.silkroad.com> (message from Tim Bass on Thu, 9 Nov 1995 11:01:02 -0500 (EST)) Subject: Re: Cache Math 102 Precedence: bulk Tim, If we assume that BGP often flaps M(t) ----> 1 then L2 is still the limiting factor. It is not possible to design an L2 AP function that approaches the speed of L1? Is it safe to assume that O#1FRV would have have already implemented this if they considered it possible? Maybe it simply boils down to CPU cycles and number of instructions..... You should assume that YFRV is not sitting on its posterior maximus, that it has some clue, and you should recall that development takes MUCH more time than theory. Tony From owner-Big-Internet@munnari.OZ.AU Fri Nov 10 13:21:46 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13785; Fri, 10 Nov 1995 13:21:46 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA04470; Fri, 10 Nov 1995 13:21:18 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA04464; Fri, 10 Nov 1995 13:10:30 +1100 Received: from jgc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12030; Fri, 10 Nov 1995 13:10:24 +1100 (from @mail.jgc.com:Techsupport@jgc.com) Received: from mail.jgc.com ([134.24.2.2]) by mail.jgc.com with SMTP id <21843>; Thu, 9 Nov 1995 15:32:23 -0800 X-Sender: techsupport@jgc.com (Unverified) X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: techsupport@jgc.com From: Publisher Program Subject: New Technology from Johnson-Grace Company Content-Transfer-Encoding: 7bit Message-Id: <95Nov9.153223pst.21843@mail.jgc.com> Date: Thu, 9 Nov 1995 10:08:36 -0800 Precedence: bulk I saw your address on a web page recently, and thought that you might be interested in our new image and speech compression. Our "ART" compression produces files that average 3 times smaller than GIFs and JPEGs. We have a plug-in for Netscape 2.0 coming out, and we're already built into the AOL, GNN, Teachersoft and Frontier browsers. If you're interested, please check out our web site for free trial software. ----------------------------------------- Geoff LeBlond Vice President, Licensing Johnson-Grace Company (714)759-0700 voice, (714)729-4643 fax web site: http://www.jgc.com ----------------------------------------- From owner-Big-Internet@munnari.OZ.AU Fri Nov 10 15:41:49 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB24110; Fri, 10 Nov 1995 15:41:49 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA04505; Fri, 10 Nov 1995 15:41:20 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA04499; Fri, 10 Nov 1995 15:33:18 +1100 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23597; Fri, 10 Nov 1995 15:33:11 +1100 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id VAA06210; Thu, 9 Nov 1995 21:45:35 -0800 Date: Thu, 9 Nov 1995 21:45:35 -0800 (PST) From: Michael Dillon X-Sender: michael@okjunc.junction.net To: Publisher Program Cc: techsupport@jgc.com Subject: Re: New Technology from Johnson-Grace Company In-Reply-To: <95Nov9.153223pst.21843@mail.jgc.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 9 Nov 1995, Publisher Program wrote: Bullshit! You are a slimy liar and a weasel that deserves to be drawn and quartered for spamming Internet mailing lists with your scam. If GNN and AOL really do use your technology that is a damn good reason to BOYCOTT both AOL and GNN !!! > > > I saw your address on a web page recently, and thought that you might be > interested in our new image and speech compression. Our "ART" compression > produces files that average 3 times smaller than GIFs and JPEGs. We have a > plug-in for Netscape 2.0 coming out, and we're already built into the AOL, > GNN, Teachersoft and Frontier browsers. If you're interested, please check > out our web site for free trial software. > > ----------------------------------------- > Geoff LeBlond > Vice President, Licensing > Johnson-Grace Company > (714)759-0700 voice, (714)729-4643 fax > web site: http://www.jgc.com > ----------------------------------------- > Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 06:46:26 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12269; Thu, 16 Nov 1995 06:46:26 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA05358; Thu, 16 Nov 1995 06:45:46 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA05352; Thu, 16 Nov 1995 06:40:37 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11627; Thu, 16 Nov 1995 06:40:32 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10864; Wed, 15 Nov 95 14:40:03 -0500 Date: Wed, 15 Nov 95 14:40:03 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511151940.AA10864@ginger.lcs.mit.edu> To: HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, jnc@ginger.lcs.mit.edu, nanog@merit.edu Precedence: bulk From: Tim Bass Then, in parallel, CIDR was hailed as the 'way to help save B space [depletion] problems'. ... very surprised to learn that our vision of "completely portable" CIDR address space have been overshadowed by the success of CIDR in another problem area that only those with keen insight at the time could predict, routing table explosion. You keep saying this, but it is *NOT TRUE*. You didn't need "keen insight" to know it was coming, you only needed to be able to *read*, viz (from "Supernetting: an Address Assignment and Aggregation Strategy" RFC-1338, June 1992): As the Internet has evolved and grown over in recent years, it has become painfully evident that it is soon to face several serious scaling problems. These include: ... 2. Growth of routing tables in Internet routers beyond the ability of current software (and people) to effectively manage. ... It has become clear that the first two of these problems are likely to become critical within the next one to three years. This memo attempts to deal with these problems by proposing a mechanism ... So, the routing table problem was well known to be coming at the time that CIDR was under discussion, and the effects of CIDR on address allocation were pointed out in *great* detail in a discussion on the *main* IETF list (look in the archives for the thread "Re: Vote NO on R-L-G IP Address Allocation proposal", and in particular my message of "Sat Oct 31 19:26:04 1992", the infamous "fnortz" message, which pointed out in some detail why renumbering was inevitable). So, if anyone who are around then missed it, they have only themselves to blame. I am damned tired of people rewriting history. Please cease and desist before I become extremely upset. after all, CIRD was only to be an *interim solution* for a few years for B space depletion. IPv6 would take care of that. ... aggregation was now the accepted practice for solving most I problems and was not an *interium* or temporary fix, but was to be a core Internet solution. There is a certain amount of truth to this. CIDR did assume that some "better" fix was coming as part of IPng (and let's not forget, the CIDR debate predated the IPv6 debate - SIP only started to be discussed late that summer). However, as is now I hope obvious to everyone, it's impossible to have a single namespace which is both i) used directly for routing, and ii) identifies hosts directly. To get rid of "renumbering", the Internet needed to split "addresses" as host-identifiers from "addresses" as routing-names, and map one into another. No matter how hard I and some others argued for doing this, though, people didn't want to take that "radical" step of two namespaces. Everyone's moaning now about the painful consequences? Tough. (I take great delight in the fact that one of the principal opponents of splitting off the host-identification function is also one of the people most upset at renumbering. I expect by now, with hindsight to help his understanding along, the irony will have dawned on him.) Technically, the aggregation advocates were correct. Socially and politically, aggregation on a global cooperative scale has problems. Which is why we need *two* namespaces: one for the routing to do what mathematics forces it to, and one for the humans to be able to dork with. there are future social and political implementations of global aggregation that are negative. There are some very painful routing consequences, even with two separate name-spaces (e.g. things like inbound traffic bias), but these are technical problems which will only admit of technical fixes. We have to investigate various possible technical solutions, and weigh the costs of them against the benefit of doing it the way we'd like, but that debate has to be a purely technical one, *not* a policy debate. Now, let's see, where are my winterized, flame proof, long johns? After this email, I'm sure to need numerous layers :-) ;-) Hah! When I get *really* grumpy, you better have something better than miserable protective clothing! Try a bunker reinforced to +125 PSI blast overpressure! :-) Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 08:45:57 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17144; Thu, 16 Nov 1995 08:45:57 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA05567; Thu, 16 Nov 1995 08:45:48 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA05530; Thu, 16 Nov 1995 08:35:54 +1100 Received: from faline.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21100; Thu, 16 Nov 1995 08:34:46 +1100 (from little@faline.bellcore.com) Received: from faline (localhost [127.0.0.1]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id QAA22225; Wed, 15 Nov 1995 16:33:41 -0500 Message-Id: <199511152133.QAA22225@faline.bellcore.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu Subject: Re: Routing wars pending? In-Reply-To: Your message of "Wed, 15 Nov 1995 14:40:03 EST." <9511151940.AA10864@ginger.lcs.mit.edu> Date: Wed, 15 Nov 1995 16:33:40 -0500 From: Mike Little Precedence: bulk In regards to: >(Tim Bass) > Technically, the aggregation advocates were correct. Socially and > politically, aggregation on a global cooperative scale has problems. >(Noel) >Which is why we need *two* namespaces: one for the routing to do what >mathematics forces it to, and one for the humans to be able to dork with. This idea has been around *long* enough. When do we separate the name spaces? How about along with the IPng transition? -Mike From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 10:05:57 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18580; Thu, 16 Nov 1995 10:05:57 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05670; Thu, 16 Nov 1995 10:05:49 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05664; Thu, 16 Nov 1995 10:04:07 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19660; Thu, 16 Nov 1995 10:04:03 +1100 (from nanog@dune.silkroad.com) Received: (from nanog@localhost) by dune.silkroad.com (8.6.12/8.6.9) id RAA05851; Wed, 15 Nov 1995 17:59:35 -0500 From: Tim Bass (@NANOG-LIST) Message-Id: <199511152259.RAA05851@dune.silkroad.com> Subject: Re: Routing wars pending? To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 15 Nov 1995 17:59:35 -0500 (EST) Cc: HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, cidrd@iepg.org, jnc@ginger.lcs.mit.edu, nanog@merit.edu In-Reply-To: <9511151940.AA10864@ginger.lcs.mit.edu> from "Noel Chiappa" at Nov 15, 95 02:40:03 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2354 Precedence: bulk Noel, With all due respects, no one is rewriting history. In early 1993 I had little time to read IETF threads on the aggregation issue, kind sir. We were working 12-16 hours a day moving big corporations and corporate networks into a position to be a part of the big I. It was the AGS+ --- 7000s were just a dream....... and from our vantage point the future address space problems were the least of my worries. Keeping corporate network managers from getting fired because they could not move packets or had to renumber three class Bs to connect were my issues. Keeping high power marketing experts from going way over your head and doing battle over ordering a client to renumber was a daily event. The historical IETF WGs have their history, as you remind us. But it is only fair to point out that there are other practical perspectives and day-to-day operations that have historical significance. The IETF is not the *only* organization allowed to have an opinion (and I use the word "organization" very loosely). I do not wish to argue with my Noel. I would rather pick a fight with the devil..... at least I would stand a fighting chance :-) The topic, I thought was something like "router wars" and address space issues. I simple point out that it is causal that there will be problems with global aggregation; and the social, political, and economic ramifications may possibly overshadow any technical drafts the IETF stores in it's archives. Please do not send any life 200 mm shells toward this bunker. I am still having trouble finding my asbestos long johns and teflon helmet ;-) I'm not one to question your dominance in the field, only to learn and work toward similar goals. Best Regards, Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 10:27:21 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23187; Thu, 16 Nov 1995 10:27:21 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05721; Thu, 16 Nov 1995 10:25:49 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05704; Thu, 16 Nov 1995 10:23:02 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23129; Thu, 16 Nov 1995 10:22:58 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11922; Wed, 15 Nov 95 18:22:53 -0500 Date: Wed, 15 Nov 95 18:22:53 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511152322.AA11922@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, nanog@dune.silkroad.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Tim Bass (@NANOG-LIST) With all due respects, no one is rewriting history. Oh? Seems to me that your claim that CIDR Was intended only as a fix to Class-B simply contradicts *what the documents themselves say*. In early 1993 I had little time to read IETF threads on the aggregation issue, kind sir. So why are you talking about the view, at that point in time, of things you didn't have time to follow or understand? Look, one reason I'm so pissed off is that we keep wasting an incredible amount of time and energy going back over stuff that's already done with. Can we stop wasting things which are in such short supply? Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 10:28:16 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22891; Thu, 16 Nov 1995 10:28:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05741; Thu, 16 Nov 1995 10:26:45 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05701; Thu, 16 Nov 1995 10:12:39 +1100 Received: from westie.gi.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20065; Thu, 16 Nov 1995 10:12:37 +1100 (from alan@westie.gi.net) Received: from gaijin.mid.net (gaijin.gi.net [198.247.250.28]) by westie.gi.net (8.7.1/8.7.1) with ESMTP id RAA15330; Wed, 15 Nov 1995 17:12:10 -0600 (CST) From: Alan Hannan Received: by gaijin.mid.net (8.7.1) id RAA00426; Wed, 15 Nov 1995 17:12:07 -0600 (CST) Message-Id: <199511152312.RAA00426@gaijin.mid.net> Subject: Re: Routing wars pending? To: nanog@merit.edu Date: Wed, 15 Nov 1995 17:12:06 -0600 (CST) Cc: jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, little@faline.bellcore.com (Mike Little) In-Reply-To: <199511152133.QAA22225@faline.bellcore.com> from "Mike Little" at Nov 15, 95 04:33:40 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Salutations. ] >(Tim Bass) ] > Technically, the aggregation advocates were correct. Socially and ] > politically, aggregation on a global cooperative scale has problems. ] >(Noel) ] >Which is why we need *two* namespaces: one for the routing to do what ] >mathematics forces it to, and one for the humans to be able to dork with. ] (Mike) ] This idea has been around *long* enough. When do we separate the name ] spaces? How about along with the IPng transition? I ask the following question naievely because I don't know how to ask it maturely. What are the correlations and contrasts between our current backbone routing problems (wrt space and # of routes) and the FCC decision several years ago to make 1-800 numbers portable. Is there any correlation? I realize (think) that the FCC ruling was localized to the US, perhaps not..... I ask because I see the a potential scenario when we are forced to play hardball wrt non portability of new CIDR routes. Imagine this... Big corporation leaves us having been allocated /21 of address space. We tell them to get new IP numbers from their provider and backbone smart people make it known they won't propogate routes (you wouldn't, right Sean?). They say get stuffed, and get a congress person to propose a bill that all IP numbers are portable. This bill passes. It could happen. Any thoughts? -alan From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 10:46:25 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18138; Thu, 16 Nov 1995 10:46:25 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA05787; Thu, 16 Nov 1995 10:46:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05777; Thu, 16 Nov 1995 10:41:07 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22817; Thu, 16 Nov 1995 10:41:03 +1100 (from avg@sprint.net) Received: from titan.sprintlink.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10463 Thu, 16 Nov 1995 10:40:59 +1100 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id SAA10459; Wed, 15 Nov 1995 18:37:33 -0500 Date: Wed, 15 Nov 1995 18:37:33 -0500 From: Vadim Antonov Message-Id: <199511152337.SAA10459@titan.sprintlink.net> To: jnc@ginger.lcs.mit.edu, little@faline.bellcore.com Subject: Re: Routing wars pending? Cc: HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@dune.silkroad.com, nanog@merit.edu Precedence: bulk Silly. We already *do have two namespaces*. One is EIDs in form of FQDNs. They are portable. Another is IPv4 addresses which aren't. How about fixing the real problem -- i.e. making renumbering easy and removing all hardwired addresses from the software? (And, yes, fixing DNS). The magic-cookie EID scheme is nothing more than more complexity to work around the broken implementations. That extra level of indirection is patently useless otherwise. Even funnier, implementation of magic cookie EIDs requires changes in exactly the same pieces of software which need to be changed to repair existing two-level scheme. Note that fixing DNS (and you *have* to do that anyway if you want to use intermediate EIDs) is a lot easier than replacing routers, and does not introduce compatibility problems at the transport level. Sorry, nobody managed to make any reasonable case pro magic-cookie EIDs as yet. The best rationale i've heard was from Noel who said that his "architect's sense" tells him so. Funny thing, a surgeon i know was at loss when i asked him about this function of organism, should be a new discovery in medicine. --vadim In regards to: >(Tim Bass) > Technically, the aggregation advocates were correct. Socially and > politically, aggregation on a global cooperative scale has problems. >(Noel) >Which is why we need *two* namespaces: one for the routing to do what >mathematics forces it to, and one for the humans to be able to dork with. This idea has been around *long* enough. When do we separate the name spaces? How about along with the IPng transition? -Mike From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 11:06:02 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22578; Thu, 16 Nov 1995 11:06:02 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA05824; Thu, 16 Nov 1995 11:05:49 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA05801; Thu, 16 Nov 1995 10:46:45 +1100 Received: from chops.icp.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23933; Thu, 16 Nov 1995 10:46:42 +1100 (from smd@icp.net) Received: by chops.icp.net id <20701>; Wed, 15 Nov 1995 18:46:32 -0000 From: Sean Doran To: alan@gi.net, nanog@merit.edu Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, HANK@taunivm.tau.ac.il, jnc@ginger.lcs.mit.edu, little@faline.bellcore.com, nanog@dune.silkroad.com Message-Id: <95Nov15.184632-0000_est.20701+11@chops.icp.net> Date: Wed, 15 Nov 1995 18:46:24 -0000 Precedence: bulk >Any thoughts? Yup, when that happens, the USA ends up being the big loser in the game of global Internet connectivity. Sean. From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 11:45:59 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28040; Thu, 16 Nov 1995 11:45:59 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA05885; Thu, 16 Nov 1995 11:45:48 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA05867; Thu, 16 Nov 1995 11:27:30 +1100 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24316; Thu, 16 Nov 1995 11:27:28 +1100 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id QAA21709; Wed, 15 Nov 1995 16:25:59 -0800 Date: Wed, 15 Nov 1995 16:25:59 -0800 From: Tony Li Message-Id: <199511160025.QAA21709@greatdane.cisco.com> To: avg@sprint.net Cc: jnc@ginger.lcs.mit.edu, little@faline.bellcore.com, HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, nanog@dune.silkroad.com, nanog@merit.edu In-Reply-To: <199511152337.SAA10459@titan.sprintlink.net> (message from Vadim Antonov on Wed, 15 Nov 1995 18:37:33 -0500) Subject: Re: Routing wars pending? Precedence: bulk Silly. We already *do have two namespaces*. One is EIDs in form of FQDNs. They are portable. Another is IPv4 addresses which aren't. A FQDN is NOT useable as an EID. The host is not the endpoint. Sorry, nobody managed to make any reasonable case pro magic-cookie EIDs as yet. The best rationale i've heard was from Noel who said that his "architect's sense" tells him so. Funny thing, a surgeon i know was at loss when i asked him about this function of organism, should be a new discovery in medicine. Consider process migration. Tony From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 11:47:16 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26813; Thu, 16 Nov 1995 11:47:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA05907; Thu, 16 Nov 1995 11:47:04 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA05870; Thu, 16 Nov 1995 11:34:30 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14385; Thu, 16 Nov 1995 11:34:23 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id TAA06659; Wed, 15 Nov 1995 19:30:45 -0500 From: Tim Bass Message-Id: <199511160030.TAA06659@dune.silkroad.com> Subject: Re: Routing wars pending? To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 15 Nov 1995 19:30:44 -0500 (EST) Cc: jnc@ginger.lcs.mit.edu, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU In-Reply-To: <9511152322.AA11922@ginger.lcs.mit.edu> from "Noel Chiappa" at Nov 15, 95 06:22:53 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1972 Precedence: bulk > > Look, one reason I'm so pissed off is that we keep wasting an incredible > amount of time and energy going back over stuff that's already done with. Can > we stop wasting things which are in such short supply? > > Noel Also, I don't agree your 'embedded logic' that because today one person is busy with other pursuits or endeavors that their perspective on these events in the future are irrelevant. In fact, it is generally accepted that individuals are conditioned and their objectivity blurred when they are too close to the problems, solutions, and issues for so long. Most of the great discoveries in science and art were and will be from those who take a different approach to an old problem. Why in the sake of humanity would anyone of reason and intellect conclude that the IETF and the Internet are an exeception???? None that I can think of.... Even the Tao states thats a man in a valley loses sight of the mountain. Can all Eastern thought be wrong as well? Can we discuss Hank's valid concern that aggregation and address portability issues are causing problems? Or shall we just change the subject each and every time the issue finds it way into our lives? Or better yet....... Would you take the lead in publishing an Internet draft on IETF related topics 'banned from further discussion? Kind Regards, Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 12:26:11 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29211; Thu, 16 Nov 1995 12:26:11 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA05969; Thu, 16 Nov 1995 12:25:49 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA05952; Thu, 16 Nov 1995 12:22:50 +1100 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29230; Thu, 16 Nov 1995 12:22:46 +1100 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id UAA10615; Wed, 15 Nov 1995 20:22:33 -0500 Date: Wed, 15 Nov 1995 20:22:33 -0500 From: Vadim Antonov Message-Id: <199511160122.UAA10615@titan.sprintlink.net> To: avg@sprint.net, tli@cisco.com Subject: Re: Routing wars pending? Cc: HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, little@faline.bellcore.com, nanog@dune.silkroad.com, nanog@merit.edu Precedence: bulk >A FQDN is NOT useable as an EID. The host is not the endpoint. Ok. FQDN + port number. The endpoint does not have to be *named*, btw. It is quite enough to disallow TCP sessions to survice change of source or destination TLA (which is more than enough to cover the change of service providers) or to keep track of address changes the same way the post service does (i.e. forward and ask the addressee to notify the sender). >Consider process migration. Any commercial OS out there which does process migration? Most OS people became quite convinced that process migration does not pay for itself. Process migration is a lame excuse for building a whole new level of indirection and doing a hell lot of changes everywhere. And, magic cookie EID is *not necessary* for process migration (you may want to read rationale for TRAP). It can (and should) be done w/o it. No matter how you jump, the migration requires dynamical rebinding of EID->TLA, and the complexity of the task does not depend on the nature of EID. So why bother with extra level of indirection? It does not simplify anything, and like any extra layer anywhere only makes for a lot of headache (why do i think of ATM?). And then, there's a document describing how to do process migration w/o magic cookie EIDs, and so far nobody found a fundamental fault (or inherent inefficiency) in it. As i discussed that with Noel the aforementioned "architect's sense" came up :) The statement that migration is impossible w/o magic cookie EIDs amounts to the denial of the existance of the postal service. It does the two-level addressing (the EID is the identity of the addressee, the TLA is the postal address). When you move your magazines keep coming to you, right? Even if the "host" (i.e. home) didn't move with you. --vadim PS Computer science is the formalized branch of general bureaucratology. From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 16:07:27 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05648; Thu, 16 Nov 1995 16:07:27 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA06171; Thu, 16 Nov 1995 16:05:51 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA06154; Thu, 16 Nov 1995 15:53:43 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05002; Thu, 16 Nov 1995 15:53:31 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12787; Wed, 15 Nov 95 23:53:22 -0500 Date: Wed, 15 Nov 95 23:53:22 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511160453.AA12787@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, little@faline.bellcore.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Mike Little This idea has been around *long* enough. When do we separate the name spaces? How about along with the IPng transition? Take this issue up on the IPng mailing lists; none of these lists are the appropriate place. Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 16:09:36 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02726; Thu, 16 Nov 1995 16:09:36 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA06191; Thu, 16 Nov 1995 16:08:08 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA06151; Thu, 16 Nov 1995 15:48:39 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05527; Thu, 16 Nov 1995 15:48:35 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12711; Wed, 15 Nov 95 23:48:24 -0500 Date: Wed, 15 Nov 95 23:48:24 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511160448.AA12711@ginger.lcs.mit.edu> To: alan@gi.net, nanog@merit.edu Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Alan Hannan What are the correlations and contrasts between our current backbone routing problems (wrt space and # of routes) and the FCC decision several years ago to make 1-800 numbers portable. Well, the 800 number problem was a little easier, since phone numbers are variable length, and the 800 number database maps the numbers into another phone number, which may be a 13-digit carrier-id+phone-number combo... They say get stuffed, and get a congress person to propose a bill that all IP numbers are portable. This bill passes. It could happen. Any thoughts? Exactly which court do they go to to get this enforced on non-US parts of the Internet? Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 17:07:35 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11926; Thu, 16 Nov 1995 17:07:35 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA06268; Thu, 16 Nov 1995 17:05:52 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA06262; Thu, 16 Nov 1995 17:00:46 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23246; Thu, 16 Nov 1995 17:00:39 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13063; Thu, 16 Nov 95 01:00:17 -0500 Date: Thu, 16 Nov 95 01:00:17 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511160600.AA13063@ginger.lcs.mit.edu> To: avg@sprint.net, tli@cisco.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Vadim Antonov It is quite enough to disallow TCP sessions to survice change of source or destination TLA (which is more than enough to cover the change of service providers) Which means we can't use them to support mobility, which was one of the chief reasons for doing it. No matter how you jump, the migration requires dynamical rebinding of EID->TLA That's not the best way to go. If you have to get a new Transport level name, then all the applications have to know about that; i.e. mobility support needs to be built into every application. The endpoint name ought to be the only name used at the transport level. And then, there's a document describing how to do process migration w/o magic cookie EIDs, and so far nobody found a fundamental fault (or inherent inefficiency) in it. Which one are you talking about. Dave Crocker's? The statement that migration is impossible w/o magic cookie EIDs amounts to the denial of the existance of the postal service. Nobody said it can't be done; you clearly can. However, you can run any possible program on a Turing machine, but I don't see anyone selling chips with a Turing machine instruction set. Just because you can do something another way doesn't mean you should. It does the two-level addressing (the EID is the identity of the addressee, the TLA is the postal address). The right place to hide the "endpoint name -> whatever" binding is below the transport layer, otherwise all the applications have to know about it. Computer science is the formalized branch of general bureaucratology. If I hadn't met you in person, so I know you really exist, i'd wonder if you weren't Jim Bound posting under a pseudonym. Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 17:08:55 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12052; Thu, 16 Nov 1995 17:08:55 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA06290; Thu, 16 Nov 1995 17:07:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA06259; Thu, 16 Nov 1995 16:58:37 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12579; Thu, 16 Nov 1995 16:58:36 +1100 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26735 Thu, 16 Nov 1995 16:57:08 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13038; Thu, 16 Nov 95 00:51:33 -0500 Date: Thu, 16 Nov 95 00:51:33 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9511160551.AA13038@ginger.lcs.mit.edu> To: avg@sprint.net, jnc@ginger.lcs.mit.edu, little@faline.bellcore.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Vadim Antonov Silly. We already *do have two namespaces*. One is EIDs in form of FQDNs. "EID" is a kind of name for an endpoint which is shortish, fixed-length, and binary. So FQDN's are by definition not EID's, although they are endpoint names. How about fixing the real problem -- i.e. making renumbering easy and removing all hardwired addresses from the software? Sounds good to me. The magic-cookie EID scheme is nothing more than more complexity to work around the broken implementations. I'l cheerfully admit that the whole idea of EID's was driven in part by the fact that we don't have a blank slate to work with. I'm not averse to making FQDN's the endpoint names in our architecture, but it means we have to touch more stuff (e.g. TCP). Whether or not FWDN's are the optimal endpoint name if you have a blank sheet of paper: hmm, hmm, still don't have an answer to that one. That extra level of indirection is patently useless otherwise. An extra level of indirection is always a handy thing to have around, viz: "All problems in computer science can be solved by another level of indirection." - Butler Lampson Mind, I don't have any particular use in mind right at the moment, but I'm sure one will appear sooner or later! :-) Even funnier, implementation of magic cookie EIDs requires changes in exactly the same pieces of software which need to be changed to repair existing two-level scheme. Nope. You can implement EID's without changing any host binary; kind of hard to make FQDN's the endpoint name without changes to hosts. The best rationale i've heard was from Noel who said that his "architect's sense" tells him so. Funny thing, a surgeon i know was at loss when i asked him about this function of organism, should be a new discovery in medicine. Well, I guess you have no common sense, since the gland that produces this will be a new discovery in medicine too. Now that we're (hopefully) done insulting each other, can we get back to technical discussions? Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 18:26:11 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25785; Thu, 16 Nov 1995 18:26:11 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA06387; Thu, 16 Nov 1995 18:25:52 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA06370; Thu, 16 Nov 1995 18:18:06 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28667; Thu, 16 Nov 1995 18:18:00 +1100 (from avg@sprint.net) Received: from titan.sprintlink.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00778 Thu, 16 Nov 1995 17:46:43 +1100 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id BAA11030; Thu, 16 Nov 1995 01:46:18 -0500 Date: Thu, 16 Nov 1995 01:46:18 -0500 From: Vadim Antonov Message-Id: <199511160646.BAA11030@titan.sprintlink.net> To: avg@sprint.net, jnc@ginger.lcs.mit.edu, little@faline.bellcore.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU Precedence: bulk Noel Chiappa wrote: >"EID" is a kind of name for an endpoint which is shortish, fixed-length, and >binary. So FQDN's are by definition not EID's, although they are endpoint >names. Well, the definition may wary depending on whom you talk to. >I'l cheerfully admit that the whole idea of EID's was driven in part by the >fact that we don't have a blank slate to work with. I'm not averse to making >FQDN's the endpoint names in our architecture, but it means we have to touch >more stuff (e.g. TCP). TCP deserves a major cleanup. It has to, if we're about to run it at Gbps. Again, you may want to take a look at my rendition of TCP, which has no options, no "special cases" in protocol engine, and has all fields alinged on 64-bit boundary, provides for cryptographical protection against spoofing attacks, has selective ACKs, and all that in 64 bytes of header (including IP header). My opinion is that IPng is the (last?) chance to upgrade *all* internet host software, and spending that chance on half-arsed "incremental improvements" is stupid at best. The *cost* of upgrade does not depend on the magnitude of changes (as long as API is preserved). Instead of inventing clever kludges we'd better approach the task of building the *simple* and *robust* set of protocols, using all experience we got in IPv4-land. You'd understand me a lot better if you tried to run a real network, where most problems have genesis in the aforementioned kludges. When i hear the word "workaround" i reach for my pistol. Meanwhile, there is enough room in the existing system for things to be fixed w/o loss of compatibility. >Whether or not FWDN's are the optimal endpoint name >if you have a blank sheet of paper: hmm, hmm, still don't have an answer to >that one. There's a law of preservation of complexity, kind of. You may move it from one place to another but the underlying task is still there and have to be done at some level. The dynamic mapping of EIDs to TLAs has to be done somewhere, and doing it with FQDNs is no more complicated than doing it with EIDs. >An extra level of indirection is always a handy thing to have around, viz: > > "All problems in computer science can be solved by another level of > indirection." - Butler Lampson That is a cute saying but also is the root of very many problems in the real world. "Overengineering" is the name for the software crisis we're living through now. Networking is like aviation -- add some extra weight and it won't fly. >Mind, I don't have any particular use in mind right at the moment, but I'm >sure one will appear sooner or later! :-) Then it would be the high time to discuss it. Before that it has to be considered useless. If we would do differently i'm going to suggest that we need to send each byte three times. Just in case. > Even funnier, implementation of magic cookie EIDs requires changes in > exactly the same pieces of software which need to be changed to repair > existing two-level scheme. >Nope. You can implement EID's without changing any host binary; kind of hard >to make FQDN's the endpoint name without changes to hosts. :) Is the proposed EID 4 byte-long? What binary are we talking about -- application binaries or system software? There is an easy way to preservce application binaries with *any* change in transport protocols, by using IPv4 addresses as "handles". If we're talking about protocol translators, there's no difference between new transport and new addressing, complexity-wise. For a T-1 you can do both on a PC. For T-3 you cannot do it on any box available now. --vadim From owner-Big-Internet@munnari.OZ.AU Thu Nov 16 20:26:12 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01519; Thu, 16 Nov 1995 20:26:12 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA06506; Thu, 16 Nov 1995 20:25:53 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA06489; Thu, 16 Nov 1995 20:23:21 +1100 Received: from sophia.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA30452; Thu, 16 Nov 1995 20:23:04 +1100 (from huitema@pax.inria.fr) Received: from [138.96.8.81] by sophia.inria.fr (8.6.12/8.6.12) with SMTP id KAA16009 for ; Thu, 16 Nov 1995 10:22:48 +0100 Date: Thu, 16 Nov 1995 10:22:48 +0100 X-Authentication-Warning: sophia.inria.fr: Host sophmaccdc1.inria.fr claimed to be [138.96.8.81] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: big-internet@munnari.OZ.AU From: huitema@pax.inria.fr (Christian Huitema) Subject: Re: Routing wars pending? Precedence: bulk At 1:46 AM 16/11/95, Vadim Antonov wrote: >Noel Chiappa wrote: > >>"EID" is a kind of name for an endpoint which is shortish, fixed-length, and >>binary. So FQDN's are by definition not EID's, although they are endpoint >>names. Cool. So FQDNs don't work because they are not short, binary and fixed length. But then, Noel's preferred addresses', or rather locators', format is supposedly not short and not fixed. So what really makes the difference ? Ascii rather than binary ? That cannot be serious... >Well, the definition may wary depending on whom you talk to. > >>I'l cheerfully admit that the whole idea of EID's was driven in part by the >>fact that we don't have a blank slate to work with. I'm not averse to making >>FQDN's the endpoint names in our architecture, but it means we have to touch >>more stuff (e.g. TCP). > >TCP deserves a major cleanup. Vadim is probably right there. A lot of the EID's case derive's from TCP using IP addresses to identify transport connections. There is no reason not to fix this, and the fix does not have to involve a new namespace. If I understand correctly, I am framed to lead a BOF on this very subject in the Tuesday morning of Dallas IETF. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 00:46:04 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26677; Fri, 17 Nov 1995 00:46:04 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA06849; Fri, 17 Nov 1995 00:45:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA06834; Fri, 17 Nov 1995 00:36:45 +1100 Received: from ncc.ripe.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06137; Fri, 17 Nov 1995 00:36:32 +1100 (from dfk@ripe.net) Received: from reif.ripe.net by ncc.ripe.net with SMTP id AA13585 (5.65a/NCC-2.30); Thu, 16 Nov 1995 14:26:23 +0100 Message-Id: <9511161326.AA13585@ncc.ripe.net> To: Alan Hannan Cc: nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, little@faline.bellcore.com (Mike Little) Subject: Routing wars pending? In-Reply-To: Your message of Wed, 15 Nov 1995 17:12:06 CST. <199511152312.RAA00426@gaijin.mid.net> References: <199511152312.RAA00426@gaijin.mid.net> From: Daniel Karrenberg X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Date: Thu, 16 Nov 1995 14:26:17 +0100 Sender: Daniel.Karrenberg@ripe.net Precedence: bulk > Alan Hannan writes: > > What are the correlations and contrasts between our current > backbone routing problems (wrt space and # of routes) and the FCC > decision several years ago to make 1-800 numbers portable. Correlations are manifold. The most striking contrasts: - Implementation on the 1-800 numbers was straightforward - number space quite small - routing fairly centralised - on the level of the 1-800 address space there is quite static routing, I understand that database updates at that time were done by shipping magtapes - The problem was local to one country and jurisdiction due to the addressing hierarchy > I ask because I see the a potential scenario when we are forced to > play hardball wrt non portability of new CIDR routes. Imagine > this... Big corporation leaves us having been allocated /21 of > address space. We tell them to get new IP numbers from their provider > and backbone smart people make it known they won't propogate > routes (you wouldn't, right Sean?). They say get stuffed, and get > a congress person to propose a bill that all IP numbers are > portable. This bill passes. They also passed a bill once to make PI 3 or some such, didn't they? Daniel From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 04:28:46 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15361; Fri, 17 Nov 1995 04:28:46 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA07086; Fri, 17 Nov 1995 04:26:01 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA07053; Fri, 17 Nov 1995 04:09:44 +1100 Received: from pilot.is.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11994; Fri, 17 Nov 1995 04:09:42 +1100 (from rgm3@is.chrysler.com) Received: by pilot.firewall.is.chrysler.com; id MAA24682; Thu, 16 Nov 1995 12:22:48 -0500 Received: from clhubgw1.is.chrysler.com(172.29.128.203) by pilot.is.chrysler.com via smap (g3.0.1) id sma024666; Thu, 16 Nov 95 12:22:18 -0500 Received: from rgm3 (rgm3.is.chrysler.com) by clhubgw1.is.chrysler.com (5.x/SMI-4.1) id AA17675; Thu, 16 Nov 1995 12:09:20 -0500 Message-Id: <9511161709.AA17675@clhubgw1.is.chrysler.com> X-Sender: t3125rm@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Nov 1995 12:09:09 -0500 To: Vadim Antonov , avg@sprint.net, tli@cisco.com From: Robert Moskowitz Subject: Re: Routing wars pending? Cc: HANK@taunivm.tau.ac.il, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, little@faline.bellcore.com, nanog@dune.silkroad.com, nanog@merit.edu Precedence: bulk At 08:22 PM 11/15/95 -0500, Vadim Antonov wrote: > >>Consider process migration. > >Any commercial OS out there which does process migration? Most >OS people became quite convinced that process migration does not >pay for itself. Vadim, In many areas you and Noel know a lot more than me. You are the eagles, I am only a hawk. But over in corporate networks, we have had much of this for years. In VTAM. Yes sessions do not survive rollovers, but reconnects go immediately to the new system. We have WORKED VERY HARD trying to manage this in DNS. Notify has helped and Dynamic will help more. But that is for host, not process. So we have to have multiple A records for different names and that breaks in-addr.arpa! GRRRRR...... Talk to my at Dallas and I will give you living examples of BBBIIIGGG mobile processes VERY mission critical..... Enough. I got to head over to the AIAG office. Talk to me about that also at Dallas. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 05:26:41 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23463; Fri, 17 Nov 1995 05:26:41 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07170; Fri, 17 Nov 1995 05:25:58 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07163; Fri, 17 Nov 1995 05:25:33 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24778; Fri, 17 Nov 1995 05:25:29 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id NAA18073; Thu, 16 Nov 1995 13:22:23 -0500 From: Tim Bass Message-Id: <199511161822.NAA18073@dune.silkroad.com> Subject: Re: Routing wars pending? To: rgm3@is.chrysler.com (Robert Moskowitz) Date: Thu, 16 Nov 1995 13:22:23 -0500 (EST) Cc: big-internet@munnari.OZ.AU, nanog@merit.edu In-Reply-To: <9511161709.AA17675@clhubgw1.is.chrysler.com> from "Robert Moskowitz" at Nov 16, 95 12:09:09 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1728 Precedence: bulk Absolutely agree with both Robert and Vadim that DNS need to be revised in a big way. I especially would like to see the MX record concept applied to information services (IX maybe), i.e. foo.bar.org. IN A 198.133.151.19 IX 10 fooU2.bar.org. IX 20 foo2U2.bar.org. IX 30 whoU2.maybe.com. IX 40 tryMe2.friendly.com. www.bar.org. IN CNAME foo.bar.org. Has this simple concept been proposed in an IETF draft unknown to us ugly ducklings :-) Quack. Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 07:06:21 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01414; Fri, 17 Nov 1995 07:06:21 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA07296; Fri, 17 Nov 1995 07:05:57 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA07279; Fri, 17 Nov 1995 06:52:11 +1100 Received: from faline.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27723; Fri, 17 Nov 1995 06:52:08 +1100 (from little@faline.bellcore.com) Received: from faline (localhost [127.0.0.1]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id OAA09162; Thu, 16 Nov 1995 14:51:50 -0500 Message-Id: <199511161951.OAA09162@faline.bellcore.com> To: Daniel Karrenberg , Alan Hannan Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org Subject: Re: Routing wars pending? In-Reply-To: Your message of "Thu, 16 Nov 1995 14:26:17 +0100." <9511161326.AA13585@ncc.ripe.net> Date: Thu, 16 Nov 1995 14:51:47 -0500 From: Mike Little Precedence: bulk (Notes: I've trimed the Cc list assuming all previous originators are on one of the lists anyway, *and* as this topic may be getting little off topic for these mailing lists, I'll try to maintain relevance) > Alan Hannan writes: > > What are the correlations and contrasts between our current > backbone routing problems (wrt space and # of routes) and the FCC > decision several years ago to make 1-800 numbers portable. > Daniel Karrenberg writes: > >Correlations are manifold. > >The most striking contrasts: > <....snip...> Competing economic interests (subscribers and network providers) motivated the FCC decision. Since the changes needed weren't impossible (just hard) the only impact technology considerations really had was on setting the deadline by which it had to be done. The Internet community currently enjoys setting (and missing) its own timetables. On the surface there appears some correlation to the number portability issue. Subscribers wanted to keep their "address" even though they may have changed network providers. When the routing system is routing based on provider, and not subscriber, the "portability problem" can exist. In the 1-800 pre-portability days, 800 numbers were translated on the basis of the network provider who "owned" the number. Be aware that the end point identity in the 1-800 scenario is the 1-800 number. The 800 number itself is translated to another number which is utilized by the network provider(s) for routing purposes. In the Internet environment the end point identity is somewhat muddled, but from a *general* perspective can be considered the domain name. Based on this, there isn't a correlation with the 1-800 portability problem because you can keep your domain name even though you changed network provider (e.g. there is no corresponding problem). However, if (or when) you consider the IP address to be the end point identifier, then the portability problem does exist. Now the focus should be placed on the scope of the portability problem. This is important because in some sense there is always a "portability" issue but not necessarily a "problem". When routing is based on some domain, such as network or provider or mask, then there is a "portability" issue for end points that relocate outside of that domain. Thus, if an end point becomes aligned with another routing domain for one reason or another (i.e. 1-800 example where the user subscribes to another provider, or the IP routing environment wants to re-organize routing domains) there is an impact. This is, of course, only a problem if you don't like the impact. I'll just quickly point out that this impact involves issues such as who absorbs the dynamics of the re-assignment, how they are absorb, and the persistence of the identity (persistence is important for usability). I like the EID approach, but I'll leave that discussion for another message. In regards to Alan's inquiry concerning space and number of routes: As far as I'm aware the 1-800 portability decision (or surrounding issues) did not involve considerations for space, either in terms of address space exhaustion - which is a current issue - or size of translation tables, or for numbers of routes (e.g. no route "explosion"). The 1-800 portability problem was in essence a difficulty in maintaining identity. -Mike From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 07:26:07 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05180; Fri, 17 Nov 1995 07:26:07 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA07344; Fri, 17 Nov 1995 07:25:57 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA07327; Fri, 17 Nov 1995 07:14:28 +1100 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19896; Fri, 17 Nov 1995 07:14:22 +1100 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id NAA17464; Thu, 16 Nov 1995 13:26:53 -0800 Date: Thu, 16 Nov 1995 13:26:52 -0800 (PST) From: Michael Dillon X-Sender: michael@okjunc.junction.net To: Daniel Karrenberg Cc: Alan Hannan , nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, Mike Little Subject: Re: Routing wars pending? In-Reply-To: <9511161326.AA13585@ncc.ripe.net> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 16 Nov 1995, Daniel Karrenberg wrote: > They also passed a bill once to make PI 3 or some such, didn't they? In the state where this happened it was passed by their congress but was vetoed in their senate so it never became law. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 22:46:21 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03612; Fri, 17 Nov 1995 22:46:21 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA08144; Fri, 17 Nov 1995 22:46:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA08127; Fri, 17 Nov 1995 22:36:48 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02246; Fri, 17 Nov 1995 22:36:26 +1100 (from STEPHEN.GEIS@ITU.CH) Received: from sigma.itu.ch by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01310 Fri, 17 Nov 1995 21:41:10 +1100 (from STEPHEN.GEIS@ITU.CH) Received: from MR.ITU.CH by ITU.CH (PMDF V4.3-7 #4298) id <01HXQXN4MS9C8ZEEDH@ITU.CH>; Fri, 17 Nov 1995 11:25:50 CET Received: with PMDF-MR; Thu, 16 Nov 1995 15:56:02 CET Mr-Received: by mta TIES.MUAS; Relayed; Thu, 16 Nov 1995 15:56:02 +0100 Mr-Received: by mta SIGMA; Relayed; Thu, 16 Nov 1995 15:56:05 +0100 Disclose-Recipients: prohibited Date: Thu, 16 Nov 1995 15:56:02 +0100 (CET) From: Stephen Geis Subject: Re: 800 numbers vs. IP addresses (was Routing wars pending?) To: Alan Hannan , nanog Cc: jnc , HANK , nanog , big-internet , cidrd , little Message-Id: <1402561616111995/A09137/SIGMA/119B84372600*@MHS> X-Envelope-To: big-internet@munnari.oz.au Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: normal Ua-Content-Id: 119B84372600 X400-Mts-Identifier: [;1402561616111995/A09137/SIGMA] Hop-Count: 1 Precedence: bulk Alan Hannan asked: > What are the correlations and contrasts between our current > backbone routing problems (wrt space and # of routes) and the FCC > decision several years ago to make 1-800 numbers portable. > There is a major difference between ownership of IP network numbers and telephone number portability: the economic benefits of ownership of addresses are not comparable to those of ownership of telephone numbers. As far as I know, the economic benefits of network number ownership are confined to cost avoidance related to re-numbering. A major argument for ownership of telephone numbers (and especially freephone - e.g., 800 - numbers) is that the subscriber makes an investment (by advertising, letterhead, etc) getting knowledge of a subscriber's phone number to customers, friends, and other correspondents. Since the knowledge (as used by humans) of how to reach a "subscriber" on the Internet is encoded in a DNS name and not in an address, no comparable argument can be made for ownership of addresses. Stephen Geis ITU geis@itu.ch From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 23:09:46 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07492; Fri, 17 Nov 1995 23:09:46 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA08228; Fri, 17 Nov 1995 23:09:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA08184; Fri, 17 Nov 1995 22:58:57 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03853; Fri, 17 Nov 1995 22:58:52 +1100 (from dkap@sanctuary.haven.org) Received: from sanctuary.haven.org by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04020 Fri, 17 Nov 1995 10:00:06 +1100 (from dkap@sanctuary.haven.org) Received: (from dkap@localhost) by sanctuary.haven.org (8.6.11/8.6.9) id RAA21739; Thu, 16 Nov 1995 17:51:13 -0500 Date: Thu, 16 Nov 1995 17:51:13 -0500 Message-Id: <199511162251.RAA21739@sanctuary.haven.org> To: michael@memra.com Cc: Daniel.Karrenberg@ripe.net, alan@gi.net, nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, little@faline.bellcore.com In-Reply-To: (message from Michael Dillon on Thu, 16 Nov 1995 13:26:52 -0800 (PST)) Subject: Re: Routing wars pending? Reply-To: dkap@haven.org From: "A Page in the Life of ..." Precedence: bulk From: Michael Dillon On Thu, 16 Nov 1995, Daniel Karrenberg wrote: > They also passed a bill once to make PI 3 or some such, didn't they? In the state where this happened it was passed by their congress but was vetoed in their senate so it never became law. Florida. I'm not sure that it was vetoed, though, I'll have to check back. (The premis of the argument put forth was a quote in the bible about a certain oasis being 30 cubits around and 10 cubits across, so PId=c solve for PI.) Dave K. (rampant trivia maven) From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 23:11:53 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26194; Fri, 17 Nov 1995 23:11:53 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA08259; Fri, 17 Nov 1995 23:11:46 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA08193; Fri, 17 Nov 1995 23:00:40 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28790; Fri, 17 Nov 1995 23:00:39 +1100 (from dogcow@piglet.merit.net) Received: from piglet.merit.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02315 Fri, 17 Nov 1995 09:06:18 +1100 (from dogcow@piglet.merit.net) Received: by piglet.merit.net (Smail3.1.29.1 #1) id m0tGCQ7-00001iC; Thu, 16 Nov 95 17:04 EST Message-Id: From: dogcow@piglet.merit.net (Tom 'moof' Spindler) Subject: Re: Routing wars pending? To: GAVRON@ACES.COM (Ehud Gavron) Date: Thu, 16 Nov 1995 17:04:33 -0500 (EST) Cc: michael@memra.com, Daniel.Karrenberg@ripe.net, alan@gi.net, nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, little@faline.bellcore.com, GAVRON@ACES.COM In-Reply-To: <01HXPPLND9PE00002U@ACES.COM> from "Ehud Gavron" at Nov 16, 95 02:14:41 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 683 Precedence: bulk Actually, the (original) explanation is correct. The state was Indiana. Read about it in Petr Beckmann's "History of Pi" if you're interested about it. I believe it has the full story. > It was a small community in Alabama that voted (for their town) to > allow PI to equal 3 for the purpose of calculating square footage > for property tax. > > That's it. No grand scheme to defraud Southern schoolkids, no legislation > of ip_v !=4, just something to make taxes simple. > > >> They also passed a bill once to make PI 3 or some such, didn't they? > > >In the state where this happened it was passed by their congress but was > >vetoed in their senate so it never became law. From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 23:14:06 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08528; Fri, 17 Nov 1995 23:14:06 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA08283; Fri, 17 Nov 1995 23:13:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA08158; Fri, 17 Nov 1995 22:48:59 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08404; Fri, 17 Nov 1995 22:48:58 +1100 (from nanog@dune.silkroad.com) Received: from dune.silkroad.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA16713 Fri, 17 Nov 1995 14:41:49 +1100 (from nanog@dune.silkroad.com) Received: (from nanog@localhost) by dune.silkroad.com (8.6.12/8.6.9) id XAA01665; Thu, 16 Nov 1995 23:39:21 -0500 From: Tim Bass (@NANOG-LIST) Message-Id: <199511170439.XAA01665@dune.silkroad.com> Subject: Re: Routing wars pending? To: big-internet@munnari.OZ.AU Date: Thu, 16 Nov 1995 23:39:20 -0500 (EST) Cc: nanog@merit.edu In-Reply-To: <9511162330.AA06428@wisdom.home.vix.com> from "Paul A Vixie" at Nov 16, 95 03:29:55 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 695 Precedence: bulk Paul quips: > > Tim, next time I'd like you to do three things differently: > > Only three? There are about double that amount I would like to see you do differently, Paul. I just don't have the time to always count the number of signatures nor worry when others hit the group reply key in elm like you seem to. How about I just leave the .sig off this one so you can enjoy subtraction as well as addition :-) Also, we'll all be counting on your adept observation skills to police all the lists people post to in a thread. Why, being so adept, it does surprise me a little you have missed the other 10,000 or so similar mistakes by others recently. < the rest deleted > Tim From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 23:17:09 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09633; Fri, 17 Nov 1995 23:17:09 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA08305; Fri, 17 Nov 1995 23:17:01 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA08199; Fri, 17 Nov 1995 23:03:00 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09487; Fri, 17 Nov 1995 23:02:59 +1100 (from GAVRON@ACES.COM) Received: from Hearts.ACES.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00808 Fri, 17 Nov 1995 08:16:36 +1100 (from GAVRON@ACES.COM) Received: from ACES.COM by ACES.COM (PMDF V4.3-10 #4107) id <01HXO6W6L0CG00002U@ACES.COM>; Thu, 16 Nov 1995 14:15:49 -0700 (MST) Date: Thu, 16 Nov 1995 14:14:41 -0700 (MST) From: Ehud Gavron Subject: Re: Routing wars pending? In-Reply-To: Your message dated "Thu, 16 Nov 1995 13:26:52 -0800 (PST)" To: Michael Dillon Cc: Daniel Karrenberg , Alan Hannan , nanog@merit.edu, jnc@ginger.lcs.mit.edu, HANK@taunivm.tau.ac.il, nanog@dune.silkroad.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, Mike Little , GAVRON@ACES.COM Message-Id: <01HXPPLND9PE00002U@ACES.COM> Organization: ACES Research Inc. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT Precedence: bulk I don't know what this has to do with big-I or cidr but let's just clear the urban legend. It was a small community in Alabama that voted (for their town) to allow PI to equal 3 for the purpose of calculating square footage for property tax. That's it. No grand scheme to defraud Southern schoolkids, no legislation of ip_v !=4, just something to make taxes simple. Ehud >On Thu, 16 Nov 1995, Daniel Karrenberg wrote: >> They also passed a bill once to make PI 3 or some such, didn't they? >In the state where this happened it was passed by their congress but was >vetoed in their senate so it never became law. >Michael Dillon Voice: +1-604-546-8022 >Memra Software Inc. Fax: +1-604-542-4130 >http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Fri Nov 17 23:19:35 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05182; Fri, 17 Nov 1995 23:19:35 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA08325; Fri, 17 Nov 1995 23:19:23 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA08190; Fri, 17 Nov 1995 22:59:17 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04699; Fri, 17 Nov 1995 22:59:16 +1100 (from vixie@wisdom.home.vix.com) Received: from gw.home.vix.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05222 Fri, 17 Nov 1995 10:30:18 +1100 (from vixie@wisdom.home.vix.com) Received: by gw.home.vix.com id AA11374; Thu, 16 Nov 95 15:30:01 -0800 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA06428; Thu, 16 Nov 1995 15:30:00 -0800 Message-Id: <9511162330.AA06428@wisdom.home.vix.com> To: big-internet@munnari.OZ.AU, nanog@merit.edu Reply-To: big-internet@munnari.OZ.AU Subject: Re: Routing wars pending? In-Reply-To: Your message of "Thu, 16 Nov 1995 13:22:23 EST." <199511161822.NAA18073@dune.silkroad.com> Date: Thu, 16 Nov 1995 15:29:55 -0800 From: Paul A Vixie Precedence: bulk > Absolutely agree with both Robert and Vadim that DNS need to be revised > in a big way. I especially would like to see the MX record concept > applied to information services (IX maybe), i.e. [...] That's not a big revision. "Big" revisions usually entail wire protocol changes. What you want is called a "SRV" record and it was submitted to the RFC Editor for "extended last call" (befitting its experimental status) about a week ago. An earlier version can be had from any Internet Drafts repository as draft-gulbrandsen-dns-rr-srvcs-01.txt. > Has this simple concept been proposed in an IETF draft unknown to > us ugly ducklings :-) > > Quack. > > Tim Tim, next time I'd like you to do three things differently: (1) do your homework before posting widely (2) post to big-internet or nanog but not both (3) only include one copy of your .signature Paul From owner-Big-Internet@munnari.OZ.AU Sat Nov 18 01:22:13 1995 Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07159; Sat, 18 Nov 1995 01:22:13 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00576 Fri, 17 Nov 1995 08:07:03 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA07418; Fri, 17 Nov 1995 08:06:56 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA07376; Fri, 17 Nov 1995 07:50:28 +1100 Received: from BART.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08051; Fri, 17 Nov 1995 07:50:25 +1100 (from MAP=Bounce@BBN.COM) Received: from GAAK.BBN.COM by BART.BBN.COM id aa03477; 16 Nov 95 15:46 EST Date: Thu, 16 Nov 1995 15:46:02 EST Message-Id: To: bass@dune.silkroad.com Cc: big-internet@munnari.OZ.AU, nanog@merit.edu In-Reply-To: <199511161822.NAA18073@dune.silkroad.com> (message from Tim Bass on Thu, 16 Nov 1995 13:22:23 -0500 (EST)) Subject: Re: Routing wars pending? From: "Michael A. Patton" Precedence: bulk From: Tim Bass Date: Thu, 16 Nov 1995 13:22:23 -0500 (EST) ... the MX record concept applied to information services [Example removed] Has this simple concept been proposed in an IETF draft unknown to us ugly ducklings :-) Yes. See draft-gulbrandsen-dns-rr-srvcs-01.txt at a repository near you. -MAP From owner-Big-Internet@munnari.OZ.AU Sat Nov 18 01:22:16 1995 Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12676; Sat, 18 Nov 1995 01:22:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00548 Fri, 17 Nov 1995 08:06:06 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA07396; Fri, 17 Nov 1995 08:05:57 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA07379; Fri, 17 Nov 1995 07:54:33 +1100 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05583; Fri, 17 Nov 1995 07:54:04 +1100 (from mo@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29797 Fri, 17 Nov 1995 07:38:47 +1100 (from mo@uunet.uu.net) Received: from localhost by rodan.UU.NET with SMTP id QQzqdm06987; Thu, 16 Nov 1995 15:38:24 -0500 Message-Id: To: Mike Little Cc: Daniel Karrenberg , Alan Hannan , big-internet@munnari.OZ.AU, cidrd@iepg.org Subject: Re: Routing wars pending? In-Reply-To: Your message of "Thu, 16 Nov 1995 14:51:47 EST." <199511161951.OAA09162@faline.bellcore.com> Date: Thu, 16 Nov 1995 15:38:24 -0500 From: "Mike O'Dell" Precedence: bulk 800 portability is NOT a good analogy for IP portability. portability of every phone number between all countries is a much better analogy. it is also much harder. -mo From owner-Big-Internet@munnari.OZ.AU Sat Nov 18 02:46:28 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19598; Sat, 18 Nov 1995 02:46:28 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA08615; Sat, 18 Nov 1995 02:46:13 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08609; Sat, 18 Nov 1995 02:40:41 +1100 Received: from faline.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15973; Sat, 18 Nov 1995 02:40:39 +1100 (from little@faline.bellcore.com) Received: from faline (localhost [127.0.0.1]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id KAA04630; Fri, 17 Nov 1995 10:40:31 -0500 Message-Id: <199511171540.KAA04630@faline.bellcore.com> To: "Mike O'Dell" Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org Subject: Re: Routing wars pending? In-Reply-To: Your message of "Thu, 16 Nov 1995 15:38:24 EST." Date: Fri, 17 Nov 1995 10:40:19 -0500 From: Mike Little Precedence: bulk Mike, I'm not sure what you're point here is. Are you saying you don't see any parallels between 800 number portability and IP number portability concepts? Alan asked for some contrast, I (hopefully) made some Big-I relevant points (not so sure about cidr relevance) concerning impacts of naming/addressing with 800 numbers as a backdrop. The only thing being new to the long term topic dicsussion perhaps is the importance of identity persistence within a "domain". I hope nobobdy seriously considers adopting the 800 translation model (or any existing model for that matter without due consideration) as a solution in the IP environment. You make a good point that the current 800 implementation is not a valid one for IP. And a quip to consider which may be harder - is it harder to solve the IP portability problem *or* to get a solution to market in one year that (currently) performs flawlessly after deployment? -Mike > Mike O'Dell writes: > >800 portability is NOT a good analogy for IP portability. > >portability of every phone number between all countries is >a much better analogy. > >it is also much harder. > > -mo From owner-Big-Internet@munnari.OZ.AU Mon Nov 20 17:29:23 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26810; Mon, 20 Nov 1995 17:29:23 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA11863; Mon, 20 Nov 1995 17:27:14 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA11846; Mon, 20 Nov 1995 17:16:20 +1100 Received: from melon.jaist.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11325; Mon, 20 Nov 1995 17:15:10 +1100 (from tatsuo@jaist.ac.jp) Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Mon, 20 Nov 1995 14:07:53 +0900 Message-Id: <199511200507.OAA15032@melon.jaist.ac.jp> To: nossdav96-announce@jaist.ac.jp Subject: Call for Paper: NOSSDAV'96 Date: Mon, 20 Nov 1995 14:07:50 JST From: Tatsuo Nakajima Precedence: bulk The following is a Call for Papers for NOSSDAV'96(International Workshop on Network and Operating Systems Support for Digital Audio and Video). Please distribute it as widely as possible to your colleagues and encourage them to submit papers by the deadline (Jan 5, 1996). More detailed information can be available from http://www.sfc.wide.ad.jp/nossdav96/ Tatsuo Nakajima, Publicity Chair NOSSDAV'96. Japan Advanced Institute of Science and Technology --------------------------------------------------- Call-for-Papers The 6th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 96) URL: http://www.sfc.wide.ad.jp/nossdav96/ April 23 - 26, 1996 Shonan Village International Conference Center, Zushi, Japan Objectives The 6th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 96) is the international workshop among active researchers and practitioners who are building innovative multimedia systems, networks and applications. While we will focus on the state of the art technology in networking and operating system support for multimedia systems, we will also seek for practitioners' papers from a variety of area, including media toolkit, mobile communications, VR, real-time systems, software agents, digital library, and distributed computing systems. It is also intended to provide extensive discussion periods during the workshop to discuss the important issues which may require future research. Relevant topics for the workshop include: High-speed/ATM networks Multimedia-oriented desk, local and wide area networks Workstation and PDA architectures for multimedia Multimedia network interfaces Cell-based system architectures Mobile systems for multimeida Communication protocols for multimedia Multicast protocols and media scaling Micro-kernel and OS support for real-time communications Resource management and reservation in the OS and network End-to-end admission control Quality of service and synchronization frameworks Multimedia storage, server, and I/O architectures Distributed multimedia systems APIs and CM programming abstractions for multimedia TV set-top device communication VOD system architecture Software agents for multimedia systems VR systems Submissions Two types of submissions are solicited: position papers and research papers. For the purpose of paper review, position papers are restricted to three single-spaced ASCII pages. Research papers are restricted to an extended abstract no longer than five formatted postscript pages. Papers should be electronically mailed to nossdav96@sfc.keio.ac.jp. Only if electronic submission is impossible, papers may be sent to the following e-mail address. Prof. Hideyuki Tokuda Keio University, 5322 Endoh, Fujisawa, Japan 252 Phone: +81-466-47-5000 (wait for 2 sec. then 3129) Fax: +81-466-47-0835 E-mail: hxt@sfc.keio.ac.jp The proceedings of the workshop will be published by Springer-Verlag and the best papers will be forwarded to selected journals for publication. Important Dates Submission Deadline 1/5/96 Acceptance Notification 2/12/96 Final Paper Due 3/18/96 Workshop: 4/23/96-4/26/96 Program Chair: Hideyuki Tokuda, Keio University/Carnegie Mellon University Program Committee: Domenico Ferrari, University of California, Berkeley Simon Gibbs, Univ. of Geneva, Switzerland Riccardo Gusella, HP Labs Ralf Herrtwich, IBM Creative Multimedia Studios Jung-kook Hong, IBM, Japan Andy Hopper, Olivetti & University of Cambridge Kevin Jeffay, University of North Carolina at Chapel Hill Jim Kurose, University of Massachusetts at Amherst Aurel Lazar, Columbia University T.D.C. Little, Boston University Derek McAuley, Cambridge University Duane Northcutt, Sun Microsystems Laboratories Guru Parulkar, Washington University Steve Pink, Swedish Institute of Computer Science Radu Popescu-Zeletin, GMD-FOKUS Ragunathan Rajkumar, Carnegie Mellon University P. Venkat Rangan, University of California, San Diego Jon Rosenberg, Bell Communications Research Doug Shepherd, Lancaster University Cormac Sreenan, AT&T Bell Laboratories Jean-Bernard Stefani, France Telecom/CNET Jay Strosnider, Carnegie Mellon University Daniel Swinehart, Xerox PARC Jon Walpole, Oregon Graduate Institute of Science & Technology Hiroshi Yasuda, NTT, Japan Publicity Chair Tatsuo Nakajima, JAIST, Japan Publishing Chair Shuich Oikawa, Keio University, Japan Local Arrangement Chair and Finance Chair Akira Nambu, NTT, Japan From owner-Big-Internet@munnari.OZ.AU Tue Nov 21 00:27:35 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07287; Tue, 21 Nov 1995 00:27:35 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA12266; Tue, 21 Nov 1995 00:27:21 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA12223; Tue, 21 Nov 1995 00:16:50 +1100 Received: from mailhost.pipex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13116; Tue, 21 Nov 1995 00:16:46 +1100 (from keith@pipex.com) Received: from pipe.pipex.net (actually mailhost.pipex.net) by pipe.pipex.net with SMTP (PP); Mon, 20 Nov 1995 13:16:22 +0000 Received: by pipe.pipex.net (8.6.12/PIPEX simple 1.22) id NAA11997; Mon, 20 Nov 1995 13:16:12 GMT Message-Id: <199511201316.NAA11997@pipe.pipex.net> From: keith@pipex.com (Keith Mitchell) Date: Mon, 20 Nov 1995 13:16:12 +0000 In-Reply-To: <199511171540.KAA04630@faline.bellcore.com> X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Mike Little , "Mike O'Dell" Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org Precedence: bulk In <199511171540.KAA04630@faline.bellcore.com>, wrote: > You make a good point that the current 800 implementation > is not a valid one for IP. > > Mike O'Dell writes: > > > >800 portability is NOT a good analogy for IP portability. > > > >portability of every phone number between all countries is > >a much better analogy. > > > >it is also much harder. A better telephony example perhaps is that of GSM roaming, where there is no mapping from a a "logical" 800 number to a physical geographic code identifying the end-point. Instead the phone is still addressed by it's home country and area code, even when it is in another country. I think the routing is currently done by host redirection. I suspect that currently roamed mobile phone use is sufficiently rare that there are not scaling problems with this approach at present, but with GSM growth comparable to Internet growth I think they may have a few headaches ahead... However, mobility is a seperate issue being addressed elsewhere in the IP world, I guess this is where the analogy breaks down. Keith Mitchell Head of Engineering PIPEX International keith@pipex.com 216 The Science Park Cambridge, UK Phone: +44 1223-250311 Fax: +44 1223-250373 A subsidiary of UUNET Technologies Inc. From owner-Big-Internet@munnari.OZ.AU Tue Nov 21 05:07:37 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10125; Tue, 21 Nov 1995 05:07:37 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12527; Tue, 21 Nov 1995 05:07:25 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12519; Tue, 21 Nov 1995 04:59:20 +1100 Received: from melon.jaist.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02104; Tue, 21 Nov 1995 04:59:12 +1100 (from erbi@eurecom.fr) Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Tue, 21 Nov 1995 02:44:52 +0900 Received: from eurecom.cica.fr by chenas.inria.fr (5.65c8d/92.02.29) via EUnet-France id AA27548; Mon, 20 Nov 1995 18:44:35 +0100 (MET) Received: from rosa.cica.fr by eurecom.cica.fr (4.1/SMI-4.0) id AA06910; Mon, 20 Nov 95 18:44:43 +0100 Message-Id: <9511201744.AA06910@eurecom.cica.fr> Organization: Eurecom, Sophia-Antipolis, France Date: Mon, 20 Nov 95 18:44:43 +0100 From: Biersack Ernst To: nossdav96-announce@jaist.ac.jp Subject: Call for Paper: Euromicro 1996 Cc: erbi@eurecom.fr Precedence: bulk 22nd Euromicro Conference Beyond 2000: Hardware and Software Design Strategies Prague September 2-5, 1996 Call for Papers Euromicro conferences have been established to bring together people from business, industry,research, government and academia who are interested in problems related to microelectronics and computing. The Euromicro 96 Conference will attract researchers in four major fields. Each field constitutes a separate track for specialists. Programme This year the conference contains a new track - Telecommunications and Multimedia. The introduction of this track reflects the growing interest and importance of the subject.The Conference will have two main activities: Keynote speeches by outstanding experts Scientific and open forum sessions, which will report on significant developments in the tracks of the conference. Social events will be organized, offering opportunities to meet other delegates from all over the world. Scope Authors are invited to submit original contributions as full papers or extended summaries on recent applications, developments and research associated with microelectronics, computer hardware and software. Where experimental results have not been obtained in full, this must be stated and, if accepted, up-to-date results must be included in the final version of the paper. Regular Papers Papers submitted to the Euromicro 96 Conference will be organized in the following four tracks. 1. Computer Architecture and Design Automation Track coordinator: Anna Antola, Italy Topics: Processor architectures Instruction sets Memory architectures Co-processors and arithmetic devices ASIC and custom ICs DSP and computer vision architectures Microsystems technologies and architectures Timing analysis and performance evaluation Fault tolerant systems HW description languages and formal methods HW/SW codesign High level synthesis Estimation and evaluation techniques Fault modelling and testing Design for testability 2. Software Engineering Track coordinator: Konrad Kloeckner, Germany Topics: Requirements capture and analysis Formal specification and design Database systems and techniques Knowledge based systems Information storage and retrieval Prototyping systems Automated software development Methodologies for large scale software development Software testing and debugging Software reuse Real-time systems Quality control Software metrics Validation and verification 3. High Performance Computing Track coordinator: Stephen Winter, UK Topics: Formal models of parallelism Distributed operating systems Massively parallel systems Multiprocessors Parallel and distributed architectures Performance engineering Load balancing strategies Parallel application modelling Parallel cooperation models Parallel discrete-event simulation Parallel Software engineering Fault tolerance Performance modelling and evaluation Tools and techniques for parallel systems development Parallel neural networks 4. Multimedia and Telecommunications Track coordinator: Isabelle Demeure, France Topics: Network and operating system support for multimedia applications Capture and management of audio and visual information Storage technologies and techniques for multimedia applications Protocols for high speed networks Formal specification of protocols Multimedia architectures Formal specification of multimedia applications Specification and management of QoS constraints Multimedia services Network and service management Paradigms and tools for multimedia applications Applications (teleworking, teleconferencing, groupware, interactive television, video-on-demand, world wide web) Short Contributions In addition to regular papers, Euromicro 96 will feature short contribution, dedicated to: Brief up-to-date reports on ongoing research projects.Innovative applications in the fields of microelectronics and computer technology, including information systems, signal processing, communications and control systems.Technical reports from industry on new products, featuring breakthroughs or relevant technology in the area.Technical progress and final reports.It is the intention that short contribution papers will be scheduled in each of the main conference sessions. Submission of regular papers Authors should submit six copies of a full paper or an extended summary to the Programme Chairperson before January 31st, 1996. They will be notified of acceptance by March 31st, 1996. Final version of papers in camera-ready forms must be received by May 15th, 1996.A submission should be accompanied by a covering front sheet containing the author name(s), affiliations(s), mailing and e-mail addresses, phone and fax numbers, Conference track and topic to which it is addressed, and up to six keywords. A brief statement emphasising those points which make the paper different from work published earlier, or elsewhere, will assist the referees in making their decisions. In order that anonymous reviewing can be carried out, the paper and its title page should not contain the name(s) of the author(s) or their affiliation(s). The six copies of the submitted paper should be accompanied by the following signed statement: Neither this paper nor any version close to it has been or is being offered elsewhere for publication. If accepted, the paper will be made available in camera-ready forms by May 15th, 1996, and it will be personally presented at the Euromicro 96 Conference by the author or one of the co-authors. The Conference proceedings will be published by IEEE/CS and will be available for the Conference. Papers exceeding 8 pages will be charged Dfl. 100,-- per page in excess. Submission of short contributions Authors should submit four copies of a full paper or an extended summary to the Short Contribution Chairperson before May 31st, 1996. They will be notified of acceptance by July 14th, 1996. A submission should be limited to 10 pages (for a full paper) and to 3 pages (for an extended summary). It should be accompanied by a covering front sheet containing the author name(s), affiliation(s), mailing address, e-mail address, telephone and fax numbers, and up to three keywords. A brief statement emphasizing those points which make the contribution different from work published earlier, or elsewhere, will assist the referees in making their decisions.In order that anonymous reviewing can be carried out, the contri bution and its title page should not contain the name(s) of the author(s) or their affiliation(s).The four copies of the submitted contribution should be accompanied by the following signed statement: If accepted, this short contribution will be made available in its final format at the Euromicro 96 Conference, and will be personally presented at the Euromicro 96 Conference by the author or one of the co-authors.Accepted contributions, personally presented at the conference by the author or one of the co-authors, will be published in the Euromicro Journal, as extended summary or full paper depending on their final quality. Programme Committee Peter Milligan, United Kingdom (Chairman) K. Kuchcinski, Sweden (Deputy Chairman) A. Antola, Italy E. Biersack, France Z. Blazek, Czech Republic B. Chapman, Austria G. Ciccarella, Italy G. Chroust, Austria I. Demeure, France F. Distante, Italy I. Erenyi, Hungary K. Fazekas, Hungary E. Fernandes, Brazil K. Grosspietsch, Germany A. Gonzalez, Spain K. Judmann, Austria P. Kacsuk, Hungary J. Karjalainen, Finland K. Kloeckner, Germany K. Kock, Germany G. Leon, Spain E. Luque, Spain L. Mezzalira, Italy J. Molgaard, Denmark A. Nunez, Spain P. Paolini, Italy A. Pawlak, Germany M. Perkowski, USA E. Pissaloux, France A. Postula, Australia E. von Puttkamer, Germany B. Robic, Slovenia J. Rugelj, Slovenia C. Ruland, Germany P. Sage, United Kingdom M. Sami, Italy N. Scarabottolo, Italy H. Schumny, Germany R. Stefanelli, Italy J-B. Stefani, France M. Taylor, United Kingdom J. Tiberghien, Belgium F. Tirado, Spain S. Tohme, France A. Tyrrell, United Kingdom F. Vajda, Hungary M. Valero, Spain K. Waldschmidt, Germany S. Winter, United Kingdom E. Zapata, Spain H. Zima, Austria From owner-Big-Internet@munnari.OZ.AU Tue Nov 21 06:27:55 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25966; Tue, 21 Nov 1995 06:27:55 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA12645; Tue, 21 Nov 1995 06:27:25 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA12628; Tue, 21 Nov 1995 06:20:51 +1100 From: cbramwell@intellibyte.com Received: from melon.jaist.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16448; Tue, 21 Nov 1995 06:20:38 +1100 (from cbramwell@intellibyte.com) Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Tue, 21 Nov 1995 04:07:49 +0900 Received: from thegate.intellibyte.com (intellibyte.north.net [198.52.33.78]) by uunorth.north.net (8.6.11/8.6.9) with SMTP id PAA06573; Mon, 20 Nov 1995 15:02:23 -0500 Received: from cjblap by thegate.intellibyte.com id aa01259; 20 Nov 95 13:11 EST X-Mailer: SuperTCP for Windows Version 4.00 R2 (Mailer Version 1.02) Message-Id: <30B0D328-00000001@cjblap.intellibyte.com> Date: Mon, 20 Nov 1995 13:12:37 cst Subject: NOSDAV Mailing list To: nossdav96-announce@jaist.ac.jp Cc: tatsuo@jaist.ac.jp Mime-Version: 1.0 Content-Type: Text/Plain; Charset=US-ASCII Precedence: bulk To whom it may concern. I received your address from tdcl@spiderman.bu.edu I am currently on the distribution list for NOSSDAV. I would very much like to remain on the e-mailing list, however, my email address has changed from HINWOOD@oise.on.ca to: cbramwell@intellibyte.com Could you please either make the change on the distribution list, or tell me whom I should contact. Thanking you in advance for your attention to this detail. (Please acknowledge the receipt of this message) --------------------------------------------------------------------- from: cbramwell@intellibyte.com Cameron Bramwell Intellibyte Inc. 330 Bay Street, Suite 1600 Toronto, Ontario, Canada M5H 2S8 Voice 416-368-7817 Ex#28 FAX 416-368-4617 ----------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Tue Nov 21 10:28:00 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01191; Tue, 21 Nov 1995 10:28:00 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA12884; Tue, 21 Nov 1995 10:27:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA12867; Tue, 21 Nov 1995 10:19:13 +1100 Received: from melon.jaist.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02327; Tue, 21 Nov 1995 10:19:06 +1100 (from aurel@ctr.columbia.edu) Received: by melon.jaist.ac.jp (8.6.9+2.4Wb3/2.8Wb); Tue, 21 Nov 1995 08:08:54 +0900 Received: from milkyway.ctr.columbia.edu (milkyway.ctr.columbia.edu [128.59.68.51]) by sirius.ctr.columbia.edu (8.7.1/8.6.4.287) with SMTP id SAA06860; Mon, 20 Nov 1995 18:08:43 -0500 (EST) From: aurel@ctr.columbia.edu (Aurel A. Lazar) Received: (aurel@localhost) by milkyway.ctr.columbia.edu (8.6.10/8.6.4.788743) id SAA05195; Mon, 20 Nov 1995 18:08:06 -0500 Date: Mon, 20 Nov 1995 18:08:06 -0500 Message-Id: <199511202308.SAA05195@milkyway.ctr.columbia.edu> To: nossdav96-announce@jaist.ac.jp Subject: xbind software available in alpha release Cc: aurel@ctr.columbia.edu Precedence: bulk I would like to let you know that the xbind software is available for experimental evaluation (alpha release). Currently, we have completed a prototype implementation of our open signalling architecture in our laboratory and are undergoing trials with other sites on NYNET, an ATM Network operating in New York State and Massachusetts. Our software runs on SunOS, Solaris and HP-UX as well as on the FORE ASX100/200 series of switches. Multimedia devices currently supported include Sunvideo and Parallax Graphics video cards, Sun Sparc, SGI and HP native audio devices. We have also implemented a prototype Video and CD quality Audio conferencing services as part of the current xbind release. Work is currently ongoing to port the system to the NEC 5 series ATM switches and to the AIX (DSOM) and Windows NT operating systems. All the information you need for downloading the software can be found in http://www.ctr.columbia.edu/comet/xbind/xbind.html. Aurel From owner-Big-Internet@munnari.OZ.AU Tue Nov 21 13:07:44 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10667; Tue, 21 Nov 1995 13:07:44 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13032; Tue, 21 Nov 1995 13:07:30 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA13013; Tue, 21 Nov 1995 12:54:11 +1100 Received: from portia.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08771; Tue, 21 Nov 1995 12:53:56 +1100 (from marnellm@portia.portia.com) Received: from [127.0.0.1] (marnellm@[127.0.0.1]) by portia.portia.com (8.6.12/8.6.10) with SMTP id UAA05485 for ; Mon, 20 Nov 1995 20:33:32 -0500 Message-Id: <199511210133.UAA05485@portia.portia.com> X-Authentication-Warning: portia.portia.com: Host [127.0.0.1] didn't use HELO protocol X-Mailer: exmh version 1.6.2 4/21/95 To: big-internet@munnari.OZ.AU Subject: What is NOSSDAV? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 20 Nov 1995 20:33:31 -0500 From: Matthew James Marnell Precedence: bulk nossdav96-announce@jaist.ac.jp Getting quite tired of this. What is NOSSDAV and why am I getting email from the above address. For some reason it is coming via: murtoa.cs.mu.oz.au? I can figure out how to get off of it, unless of course someone has subscribed another list I'm on to the NOSSDAV list, which does me no good at all. Has someone subscribed the Big-Internet to Nossdav? Matt -- Matt Marnell Portia Communication & Internet Services CEO/CIO Inet Consulting, Training, Info Services marnellm@portia.com Web Authoring and Unix Consulting and Admin http://www.portia.com v: (513)435-6534 f: (513)435-6643 From owner-Big-Internet@munnari.OZ.AU Tue Nov 21 22:49:16 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA31529; Tue, 21 Nov 1995 22:49:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA13525; Tue, 21 Nov 1995 22:47:35 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA13508; Tue, 21 Nov 1995 22:37:32 +1100 Received: from ncc.ripe.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04305; Tue, 21 Nov 1995 22:37:21 +1100 (from geertj@ripe.net) Received: from berklix.ripe.net by ncc.ripe.net with SMTP id AA02100 (5.65a/NCC-2.30); Tue, 21 Nov 1995 12:36:34 +0100 Received: from berklix.ripe.net (geertj@localhost.ripe.net [127.0.0.1]) by berklix.ripe.net (8.6.12/8.6.9) with ESMTP id UAA00300; Mon, 20 Nov 1995 20:53:21 +0100 Message-Id: <199511201953.UAA00300@berklix.ripe.net> To: keith@pipex.com (Keith Mitchell) Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org From: Geert Jan de Groot X-Organization: RIPE Network Coordination Centre X-Phone: +31 20 592 5065 Subject: Re: Routing wars pending? In-Reply-To: Your message of "Mon, 20 Nov 1995 13:16:12 GMT." <199511201316.NAA11997@pipe.pipex.net> Date: Mon, 20 Nov 1995 20:53:20 +0100 Sender: GeertJan.deGroot@ripe.net Precedence: bulk On Mon, 20 Nov 1995 13:16:12 +0000 Keith Mitchell wrote: > In <199511171540.KAA04630@faline.bellcore.com>, wrote: > A better telephony example perhaps is that of GSM roaming, where > there is no mapping from a a "logical" 800 number to a physical > geographic code identifying the end-point. Instead the phone is still > addressed by it's home country and area code, even when it is > in another country. I think the routing is currently done by host > redirection. > > I suspect that currently roamed mobile phone use is sufficiently rare > that there are not scaling problems with this approach at present, > but with GSM growth comparable to Internet growth I think they may > have a few headaches ahead... GSM, at least in the Netherlands, uses the priciple that if you're out of your 'region', that you pay the transit between the home-country and the place you are. E.g. if a Dutch subscriber is in France and receives a call from the Netherlands, then the caller pays mobile phone rates for a Dutch mobile call, and the GSM owner pays a rate from the Netherlands to France, i.e. the GSM owner pays for its mobility and the extra transit involved. We could do the same with IP (encapsulating it), but somehow I feel that this approach will never be popular, either with GSM or with IP... Geert Jan From owner-Big-Internet@munnari.OZ.AU Mon Nov 27 15:10:20 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA32454; Mon, 27 Nov 1995 15:10:20 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA20543; Mon, 27 Nov 1995 15:09:47 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA20537; Mon, 27 Nov 1995 15:02:10 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19933; Mon, 27 Nov 1995 15:01:43 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id XAA05234; Sun, 26 Nov 1995 23:00:49 -0500 Date: Sun, 26 Nov 1995 23:00:49 -0500 From: Avi Freedman Message-Id: <199511270400.XAA05234@netaxs.com> To: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu Subject: CIDR Aggregation Tool Cc: freedman@netaxs.com Precedence: bulk Well, after observing the debates about What To Do About The Routing Table Size, I decided to work on some informal tools to examine the current routing table space for possible aggregations. Right now, the raw data is the routing table from the Net Access MAE-East router. It only searches for aggregates /15 < x < /25 right now - ignoring some fairly obvious aggregation-suggestions in the /8 < x < /16 range. The results are up at http://routes.netaxs.com and the some of the caveats are listed on the web page, but are: 1) When the Net Access MAE-East router has multiple identical routes that point to the same next-hop (192.41.177.x), the system only uses the one first listed in the cisco 'sho ip bgp summ' output - even though that's not always the 'best' route. 2) When an AS advertises both an aggregate and a specific, the specific is 'dropped' by the aggregator. If the input is: {205.89.10.128/17, 205.89.10.130}, the output will be: {205.89.10.128/17} (205.89.10.130 will be dropped). 3) The source of data is the Net Access MAE-East router routing table, and we don't peer with all parties at MAE-East directly - thus, it's possible that the system catches aggregations that are impossible because they're announced to a 3rd party via different paths - but an informal look around doesn't appear to indicate that. 4) The system goes by next-hop rather than by AS-Path. There seems to be a good correlation, but ... Also, the final disclaimer: I've examined the results and they *look* reasonable. But I haven't written tester-tools to attempt to verify by another algorithm that the results are correct. Here's the table at the end of the web page: Before After Run Agg. Run 192.41.177.110 ibm 81 68 192.41.177.115 digex 98 98 192.41.177.120 eu.net 949 775 192.41.177.125 nsn.nasa 126 112 192.41.177.140 ans 2146 1425 192.41.177.145 agis 539 304 192.41.177.150 uscyber 2 2 192.41.177.160 interpath 2 2 192.41.177.170 net99 309 246 192.41.177.180 mci 2 2 192.41.177.181 mci 8963 6828 192.41.177.190 pipex 367 308 192.41.177.210 netcom 370 348 192.41.177.235 psi 1 1 192.41.177.240 icp 4499 3712 192.41.177.241 sprintlink 6429 4694 192.41.177.245 psi 1491 1098 192.41.177.249 alternet 3971 3148 192.41.177.251 es.net 96 88 192.41.177.252 es.net 122 101 192.41.177.6 suranet 470 445 192.41.177.70 internex 1 1 192.41.177.80 ios 10 8 192.41.177.85 cais 184 158 192.41.177.86 hlc 354 243 192.41.177.89 energis 2 2 192.41.177.95 delphi 3 3 A final note: We're open to {Additional static sources of route tables at MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken, or the PacBell NAP}; and dynamic (i.e. the vty password so we can run a sho ip bgp summ every so often) sources at any of the MAEs or NAPs. If we get good feedback, we may automate this to run overnight and keep a history. Avi Freedman freedman@netaxs.com From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 01:50:06 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03855; Tue, 28 Nov 1995 01:50:06 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA21180; Tue, 28 Nov 1995 01:49:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA21174; Tue, 28 Nov 1995 01:40:24 +1100 Received: from clone3.Reston.mci.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03453; Tue, 28 Nov 1995 01:40:15 +1100 (from enke@mci.net) Received: from localhost ([127.0.0.1]) by clone3.Reston.mci.net (8.6.12/8.6.6) with ESMTP id JAA27275; Mon, 27 Nov 1995 09:39:36 -0500 Message-Id: <199511271439.JAA27275@clone3.Reston.mci.net> To: Avi Freedman Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu, enke@mci.net Subject: Re: CIDR Aggregation Tool In-Reply-To: Your message of "Sun, 26 Nov 1995 23:00:49 EST." <199511270400.XAA05234@netaxs.com> Date: Mon, 27 Nov 1995 09:39:35 -0500 From: Enke Chen Precedence: bulk Avi, Did you not see the aggregation report by Tony Bates on cidrd posted periodically for the last couple of years? It lists aggregation gains for each origin AS, rather than the BGP neighbor in your numbers. IMHO, numbers based on origin AS is much more useful. If you need to invent wheels, let us at least invent better wheels :-) -- Enke Date: Mon, 27 Nov 1995 01:34:55 EST To: cidrd@iepg.org From: Tony Bates Subject: In the spirit... Here's the latest top-30. Looks like UUNET-CANADA dropped a fair bit from last time. --Tony. ASnum NetsNow NetsCIDR NetGain % Gain Description AS2493 1047 576 471 45.0% i*internet AS174 1493 1053 440 29.5% Performance Systems International AS544 740 524 216 29.2% The DataNet IP Service AS3848 425 236 189 44.5% WORLDLINX AS568 759 572 187 24.6% Milnet FIXes--144(W)/145(E) AS4628 240 54 186 77.5% APNIC-AS-BLOCK AS1324 465 287 178 38.3% ANS New York City - DNSS 35 AS97 506 338 168 33.2% JvNCnet AS3602 285 175 110 38.6% Intergrated Network Services Inc. AS4230 195 93 102 52.3% EMBRATEL-BR AS1717 649 556 93 14.3% RENATER [....] > Date: Sun, 26 Nov 1995 23:00:49 -0500 > From: Avi Freedman > To: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu > CC: freedman@netaxs.com > Well, after observing the debates about What To Do About The Routing Table > Size, I decided to work on some informal tools to examine the current > routing table space for possible aggregations. > > Right now, the raw data is the routing table from the Net Access MAE-East > router. > > It only searches for aggregates /15 < x < /25 right now - ignoring some > fairly obvious aggregation-suggestions in the /8 < x < /16 range. > > The results are up at http://routes.netaxs.com and the some of the caveats > are listed on the web page, but are: > > 1) When the Net Access MAE-East router has multiple identical routes that > point to the same next-hop (192.41.177.x), the system only uses the one > first listed in the cisco 'sho ip bgp summ' output - even though that's > not always the 'best' route. > > 2) When an AS advertises both an aggregate and a specific, the specific > is 'dropped' by the aggregator. If the input is: > {205.89.10.128/17, 205.89.10.130}, the output will be: > {205.89.10.128/17} (205.89.10.130 will be dropped). > > 3) The source of data is the Net Access MAE-East router routing table, > and we don't peer with all parties at MAE-East directly - thus, it's > possible that the system catches aggregations that are impossible > because they're announced to a 3rd party via different paths - but > an informal look around doesn't appear to indicate that. > > 4) The system goes by next-hop rather than by AS-Path. There seems to > be a good correlation, but ... > > Also, the final disclaimer: I've examined the results and they *look* > reasonable. But I haven't written tester-tools to attempt to verify > by another algorithm that the results are correct. > > Here's the table at the end of the web page: > > Before After > Run Agg. Run > 192.41.177.110 ibm 81 68 > 192.41.177.115 digex 98 98 > 192.41.177.120 eu.net 949 775 > 192.41.177.125 nsn.nasa 126 112 > 192.41.177.140 ans 2146 1425 > 192.41.177.145 agis 539 304 > 192.41.177.150 uscyber 2 2 > 192.41.177.160 interpath 2 2 > 192.41.177.170 net99 309 246 > 192.41.177.180 mci 2 2 > 192.41.177.181 mci 8963 6828 > 192.41.177.190 pipex 367 308 > 192.41.177.210 netcom 370 348 > 192.41.177.235 psi 1 1 > 192.41.177.240 icp 4499 3712 > 192.41.177.241 sprintlink 6429 4694 > 192.41.177.245 psi 1491 1098 > 192.41.177.249 alternet 3971 3148 > 192.41.177.251 es.net 96 88 > 192.41.177.252 es.net 122 101 > 192.41.177.6 suranet 470 445 > 192.41.177.70 internex 1 1 > 192.41.177.80 ios 10 8 > 192.41.177.85 cais 184 158 > 192.41.177.86 hlc 354 243 > 192.41.177.89 energis 2 2 > 192.41.177.95 delphi 3 3 > > A final note: We're open to {Additional static sources of route tables at > MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken, > or the PacBell NAP}; and dynamic (i.e. the vty password so we can run > a sho ip bgp summ every so often) sources at any of the MAEs or NAPs. > > If we get good feedback, we may automate this to run overnight and keep > a history. > > Avi Freedman > freedman@netaxs.com > From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 03:10:34 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05856; Tue, 28 Nov 1995 03:10:34 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21264; Tue, 28 Nov 1995 03:09:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21258; Tue, 28 Nov 1995 03:04:28 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09106; Tue, 28 Nov 1995 03:04:26 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id LAA08941; Mon, 27 Nov 1995 11:04:21 -0500 From: Avi Freedman Message-Id: <199511271604.LAA08941@netaxs.com> Subject: Re: CIDR Aggregation Tool To: enke@mci.net (Enke Chen) Date: Mon, 27 Nov 1995 11:04:20 -0500 (EST) Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu, enke@mci.net In-Reply-To: <199511271439.JAA27275@clone3.Reston.mci.net> from "Enke Chen" at Nov 27, 95 09:39:35 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 897 Precedence: bulk > Avi, > Did you not see the aggregation report by Tony Bates on cidrd > posted periodically for the last couple of years? It lists > aggregation gains for each origin AS, rather than the BGP > neighbor in your numbers. IMHO, numbers based on origin AS > is much more useful. > > If you need to invent wheels, let us at least invent better > wheels :-) > > -- Enke No, I missed the ASnum-based report by Tony on cidrd. In any case, I thought it would be useful to try to gather the data independently on real data in use by our network... Also, the report based on ASN tends to miss JVNC etc... which can be aggregated by their transit provider at the peering/exchange locations. Reports based on just next-hop seem to catch the top-level aggregation possibilities (i.e. a customer of JVNC & a customer of some other ISP might have adjacent /24s that could be aggregated)... Avi From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 03:30:29 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22032; Tue, 28 Nov 1995 03:30:29 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21310; Tue, 28 Nov 1995 03:29:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21295; Tue, 28 Nov 1995 03:17:48 +1100 Received: from aero.branch.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23476; Tue, 28 Nov 1995 03:17:36 +1100 (from jon@branch.com) Received: by aero.branch.com (mail) id m0tK6FH-000Nj6C; Mon, 27 Nov 95 11:17 EST Message-Id: From: jon@branch.com (Jon Zeeff) Subject: Re: CIDR Aggregation Tool To: freedman@netaxs.com (Avi Freedman) Date: Mon, 27 Nov 1995 11:17:30 -0500 (EST) Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu, freedman@netaxs.com In-Reply-To: <199511270400.XAA05234@netaxs.com> from "Avi Freedman" at Nov 26, 95 11:00:49 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 402 Precedence: bulk Perhaps this is just a small error that has to be accepted in your measurements, but we are dual homed and require both the aggregate and the specific. > 2) When an AS advertises both an aggregate and a specific, the specific > is 'dropped' by the aggregator. If the input is: > {205.89.10.128/17, 205.89.10.130}, the output will be: > {205.89.10.128/17} (205.89.10.130 will be dropped). From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 03:50:04 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13572; Tue, 28 Nov 1995 03:50:04 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21352; Tue, 28 Nov 1995 03:49:56 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21346; Tue, 28 Nov 1995 03:47:02 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01667; Tue, 28 Nov 1995 03:47:00 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id LAA10434; Mon, 27 Nov 1995 11:46:54 -0500 From: Avi Freedman Message-Id: <199511271646.LAA10434@netaxs.com> Subject: Re: CIDR Aggregation Tool To: freedman@netaxs.com (Avi Freedman) Date: Mon, 27 Nov 1995 11:46:53 -0500 (EST) Cc: enke@mci.net, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271604.LAA08941@netaxs.com> from "Avi Freedman" at Nov 27, 95 11:04:20 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 249 Precedence: bulk > Also, the report based on ASN tends to miss JVNC etc... which > can be aggregated by their transit provider at the peering/exchange > locations. Oops. I meant to say "the report based on next-hop", not "the report based on ASN". Sorry... Avi From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 03:51:09 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06536; Tue, 28 Nov 1995 03:51:09 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21374; Tue, 28 Nov 1995 03:51:00 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21343; Tue, 28 Nov 1995 03:44:23 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA30129; Tue, 28 Nov 1995 03:44:19 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id LAA10333; Mon, 27 Nov 1995 11:44:13 -0500 From: Avi Freedman Message-Id: <199511271644.LAA10333@netaxs.com> Subject: Re: CIDR Aggregation Tool To: jon@branch.com (Jon Zeeff) Date: Mon, 27 Nov 1995 11:44:12 -0500 (EST) Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu In-Reply-To: from "Jon Zeeff" at Nov 27, 95 11:17:30 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1372 Precedence: bulk > Perhaps this is just a small error that has to be accepted in your > measurements, but we are dual homed and require both the aggregate and > the specific. > > > 2) When an AS advertises both an aggregate and a specific, the specific > > is 'dropped' by the aggregator. If the input is: > > {205.89.10.128/17, 205.89.10.130}, the output will be: > > {205.89.10.128/17} (205.89.10.130 will be dropped). The 205.88.10.128 was a random example. I hope that's not you :) There are no "value" judgements made by the tool - it's just suggesting aggregates. And if we see an aggregate and a specific, both set to the same next-hop, it's quite likely that it's the same AS announcing both routes, and that they (your transit provider(s)) could do the aggregation themselves - but the tool *is* deficient in that right now it doesn't consider AS-paths. As an example, picking an IP for branch.com (198.111.253.37): Our route table has: *> 198.111.252.0 192.41.177.145 <--- agis *> 198.111.252.0/22 192.41.177.181 <--- mci *> 198.111.253.0 192.41.177.145 <--- agis *> 198.111.255.0 192.41.177.145 <--- agis So if 198.111.252/23 is suggested as an aggregate for the 192.41.177.145 (AGIS) target, that's because it looks like AGIS could in fact announce 198.111.22.0/23 instead of 198.111.252/0 and 198.111.253.0. Avi From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 05:10:08 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10221; Tue, 28 Nov 1995 05:10:08 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA21494; Tue, 28 Nov 1995 05:09:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA21476; Tue, 28 Nov 1995 04:53:16 +1100 Received: from aero.branch.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03589; Tue, 28 Nov 1995 04:53:11 +1100 (from jon@branch.com) Received: by aero.branch.com (mail) id m0tK7jS-000Nj7C; Mon, 27 Nov 95 12:52 EST Message-Id: From: jon@branch.com (Jon Zeeff) Subject: Re: CIDR Aggregation Tool To: freedman@netaxs.com (Avi Freedman) Date: Mon, 27 Nov 1995 12:52:45 -0500 (EST) Cc: jon@branch.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271644.LAA10333@netaxs.com> from "Avi Freedman" at Nov 27, 95 11:44:12 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 751 Precedence: bulk > Our route table has: > *> 198.111.252.0 192.41.177.145 <--- agis > *> 198.111.252.0/22 192.41.177.181 <--- mci > *> 198.111.253.0 192.41.177.145 <--- agis > *> 198.111.255.0 192.41.177.145 <--- agis This isn't what agis is supposed to be announcing, I'll have to ask them again to announce 198.111.252/22. There's a couple less routes already :-). Once that is fixed, further aggregation of 198.111.252.0 (say into 198.111/16, as a non real example) would change our routing (in ways we don't want it changed), even with your "next hop the same" criteria because of the additional meaning that specifics have in terms of priority. I agree that your tool is usefull in identifying _potential_ savings. From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 05:30:29 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06751; Tue, 28 Nov 1995 05:30:29 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA21550; Tue, 28 Nov 1995 05:29:55 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA21527; Tue, 28 Nov 1995 05:14:21 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08304; Tue, 28 Nov 1995 05:14:17 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id NAA13291; Mon, 27 Nov 1995 13:04:17 -0500 From: Avi Freedman Message-Id: <199511271804.NAA13291@netaxs.com> Subject: Re: CIDR Aggregation Tool To: jon@branch.com (Jon Zeeff) Date: Mon, 27 Nov 1995 13:04:14 -0500 (EST) Cc: jon@branch.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu In-Reply-To: from "Jon Zeeff" at Nov 27, 95 12:52:45 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1203 Precedence: bulk [Please take any other responses just to cidrd. This is copied to big-inet and nanog so people will see the followup request. I just wanted the announcement to go out maximally, but the details and responses are of no interet to nanog as a whole...] > > Our route table has: > > *> 198.111.252.0 192.41.177.145 <--- agis > > *> 198.111.252.0/22 192.41.177.181 <--- mci > > *> 198.111.253.0 192.41.177.145 <--- agis > > *> 198.111.255.0 192.41.177.145 <--- agis > > This isn't what agis is supposed to be announcing, I'll have to > ask them again to announce 198.111.252/22. There's a couple less > routes already :-). > > Once that is fixed, further aggregation of 198.111.252.0 (say into > 198.111/16, as a non real example) would change our routing (in > ways we don't want it changed), even with your "next hop the same" > criteria because of the additional meaning that specifics have in > terms of priority. Well, we only see 198.111.252, 253, and 255 from AGIS, so there's no danger of AGIS over-aggregating even if they combined 252 & 253... > I agree that your tool is usefull in identifying _potential_ savings. That's all it's for. Avi From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 06:10:29 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14984; Tue, 28 Nov 1995 06:10:29 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA21599; Tue, 28 Nov 1995 06:09:56 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA21584; Tue, 28 Nov 1995 05:50:30 +1100 Received: from brookfield-ef0.brookfield.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05636; Tue, 28 Nov 1995 05:50:28 +1100 (from curtis@brookfield.ans.net) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id NAA01164; Mon, 27 Nov 1995 13:50:17 -0500 Message-Id: <199511271850.NAA01164@brookfield.ans.net> To: Avi Freedman Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu Reply-To: curtis@ans.net Subject: Re: CIDR Aggregation Tool In-Reply-To: Your message of "Sun, 26 Nov 1995 23:00:49 EST." <199511270400.XAA05234@netaxs.com> Date: Mon, 27 Nov 1995 13:50:17 -0500 From: Curtis Villamizar Precedence: bulk Avi, While this is useful as a metric of the degree of aggregation, it is not sufficient to configure aggregation. This is still useful as a means to look at where improvement may be needed. Please don't get me wrong in pointing out that there are limits to the applicability, this *is* useful. In message <199511270400.XAA05234@netaxs.com>, Avi Freedman writes: > Well, after observing the debates about What To Do About The Routing Table > Size, I decided to work on some informal tools to examine the current > routing table space for possible aggregations. > > Right now, the raw data is the routing table from the Net Access MAE-East > router. > > It only searches for aggregates /15 < x < /25 right now - ignoring some > fairly obvious aggregation-suggestions in the /8 < x < /16 range. > > The results are up at http://routes.netaxs.com and the some of the caveats > are listed on the web page, but are: > > 1) When the Net Access MAE-East router has multiple identical routes that > point to the same next-hop (192.41.177.x), the system only uses the one > first listed in the cisco 'sho ip bgp summ' output - even though that's > not always the 'best' route. The routing table seen at one place in the Internet is insufficient to determine whether aggregation is possible. Part of the problem is that equally specific alternate paths are supressed until primary connectivity is lost. You may not see alternate paths for multihomed sites that would prevent aggregation. > 2) When an AS advertises both an aggregate and a specific, the specific > is 'dropped' by the aggregator. If the input is: > {205.89.10.128/17, 205.89.10.130}, the output will be: > {205.89.10.128/17} (205.89.10.130 will be dropped). This is often done to allow a multihomed component of an aggregate to be routed correctly while still providing the backup path, or allowing load splitting across providers (usually load split by AS path filtering or more simply by AS path length). There is no way to tell a mistake from this being done intentionally. > 3) The source of data is the Net Access MAE-East router routing table, > and we don't peer with all parties at MAE-East directly - thus, it's > possible that the system catches aggregations that are impossible > because they're announced to a 3rd party via different paths - but > an informal look around doesn't appear to indicate that. > > 4) The system goes by next-hop rather than by AS-Path. There seems to > be a good correlation, but ... You really need to take into account AS path. As far back as 1992 we've seen grossly optimistic estimates based solely on next hop at single points (including estimates from me in June/July 1992). In effect what you have is the degree of aggregation possible if the aggregartion boundry was extended around the entire rest of the world (or at least everyone that peered directly with you at the point of measurement). What can be aggregated according to such an estimate will vary according to who is making the measurement and where. > Also, the final disclaimer: I've examined the results and they *look* > reasonable. But I haven't written tester-tools to attempt to verify > by another algorithm that the results are correct. > > Here's the table at the end of the web page: > > Before After > Run Agg. Run > 192.41.177.110 ibm 81 68 > 192.41.177.115 digex 98 98 > 192.41.177.120 eu.net 949 775 > 192.41.177.125 nsn.nasa 126 112 > 192.41.177.140 ans 2146 1425 > 192.41.177.145 agis 539 304 > 192.41.177.150 uscyber 2 2 > 192.41.177.160 interpath 2 2 > 192.41.177.170 net99 309 246 > 192.41.177.180 mci 2 2 > 192.41.177.181 mci 8963 6828 > 192.41.177.190 pipex 367 308 > 192.41.177.210 netcom 370 348 > 192.41.177.235 psi 1 1 > 192.41.177.240 icp 4499 3712 > 192.41.177.241 sprintlink 6429 4694 > 192.41.177.245 psi 1491 1098 > 192.41.177.249 alternet 3971 3148 > 192.41.177.251 es.net 96 88 > 192.41.177.252 es.net 122 101 > 192.41.177.6 suranet 470 445 > 192.41.177.70 internex 1 1 > 192.41.177.80 ios 10 8 > 192.41.177.85 cais 184 158 > 192.41.177.86 hlc 354 243 > 192.41.177.89 energis 2 2 > 192.41.177.95 delphi 3 3 > > A final note: We're open to {Additional static sources of route tables at > MAE-East; Additional static sources of route tables at {MAE-West, Pennsauken, > or the PacBell NAP}; and dynamic (i.e. the vty password so we can run > a sho ip bgp summ every so often) sources at any of the MAEs or NAPs. You will find that while improvement is possible, and may still even be fairly substantial, your figures represent an optimistic estimate. Another way of estimating what can be aggregated is by determining from how many places all of the components of an aggregate could be heard in all backup situations. In some cases it might be reasonable to drop some degree of alternate connectivity (fourth or fifth preferred paths) and allow a number of holes (specifically aggregated components). In principle this could be done algorithmically using the IRR. In practice, you need to check with some of the parties involved to make sure registered information (particialrly aut-num AS peerings) are accurate beforehand. Using the IRR you (or we) can select candidates for aggregation and then make sure the aggregation can really be asfely done. This is a little different in than you estimate in that it the viewpoint is what can we aggregate, rather than what might we see better aggregated in the future. The bgp paths at major interconnects could form a useful sanity check, making sure that AS paths do not conflict with IRR AS peering information for any candidate for aggregation. > If we get good feedback, we may automate this to run overnight and keep > a history. > > Avi Freedman > freedman@netaxs.com Thanks for the information. Curtis ps- This thread was not about ANS, but for those following NANOG activity might who may want it, here is a brief update. We have not yet deployed the code needed to generate configurations that take advantage of aggregates marked in the IRR. For a rough hint at where we are headed, see: ftp://ftp.ans.net/pub/papers/slides/nanog-sep-1995-proxy-agg.ps From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 06:30:28 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04344; Tue, 28 Nov 1995 06:30:28 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA21655; Tue, 28 Nov 1995 06:29:57 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA21635; Tue, 28 Nov 1995 06:22:55 +1100 Received: from aero.branch.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12543; Tue, 28 Nov 1995 06:22:53 +1100 (from jon@branch.com) Received: by aero.branch.com (mail) id m0tK97D-000Nj7C; Mon, 27 Nov 95 14:21 EST Message-Id: From: jon@branch.com (Jon Zeeff) Subject: Re: CIDR Aggregation Tool To: curtis@ans.net Date: Mon, 27 Nov 1995 14:21:22 -0500 (EST) Cc: freedman@netaxs.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271850.NAA01164@brookfield.ans.net> from "Curtis Villamizar" at Nov 27, 95 01:50:17 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 394 Precedence: bulk I wouldn't mind if aggregation was done automatically unless the route was specifically registered somewhere as being a "don't aggregate" route. In other words, let people indicate if it wasn't a mistake. > load splitting across providers (usually load split by AS path > filtering or more simply by AS path length). There is no way to tell > a mistake from this being done intentionally. From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 06:32:48 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07097; Tue, 28 Nov 1995 06:32:48 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA21677; Tue, 28 Nov 1995 06:32:30 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA21632; Tue, 28 Nov 1995 06:17:05 +1100 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07030; Tue, 28 Nov 1995 06:17:02 +1100 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id OAA16293; Mon, 27 Nov 1995 14:16:49 -0500 From: Avi Freedman Message-Id: <199511271916.OAA16293@netaxs.com> Subject: Re: CIDR Aggregation Tool To: curtis@ans.net Date: Mon, 27 Nov 1995 14:16:48 -0500 (EST) Cc: big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu In-Reply-To: <199511271850.NAA01164@brookfield.ans.net> from "Curtis Villamizar" at Nov 27, 95 01:50:17 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1709 Precedence: bulk > Avi, > > While this is useful as a metric of the degree of aggregation, it is > not sufficient to configure aggregation. This is still useful as a > means to look at where improvement may be needed. Please don't get me > wrong in pointing out that there are limits to the applicability, this > *is* useful. I should have been much more specific. There was never any intent to suggest that this was a configuration-generator... Nor was there any intent to imply that certain providers are bad or remiss or misconfigured or underconfigured... The hope was that it might be useful as something to look at (a raw generator of aggregation-possibilities). Also, I was interested in seeing how many routes could be aggregated at one peering point (not inside a provider's network, but at one edge). For example, if the processing to compute the aggregations was low, and only aggregated entries were inserted into a cache (but the actual BGP announced more specific entries were kept in the routing table), perhaps that would help if route table and/or cache table size was/is still a problem. But it seems that the current generation of technology that is out there doesn't run into a SP-cache-size wall from either a switching-speed or memory angle. > You will find that while improvement is possible, and may still even > be fairly substantial, your figures represent an optimistic estimate. Agreed. [Suggestions re: IRR deleted for brevity.] Agreed re: the IRR as well. Next on the list is to examine the Merit tools. Sigh - my nanog notes were lost when my 200LX was stolen, but I know where to find the tools... > Thanks for the information. Thanks for the feedback. > Curtis Avi From owner-Big-Internet@munnari.OZ.AU Tue Nov 28 17:30:44 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id GA02731; Tue, 28 Nov 1995 17:30:44 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA22274; Tue, 28 Nov 1995 17:30:06 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA22257; Tue, 28 Nov 1995 17:13:29 +1100 Received: from brookfield-ef0.brookfield.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id GA18883; Tue, 28 Nov 1995 17:13:19 +1100 (from curtis@brookfield.ans.net) Received: from brookfield.ans.net (localhost.brookfield.ans.net [127.0.0.1]) by brookfield.ans.net (8.6.12/8.6.12) with ESMTP id BAA04101; Tue, 28 Nov 1995 01:12:10 -0500 Message-Id: <199511280612.BAA04101@brookfield.ans.net> To: jon@branch.com (Jon Zeeff) Cc: curtis@ans.net, freedman@netaxs.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu Reply-To: curtis@ans.net Subject: Re: CIDR Aggregation Tool In-Reply-To: Your message of "Mon, 27 Nov 1995 14:21:22 EST." Date: Tue, 28 Nov 1995 01:12:09 -0500 From: Curtis Villamizar Precedence: bulk In message , Jon Zeeff writes: > I wouldn't mind if aggregation was done automatically unless > the route was specifically registered somewhere as being a > "don't aggregate" route. In other words, let people indicate > if it wasn't a mistake. > > > load splitting across providers (usually load split by AS path > > filtering or more simply by AS path length). There is no way to tell > > a mistake from this being done intentionally. A glance at the IRR is all it takes to find a dual homed site and determined that even though primary connectivity is through the same path as the aggregate an alternate path goes through another path. The answer there is often to aggregate anyway and pass the dual homed exceptions as explicit component routes. Problems can arise if there is no aut-num object for the AS in question, or the object is not accurate, or the routes in question don't have their own AS and are not registered correctly. Of course, if you can't be bothered registering in the IRR correctly, you have to accept the consequences. In the context of ANS's scheme after determining that something could be aggregated we would mark the aggregate with the community ANSAGGREGATE and the components with the community ANSCOMPONENTS. The rest is (not yet deployed, and not quite completely coded) magic. The aggregate would be formed in the next config run. There is also plan to use ANSPROXYAGGR and ANSPROXYCOMP but marking other peoples route objects (the components of a proxy aggregate) with a community is a hard thing to do if not in the maintainer list for the object. Curtis From owner-Big-Internet@munnari.OZ.AU Wed Nov 29 05:13:23 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id SA02846; Wed, 29 Nov 1995 05:13:23 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA23016; Wed, 29 Nov 1995 05:10:21 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA23005; Wed, 29 Nov 1995 05:10:02 +1100 Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id SA03520; Wed, 29 Nov 1995 05:09:47 +1100 (from cengiz@ISI.EDU) Received: from cat.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 28 Nov 1995 10:09:37 -0800 Date: Tue, 28 Nov 1995 10:10:00 -0800 Posted-Date: Tue, 28 Nov 1995 10:10:00 -0800 Message-Id: <199511281810.AA22074@cat.isi.edu> Received: by cat.isi.edu (5.65c/4.0.3-4) id ; Tue, 28 Nov 1995 10:10:00 -0800 From: Cengiz Alaettinoglu To: curtis@ans.net Cc: jon@branch.com (Jon Zeeff), freedman@netaxs.com, big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu Subject: Re: CIDR Aggregation Tool In-Reply-To: <199511280612.BAA04101@brookfield.ans.net> References: <199511280612.BAA04101@brookfield.ans.net> X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 822 1511 x219 X-Fax: +1 (310) 823 6714 Precedence: bulk Curtis Villamizar (curtis@ans.net) on November 28: > There is also plan > to use ANSPROXYAGGR and ANSPROXYCOMP but marking other peoples route > objects (the components of a proxy aggregate) with a community is a > hard thing to do if not in the maintainer list for the object. There are three proposals to enable marking other peoples' routes in the RPS WG: one based on ISP tags, one on route macros and one on attachment objects. Once one (or more) of these schemes are accepted and implemented, this may not be a difficult problem anymore. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz From owner-Big-Internet@munnari.OZ.AU Thu Nov 30 04:55:28 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id RA28849; Thu, 30 Nov 1995 04:55:28 +1100 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA24304; Thu, 30 Nov 1995 04:50:38 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA24287; Thu, 30 Nov 1995 04:33:28 +1100 Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id RA04716; Thu, 30 Nov 1995 04:33:25 +1100 (from cengiz@ISI.EDU) Received: from cat.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 29 Nov 1995 09:33:14 -0800 Date: Wed, 29 Nov 1995 09:33:33 -0800 Posted-Date: Wed, 29 Nov 1995 09:33:33 -0800 Message-Id: <199511291733.AA24758@cat.isi.edu> Received: by cat.isi.edu (5.65c/4.0.3-4) id ; Wed, 29 Nov 1995 09:33:33 -0800 From: Cengiz Alaettinoglu To: curtis@ans.net Cc: Avi Freedman , big-internet@munnari.OZ.AU, cidrd@iepg.org, nanog@merit.edu Subject: Re: CIDR Aggregation Tool In-Reply-To: <199511271850.NAA01164@brookfield.ans.net> References: <199511270400.XAA05234@netaxs.com> <199511271850.NAA01164@brookfield.ans.net> X-Organisation: USC / Information Sciences Institute X-Phone: +1 (310) 822 1511 x219 X-Fax: +1 (310) 823 6714 Precedence: bulk Curtis Villamizar (curtis@ans.net) on November 27: > [lots deleted] > Another way of estimating what can be aggregated is by determining > from how many places all of the components of an aggregate could be > heard in all backup situations. In some cases it might be reasonable > to drop some degree of alternate connectivity (fourth or fifth > preferred paths) and allow a number of holes (specifically aggregated > components). In principle this could be done algorithmically using > the IRR. In practice, you need to check with some of the parties > involved to make sure registered information (particialrly aut-num AS > peerings) are accurate beforehand. > > Using the IRR you (or we) can select candidates for aggregation and > then make sure the aggregation can really be asfely done. This is a > little different in than you estimate in that it the viewpoint is what > can we aggregate, rather than what might we see better aggregated in > the future. The bgp paths at major interconnects could form a useful > sanity check, making sure that AS paths do not conflict with IRR AS > peering information for any candidate for aggregation. > [lots deleted] Actually we are working on such a tool, that we call CIDR assistant. A pre-alpha release of this tool will be available before/during the IETF, and there will be a discussion of this tool in the RPS wg. This tool considers the topology and the policies registered in the IRR before suggesting potential aggregations. The amount of policy/topology that is considered is configurable. Cengiz -- Cengiz Alaettinoglu Information Sciences Institute (310) 822-1511 University of Southern California http://www.isi.edu/div7/people/cengiz