From owner-Big-Internet@munnari.OZ.AU Mon Dec 11 18:15:39 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id HA20102; Mon, 11 Dec 1995 18:15: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 SAA08449; Mon, 11 Dec 1995 18:15:03 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA08443; Mon, 11 Dec 1995 18:11:18 +1100 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id HA07741; Mon, 11 Dec 1995 18:10:46 +1100 (from deering@parc.xerox.com) Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14840(7)>; Sun, 10 Dec 1995 23:10:29 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Sun, 10 Dec 1995 23:10:20 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Routing wars pending? In-Reply-To: jnc's message of Wed, 15 Nov 95 11:40:03 -0800. <9511151940.AA10864@ginger.lcs.mit.edu> Date: Sun, 10 Dec 1995 23:10:06 PST Sender: Steve Deering From: Steve Deering Message-Id: <95Dec10.231020pst.75270@digit.parc.xerox.com> Precedence: bulk Noel, Finally getting a chance to catch up on some egregious recent email... In a message in response to Tom Bass on Nov. 15, you wrote: > I am damned tired of people rewriting history. Please cease and desist > before I become extremely upset. Later in that same message, you included this parenthetical comment: > (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.) I presume you were referring to me. If so, you are also guilty of rewriting history. I am not, and have never been, fundamentally opposed to splitting off the host identification function from the "locating" function. What I was and am opposed to is inventing a new numbering space *without* specifying the algorithms, protocols, databases, and management mechanisms required to actually get the desired functionality out of the separate numbering space, at an acceptable cost. What I heard was a number of people declaring that inventing a new ID space would solve some problems, but never actually specifying all the hard parts, that is, how do the new numbers work, how are they maintained, and how do they interact with the existing numbering spaces. (Actually, it's possible that kre did all that, but I just didn't understand it or think it was feasible to manage. Everyone else was just handwaving, as far as I could tell.) Furthermore, no two "identifier" advocates seemed to agree on what those identifiers would identify -- I heard impassioned arguments in favor of identifying interfaces, nodes, IP modules within nodes, transport modules within nodes, transport sessions (e.g., BSD sockets), processes, and probably some other identifiable entities I can't remember. In my opinion, there are two reasonable approaches: (1) fully design a system for using and maintaining separate identifier and locator numbering spaces, including the mechanisms by which renumbering, mobility, multihoming, etc. are transparently achieved. or (2) stay with our current architecture in which both the identifying and locating functions are overloaded on the single numbering space ("addresses"), and accept that some compromises may have to be made to satisfy both functions. The choice between the two approaches ought to be made by compared the costs (in resources, manageability, understandability, etc.) of approach (1) with the costs (e.g., reduced flexibility) of approach (2). That is, the simple existence of a design satisfying (1) would not be sufficient grounds to adopt it; it's problems and costs must be less onerous that the problems and costs it is supposed to fix. Which prompts me to coin a variation on your favorite aphorism: "Any problem in computer science can be transformed into a different set of problems by another level of indirection." - S. Deering Now, it is certainly true that I lean more towards approach (2) than approach (1), because my "hunches" tell me that approach (1) would end up creating more problems than it would solve, and because what I like better than inventing new protocols/systems/architectures is *not* inventing them, when they aren't necessary. (Apparently unlike most people, I recognize that good protocol design is Very Hard, something to be avoided if at all possible.) However, I have always been open to proposals for an approach (1) solution that looks reasonable. As recently as this past summer, I was involved in Lixia's addressing study group (reported on at the Stockholm IETF) in which one of the proposals under study was one from Dave Clark, which had separate identifying and locating address components (the high and low order halves of IPv6 addresses). I thought it looked promising, though we did uncover some problems that Dave had not anticipated. I don't consider that avenue of study to be terminated. (By the way, I thought I saw a message from you many months ago, basically withdrawing your EID proposal because of the costs of maintaining yet another numbering space. Am I misremembering that?) Now, about the renumbering jihad. Yes, I am upset about that. You find that ironic, as if the forced renumbering of IPv4 systems is a natural consequence of my criticism of some handwaving EID proposals for IPng. Yeah, that sure makes sense. Why I am upset about the renumbering approach currently being forced on Internet subscribers is that it is neither of the two reasonable approaches I listed above. That is, it is neither based on an architected design for a separate identifier space, nor is it based on a recognition of the overloaded nature of IP addresses and the resulting need to satisfy both functions of the addresses. Instead, the approach is to simply declare that one fundamental architectural property of the IP architecture -- that addresses may be used as relatively long-lived identifiers of hosts -- is no longer true, and damn the consequences. The providers have basically hijacked the address space (taking effective ownership of it, somehow supported by "instant best current practice" documents denouncing the concept of address ownership), and asserted that addresses are now simply locators. As a self-proclaimed Architect, you should recognize that simply removing a property of an architecture upon which much of its software depends, without designing a functioning alternative, is, um, unlikely to result in a working system. This action is supported by false claims that this is the only way to keep Internet routing working. For IPv4, at least one other approach is possible: the mapping approach most recently proposed by kre, and proposed a long time ago by Bob Hinden. (For IPv6, a couple of other approaches are also feasible: a properly architected separate identifier scheme, or coping with the overloaded addresses by using something like my metro-based addressing scheme. But that's obviously a ways off.) Yes, employing the mapping approach would require some work on the part of the default-free ISPs to get it deployed quickly, but that would be nothing compared to the unbounded amount of work that will have to be done to fix every use of IP addresses as identifiers. Hell, it is far from clear that all those uses can *be* fixed (e.g., how do you find your DNS server when its address might change at any time -- certainly not by looking it up in the DNS!). kre's scheme was dismissed out-of-hand by you and others as being too late, but what confidence do you have that the unbounded and unknowable set of problems arising from renumbering can be solved in time to avoid major failures for Internet users? Yakov likes to point out that an Internet that is not routable is not very useful. Well neither is an Internet in which the nodes are not identifiable. Both properties are essential, and both can be accomplished with a bounded, known amount of effort by both providers and customers. Instead, one property is being taken away for the convenience of the big ISPs, and the customers are simply being to told to Deal With It, with absolutely no assurance that It can actually be Dealt With. I think that those pushing this approach are being either very irresponsible or very naive, and I do indeed find that upsetting. And not a bit ironic. Oh, and if you were not referring to me in your parenthetical comment above, Never Mind. Steve From owner-Big-Internet@munnari.OZ.AU Tue Dec 12 00:55:24 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id NA22648; Tue, 12 Dec 1995 00:55: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 AAA08892; Tue, 12 Dec 1995 00:55:06 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA08860; Tue, 12 Dec 1995 00:36:54 +1100 Received: from dune.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id NA22438; Tue, 12 Dec 1995 00:36:49 +1100 (from bass@dune.silkroad.com) Received: (from bass@localhost) by dune.silkroad.com (8.6.12/8.6.9) id JAA00485; Mon, 11 Dec 1995 09:33:01 -0500 From: Tim Bass Message-Id: <199512111433.JAA00485@dune.silkroad.com> Subject: Re: Routing wars pending? To: deering@parc.xerox.com (Steve Deering) Date: Mon, 11 Dec 1995 09:33:01 -0500 (EST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <95Dec10.231020pst.75270@digit.parc.xerox.com> from "Steve Deering" at Dec 10, 95 11:10:06 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: 778 Precedence: bulk Steve, Seasons greetings. FYI: Tim Bass, not Tom :-) > > In a message in response to Tom Bass on Nov. 15, you wrote: > [ ... ] 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 Tue Dec 12 05:15:22 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id SA29178; Tue, 12 Dec 1995 05:15: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 FAA09131; Tue, 12 Dec 1995 05:15:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA09114; Tue, 12 Dec 1995 05:06:12 +1100 Received: from [192.20.239.133] by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id SA12619; Tue, 12 Dec 1995 05:05:59 +1100 (from tds@hoserve.ho.att.com) Received: from hoserve.ho.att.com by ig1.att.att.com id AA25249; Mon, 11 Dec 95 13:04:10 EST Received: from qpc1 (qpc1.ho.att.com) by hoserve.ho.att.com (4.1/EMS-1.1 SunOS) id AA02186; Mon, 11 Dec 95 13:07:10 EST Received: by qpc1 (4.1/EMS-1.1 SunOS) id AA02540; Mon, 11 Dec 95 13:09:25 EST Message-Id: <9512111809.AA02540@qpc1> From: tds@hoserve.ho.att.com (Tony DeSimone) To: Steve Deering Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: Routing wars pending? In-Reply-To: <95Dec10.231020pst.75270@digit.parc.xerox.com> References: <9511151940.AA10864@ginger.lcs.mit.edu> <95Dec10.231020pst.75270@digit.parc.xerox.com> Reply-To: Tony DeSimone Date: Mon, 11 Dec 95 13:09:23 EST Precedence: bulk > I am damned tired of people rewriting history. Please cease and desist > before I become extremely upset. Steve> I was and am opposed to is inventing a new numbering space Steve> *without* specifying the algorithms, protocols, databases, and Steve> management mechanisms required to actually get the desired Steve> functionality out of the separate numbering space, at an Steve> acceptable cost. And speaking of history, if this discussion were taking place some years back, the quote above would make a nice harangue against class D addresses. Tony From owner-Big-Internet@munnari.OZ.AU Tue Dec 12 07:15:21 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id UA10136; Tue, 12 Dec 1995 07:15: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 HAA09277; Tue, 12 Dec 1995 07:15:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA09262; Tue, 12 Dec 1995 07:04:20 +1100 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id UA06477; Tue, 12 Dec 1995 07:03:49 +1100 (from deering@parc.xerox.com) Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <17112(6)>; Mon, 11 Dec 1995 11:08:45 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 11 Dec 1995 11:00:49 -0800 To: Tony DeSimone Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Routing wars pending? In-Reply-To: tds's message of Mon, 11 Dec 95 10:09:23 -0800. <9512111809.AA02540@qpc1> Date: Mon, 11 Dec 1995 11:00:44 PST Sender: Steve Deering From: Steve Deering Message-Id: <95Dec11.110049pst.75270@digit.parc.xerox.com> Precedence: bulk Tony, > Steve> I was and am opposed to is inventing a new numbering space > Steve> *without* specifying the algorithms, protocols, databases, and > Steve> management mechanisms required to actually get the desired > Steve> functionality out of the separate numbering space, at an > Steve> acceptable cost. > > And speaking of history, if this discussion were taking place some > years back, the quote above would make a nice harangue against class D > addresses. What are you talking about? I wrote papers and a whole damn thesis on how to make multicast addresses work. I implemented two of the protocols to make them work (IGMP and DVMRP) and I provided the code for building the MBone, to demonstrate that they could work and solve real problems. And I have *not* committed the fate of the Internet's bread-and-butter applications to the success of multicast addresses, unlike those who would advocate that we separate unicast addressing and identification even though the supporting mechanisms for that have never been adequately specified, implemented, or demonstrated in a large prototype. Note that support for Class D addresses is still optional in an IP implementation; I don't think those advocating EIDs for IPng are proposing that they be optional for the first 5 or 10 years while we complete the design and prototyping effort to prove that they actually solve at least some of the problems they are claimed to solve, at a bearable cost. Steve From owner-Big-Internet@munnari.OZ.AU Tue Dec 12 09:55: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 WA27958; Tue, 12 Dec 1995 09:55: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 JAA09438; Tue, 12 Dec 1995 09:55:14 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09421; Tue, 12 Dec 1995 09:46:42 +1100 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id WA05489; Tue, 12 Dec 1995 09:46:39 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29419; Mon, 11 Dec 95 16:47:55 -0500 Date: Mon, 11 Dec 95 16:47:55 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9512112147.AA29419@ginger.lcs.mit.edu> To: deering@parc.xerox.com Subject: Re: Routing wars pending? Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Steve Deering >> I was and am opposed to is inventing a new numbering space >> *without* specifying the algorithms, protocols, databases, and >> management mechanisms required to actually get the desired >> functionality out of the separate numbering space, at an >> acceptable cost. > And speaking of history, if this discussion were taking place some > years back, the quote above would make a nice harangue against class D > addresses. What are you talking about? I wrote papers and a whole damn thesis on how to make multicast addresses work. I implemented two of the protocols to make them work (IGMP and DVMRP) and I provided the code for building the MBone, to demonstrate that they could work and solve real problems. I don't care what is added or not added to IPv6, and I have absolutely 0.00000 interest in trying to convince you to add support for endpoint identification to IPv6, so please don't take this message as any attempt on my part to have any influence on such topics, but I do have a reaction to your rebuttal. You may have done *some* stuff to make them useful, but it was by no means all the "algorithms, protocols, databases", etc required. If so, what on earth is the IDMR group (etc) doing? So I agree, the standard that you might be interpreted as holding up with your original comment (I'm not quite sure what you had in mind with the "algorithms, protocols, databases" etc comments) is perhaps one multicast might not have met. (Some of the people who had some reservations about the "how" of multicast had no doubt about the "why" of multicast, but I see this acceptance of the potential usefulness of new ideas is something that has passed from he scene...) And I have *not* committed the fate of the Internet's bread-and-butter applications to the success of multicast addresses "And I have not committed the fate of the ARPAnet's bread-and-buttter applications to the success of a radical new idea in how to do the transport layer". Steve, if that's your standard for the introduction of anything new, that it tinker around the edges, we might as well just retire right now. That does not mean I'm advocating a flag day, with a large working system you clearly have to have an interoperable migration, but I fail to see why adding endpoint identification is any less of a thoroughgoing upheaval than, say, defining a whole new internetwork layer. One wonders, in fact, what criteria you are using that OK's one and not the other; somehow I have doubts that it's the one you stated. those who would advocate that we separate unicast addressing and identification even though the supporting mechanisms for that have never been adequately specified, implemented, or demonstrated in a large prototype. Planck was right. Note that support for Class D addresses is still optional in an IP implementation Not as a practical matter. Certainly, it's basically impossible to build a useful router without them. I don't think those advocating EIDs for IPng are proposing that they be optional for the first 5 or 10 years while we complete the design and prototyping effort to prove that they actually solve at least some of the problems they are claimed to solve, at a bearable cost. Oh, goodie, do we get to apply the same standard to IPv6? Noel From owner-Big-Internet@munnari.OZ.AU Tue Dec 12 16:36:08 1995 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id FA31903; Tue, 12 Dec 1995 16:36: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 QAA09772; Tue, 12 Dec 1995 16:35:16 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA09757; Tue, 12 Dec 1995 16:24:29 +1100 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id FA13508; Tue, 12 Dec 1995 16:23:41 +1100 (from deering@parc.xerox.com) Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14786(4)>; Mon, 11 Dec 1995 21:23:30 PST Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 11 Dec 1995 21:23:25 -0800 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: Routing wars pending? In-Reply-To: jnc's message of Mon, 11 Dec 95 13:47:55 -0800. <9512112147.AA29419@ginger.lcs.mit.edu> Date: Mon, 11 Dec 1995 21:23:19 PST Sender: Steve Deering From: Steve Deering Message-Id: <95Dec11.212325pst.75270@digit.parc.xerox.com> Precedence: bulk Noel, > I don't care what is added or not added to IPv6, and I have absolutely > 0.00000 interest in trying to convince you to add support for endpoint > identification to IPv6... Understood. And I have exactly the same interest in entering into the architecture evolution vs. revolution debate with you again. We've done that before and we both know each other's position, I believe. So I'll skip over those parts of your message and just respond to your requests for clarification. > You may have done *some* stuff to make [class D addresses] useful, but it > was by no means all the "algorithms, protocols, databases", etc required. > If so, what on earth is the IDMR group (etc) doing? The specification of RFC-1112 immediately made class D addresses useful as a standard IP-level interface to link-level (e.g., Ethernet), single-hop multicasts so, for example, routers could use something more selective than broadcast to find and talk to their neighbors. That's why it's reasonable that support for multicast origination and reception (but not forwarding) has been a basic requirement for routers for some time now, as you pointed out -- router-to-router usage of multicast required very little technology or infrastructure, just an IP-to-link-layer address mapping algorithm and a set of procedures for IANA to assign and record well-known class D addresses to routing algorithms. The development and implementation of IGMP, DVMRP, and MOSPF made class D addresses additionally useful for campus-wide and private-internet-wide multicasts, such as local teleconferences, scientific data dissemination, and distributed interactive simulation, all of which are now regularly being done. The deployment of the MBone has demonstrated that class D addresses can be even more useful: they can be used for a certain number of world-wide teleconferences/meetings/entertainment events (that number being constrained by bandwidth at this point, not by missing multicast technology). And though we have not demonstrated it due to the aforementioned bandwidth limitations, I believe that the MBone technology is recognized as capable of supporting the multicast delivery aspects of "500 channels of TV", for an arbitrarily large audience, since there is no scaling limit in the size of group membership. The IDMR group is addressing still further uses, such as supporting a bazillion 3-person teleconferences, where the participants are widely separated in the topology. That's the part where there are still some open scaling issues. If those issues never get resolved, that will be unfortunate, but we will still have all the other uses that I listed above. Therefore I stand by my claim that all of the "algorithms, protocols, databases, etc." required to make IP multicast useful were developed and tested before committing the fate of any essential Internet services to those uses. (By the way, I certainly don't mean to give the impression that I alone satisfied all the requirements to make IP multicast useful. A large number of people have contributed to getting in place all the technology needed to make IP multicast fulfil all the uses it currently fulfils. One important multicast-support component in the "algorithms, protocols, and databases" department is Van's 'sd' tool, which provides a mechanism for dynamic allocation and reclamation of transient multicast addresses.) > I'm not quite sure what you had in mind with the "algorithms, protocols, > databases" etc comments Then let me try to explain. In the context of a proposal for a separate identifier space, it is likely to include specification of the storage, maintenance, and access procedures for one or more of the following new mapping databases: address (locator) to identifier identifier to address (locator) DNS name to identifier identifier to DNS name Are these new record-types in the DNS? in some other database? Are they maintained manually? dynamically? If dynamically, what is the update protocol? Is there a caching requirement? If so, what is the cache- coherency algorithm/protocol? If some of these questions have multiple possible answers, or need not be answered immediately to still get something useful out of the separate identifier space, which questions are those? What is the minimal mapping system required to get any benefit from separate identifiers? Then for *at least one* intended use of the separate identifiers, specify or demonstrate all the components needed to accomplish that use. For example, if you claim that a separate identifier space can be used to "solve" the IP mobility problem, explain exactly how they do would that. The explanation will include a description of how packets get delivered to a node whose locator keeps changing, possibly involving updating of the identifier-to- locator binding. Is that binding change accomplished by updating the mapping database? By protocol exchanges with a "home base" or with the correspondent node? If the latter, what is that protocol -- what are the fields in the packet; how is loss handled; what are the security measures required and how are the accomplished? Does everything work if both ends of a conversation are moving at the same time? In other words, I would expect to see something similar to the current mobile IP draft (or, even better, a demonstrated implementation of it), almost none of which has anything to do with whether or not mobile nodes are identified by separate identifiers or overloaded addresses, but all of which is required before claiming that the mobility problem is solved. Or pick renumbering or multihoming as your first use to be explained in detail, if one of those are easier. Now do you understand my criteria? It's easy to claim that some new architectural feature will be useful in solving a bunch of problems, but without a convincing explanation/demonstration of how it will solve at least one real problem, in a way that's clearly better than just using whatever features are already present in the existing architecture, why should anyone buy into the cost and complexity of adding that feature? Just saying that your "architectural sense" tells you so is not sufficient for changes of this magnitude, in my opinion. > I don't think those advocating EIDs for IPng are proposing that they be > optional for the first 5 or 10 years while we complete the design and > prototyping effort to prove that they actually solve at least some of the > problems they are claimed to solve, at a bearable cost. > > Oh, goodie, do we get to apply the same standard to IPv6? Yes, for those parts that are new architecture, which is basically just the Flow Label and Priority fields. Note that those features are called out in the IPv6 spec as effectively optional, and subject to change as we learn more about how to use them effectively. No other part of the IPv6 architecture depends on them actually working, so if it turns out that they don't work as well as we hope they will, we will have not trapped ourselves in a broken system -- we'll still have all the functionality we have in the current architecture, plus those improvements that did not require new architecture, such as the bigger address space, the better extensibility, the easier autoconfiguration (which is technology previously demonstrated in other internet stacks, such as XNS/IPX), etc. And if the Flow Label and/or Priority features do work out, great, we'll have an even better system. Steve From owner-Big-Internet@munnari.OZ.AU Sat Dec 23 00:20:07 1995 Subject: relative traffic snapshots Date: Fri, 22 Dec 1995 03:36:39 -0500 From: Sean Doran Message-Id: <95Dec22.033649-0000_est.20608+15@chops.icp.net> I'm apparently the first person in a while to turn on flow-switching on a Cisco 7505, and have done so for giggles on the one we have sitting between the ICM and SL LANs in Washington D.C. I figure that given that there has been some talk here and there (in end-to-end land and in TCP land) about the length of flows and how many flows one might see and the like, that a quickie snapshot from a busy but not *very* busy part of the Internet might be useful if dumped on big-internet. There are a couple caveats, notably that the averaging done in the accumulation of these stats is since the box started up, and that there are a number of things not flow-switched due to asymmetrical routing. Also, as noted, this is not the busiest piece of the Internet, and the past 12 hours are far from the busiest period of time on this particular (private) interconnect. The question I have, wearing an ICM researchy NSFish hat, is this: is gathering this kind of statistic worthwhile to anyone? In particular, is it worthwile enough to spend bunches of time playing with getting more information out of the flow-switching routing cache, or should we carry on just trying to make packets move through boxes as fast, as reliably and as stably as we can? Sean. - -- IP Flow Switching Cache, 16345 active flows, 39 inactive 7710715 added, 4367204 replaced, 2846226 timed out, 480940 invalidated statistics cleared 40210 seconds ago Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 43413 1.0 116 112 126.1 113.0 54.2 TCP-FTP 201597 5.0 10 98 51.9 22.6 58.5 TCP-FTPD 165525 4.1 111 376 458.2 48.5 57.5 TCP-WWW 4842729 120.4 13 296 1648.1 15.4 58.0 TCP-SMTP 700011 17.4 16 225 283.9 23.3 57.9 TCP-X 1259 0.0 72 223 2.2 64.8 51.9 TCP-other 944533 23.4 33 303 787.2 33.2 58.1 UDP-TFTP 9 0.0 1 79 0.0 0.0 59.8 UDP-other 450956 11.2 8 243 100.5 22.0 59.0 ICMP 320197 7.9 7 87 59.6 39.1 58.2 IGMP 21176 0.5 5 405 2.8 3.4 58.3 IPINIP 1038 0.0 232 146 6.0 124.8 52.1 GRE 1 0.0 2 1547 0.0 9.6 61.3 IP-other 2063 0.0 92 208 4.7 122.9 54.2 Total: 7694507 191.3 18 257 3531.8 0.5 0.1 From owner-Big-Internet Tue Dec 26 00:20:09 1995 From: kc@upeksa.sdsc.edu (k claffy) Message-Id: <199512250412.UAA07706@upeksa.sdsc.edu> Subject: Re: relative traffic snapshots Date: Sun, 24 Dec 1995 20:12:53 -0800 (PST) The question I have, wearing an ICM researchy NSFish hat, is this: is gathering this kind of statistic worthwhile to anyone? In particular, is it worthwile enough to spend bunches of time playing with getting more information out of the flow-switching routing cache, or should we carry on just trying to make packets move through boxes as fast, as reliably and as stably as we can? i dunno, Sean, assuming you could configure it by port on your own, would it have helped you find this sooner/less-painfully?: ------- Start of forwarded message ------- From: Sean Doran To: outage@sprint.net Subject: [SprintLink Outage] icm-dc-1 problem spotted and fixed Date: Mon, 25 Sep 1995 16:56:32 -0400 Sender: owner-outage@sprint.net Precedence: bulk Reply-To: insc@sprint.net After much staring at things and configuring ip accounting, we determined that a namesevrer downstream from a 64kbps ICM connectee was somehow triggering massive floods back towards its udp port 53. By massive I mean several Mbits/second from several sources. This caused icm-dc-1 lots of headache and heartburn as it tried to push all this traffic down the 64kbps bitpipe or throw it away as fast as possible. The folks responsible for the ICM connectee and the network in question have been alerted in email (a phone call will go out to them as well). In the mean while, since this was traffic all aimed at one address and it's a slow line, I've installed packet filters to prevent traffic between that nameserver and the rest of the world. This has made the traffic between this connectee and icm-dc-1 drop from a very full 64kbps in both directions, with 1.6 million dropped packets over 1 hour 40 minutes, to a nice quiescent 12kbps/16pps from them and practically nothing to them. ICM-DC-1 is now back from 100% CPU utilization to 27% CPU utilization, which is about normal. We regret that it took so long and it was so difficult to accurately pinpoint the cause, and look forward to a final resolution. Sean. ------- End of forwarded message ------- k - -- IP Flow Switching Cache, 16345 active flows, 39 inactive 7710715 added, 4367204 replaced, 2846226 timed out, 480940 invalidated statistics cleared 40210 seconds ago Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec) -------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow TCP-Telnet 43413 1.0 116 112 126.1 113.0 54.2 TCP-FTP 201597 5.0 10 98 51.9 22.6 58.5 TCP-FTPD 165525 4.1 111 376 458.2 48.5 57.5 TCP-WWW 4842729 120.4 13 296 1648.1 15.4 58.0 TCP-SMTP 700011 17.4 16 225 283.9 23.3 57.9 TCP-X 1259 0.0 72 223 2.2 64.8 51.9 TCP-other 944533 23.4 33 303 787.2 33.2 58.1 UDP-TFTP 9 0.0 1 79 0.0 0.0 59.8 UDP-other 450956 11.2 8 243 100.5 22.0 59.0 ICMP 320197 7.9 7 87 59.6 39.1 58.2 IGMP 21176 0.5 5 405 2.8 3.4 58.3 IPINIP 1038 0.0 232 146 6.0 124.8 52.1 GRE 1 0.0 2 1547 0.0 9.6 61.3 IP-other 2063 0.0 92 208 4.7 122.9 54.2 Total: 7694507 191.3 18 257 3531.8 0.5 0.1