From owner-Big-Internet@munnari.OZ.AU Sat Oct 16 23:31:27 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08805; Sat, 16 Oct 1993 23:29:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA01121; Sat, 16 Oct 1993 23:25:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA01097; Sat, 16 Oct 1993 23:19:54 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08415; Sat, 16 Oct 1993 23:19:04 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU From: Robert Elz Subject: Forwarded: IESG Handling of IPng documents Date: Sat, 16 Oct 1993 23:18:47 +1000 Message-Id: <10450.750777527@munnari.OZ.AU> Sender: kre@munnari.OZ.AU Since the last message to this list was my "I'm planning to change the list" message, and that was over two weeks ago, there have been several people who assume that either the list has broken, or that they've been deleted... Its not uncommon for Big-Internet to go quiet for a while, this time the silence just happened to be at a rather unfortunate time! Rather than just send a meaningless message of reassurance, I thought I should send Phill Gross's message on RFC's for IPng, even though most people on this list have probably seen it already from ietf-announce where it appeared. If nothing else, this will get it in the B-I archives. kre ps: the change I promised happened, if you get this message you're still on the list, and its working! ------- Forwarded Message From: Phill Gross Date: Thu, 14 Oct 93 11:29:25 -0400 To: IETF-Announce:; Subject: IESG Handling of IPng documents Message-Id: <9310141129.aa06113@IETF.CNRI.Reston.VA.US> The IESG has determined how documents from the IPng candidates will be treated when they are submitted to the IESG for publication as RFCs. 1. All IPng-related documents will be submitted for publication as RFCs in normal fashion; that is, as soon as the working group and the area directorate recommends that the IESG review them for publication. All IPng-related RFCs will be published with Experimental status. All IPng-related RFCs will remain in Experimental status until a single IPng is selected. 2. At some point, one IPng shall be selected, and it will be moved onto the standards track as defined in RFC1310 (or its successor). An Applicability Statement will be prepared to assign a status of "Recommended" as the Common IPng for Internet interoperability. 3. Once a "Common IPng" protocol has been selected, the other (former) IPng candidates will be treated in normal fashion. That is, they may eventually be moved to Historic status, or, if recommended by the working group and area directorate, they may be moved onto the standards track. However, because there can be only one level three protocol with a status of "Recommended as the Common IPng for Internet interoperability", an Applicability Statement must be prepared that clearly distinguishes between the subject protocol and the "Recommended Common IPng". Phill Gross IETF Chair ------- End of Forwarded Message From owner-Big-Internet@munnari.OZ.AU Tue Oct 19 12:13:58 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10251; Tue, 19 Oct 1993 02:14:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA03704; Tue, 19 Oct 1993 02:10:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA03678; Tue, 19 Oct 1993 01:57:35 +1000 Received: from access.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19712; Mon, 18 Oct 1993 15:38:10 +1000 (from tdarcos@access.digex.net) Received: by access.digex.net id AA08909 (5.67a8/IDA-1.4.4 for Internet ); Mon, 18 Oct 1993 01:36:45 -0400 Newsgroups: pub.tdarcos.private.mail Date: Mon, 18 Oct 1993 01:12:58 -0400 (EDT) From: "Tansin A. Darcos & Company" <0005066432@MCIMAIL.COM> Sender: "Tansin A. Darcos & Company" <0005066432@MCIMAIL.COM> Reply-To: "Tansin A. Darcos & Company" <0005066432@MCIMAIL.COM> Subject: Notice, Advisory and Disclaimer on Lists and Groups To: Not for mail Message-Id: <0119931018011200/0005066432NA1EM-c100000@MCIMAIL.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Notice, Advisory and Disclaimer: Be advised that when you subscribe to a Bitnet or in some cases, Internet mailing list, if the list is public, unless you say otherwise, anyone on Internet can find out who subscribes to that list. If the mailing software makes a mistake, it may hand someone the entire list of all subscribers even if your identity is not supposed to be disclosed. If you send ('post') a message (or a reply to an earlier message) to the mailing list's publication address (or post a message to a newsgroup), you are consenting to give your message (and with your Personal Name and E-Mail address) publicly to everyone who subscribes to it. This may include remailing services that "explode" a message, news group exchangers that post messages to or from Usenet News Groups to/from mailing lists, archivers that store messages, and even to processors that copy all public messages to CD-ROM. Rumor has it the U.S. National Security Agency has computers that monitor Internet mailing lists and news groups looking for "suspicious messages" as well. By posting a message to a list, the chances are good to excellent that your message will be stored permanently. Readers may copy your message to their own disk storage for reference or sites may archive messages posted to newsgroups and mailing lists, and some sites route Internet messages to printers or fax machines. Some people may repost your message to a different group even despite any request on your part or without your consent, if they think more (other) people should see it. While under most countries laws copyright exists from the moment of creation, assume anything you post on a news group or mailing list will be treated as if it is in the public domain. The managers and operators of a list or newsgroup have no capability to control this and by posting a message you are essentially consenting to having your message be around potentially forever. Be advised also that under both major international copyright treaties (Universal and Berne) someone may copy your message as part of theirs in order to quote it to respond to it; this is legal, is an integral part of the Internet culture, and there is no right under law you can have to prevent it even if you were to explicitly claim copyright on your message. Also, any claims or statements made in a message should be taken only as the personal opinion of the writer (without regard to the organization their messages come from) unless they explicitly declare this to be the position of a company or organization. If you have something personal to say in response to someone, be absolutely certain your message is sent only in private mail to them. You should assume that anything you write in a public message should be considered in the same light as if it was going to be printed on the front page of the {International Herald Tribune}, {New York Times} or {Jerusalem Post}. Please Feel Free to recirculate this notice. Paul Robinson, Tansin A. Darcos & Company October 18, 1993 From owner-Big-Internet@munnari.OZ.AU Thu Oct 21 07:26:35 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01595; Thu, 21 Oct 1993 07:26:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA06497; Thu, 21 Oct 1993 07:26:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA06477; Thu, 21 Oct 1993 07:13:17 +1000 From: mankin@cmf.nrl.navy.mil Received: from [134.207.7.68] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00965; Thu, 21 Oct 1993 07:08:56 +1000 (from mankin@cmf.nrl.navy.mil) Received: from radegond.cmf.nrl.navy.mil by picard.cmf.nrl.navy.mil (4.1/SMI-4.1) id AA24905; Wed, 20 Oct 93 17:06:15 EDT Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA07382; Wed, 20 Oct 93 17:06:13 EDT Date: Wed, 20 Oct 93 17:06:13 EDT Message-Id: <9310202106.AA07382@radegond.cmf.nrl.navy.mil> To: big-internet@munnari.OZ.AU, iab@cnri.reston.va.us, iesg@cnri.reston.va.us, ietf@cnri.reston.va.us Subject: The Real IPNG Area Report Hello, There was a snafu involving system administrators reconfiguring AFS while I sent this the other day, which resulted in a deformed report. Here is the report as it was intended. Apologies to those who get multiple copies, we want to make sure you hear from us! ---------------------------------------------------------------------------- IPNG Area Report October 1993 Scott Bradner and Allison Mankin, Co-Area Directors sob@harvard.edu mankin@cmf.nrl.navy.mil The IPNG Area is a temporary area in the IESG charged with managing the "IP the next generation" process. This is the first of area reports we will issue approximately monthly to keep the IETF informed about our progress. We will give a presentation describing the Area and the IPng process that we will be pursuing. This is scheduled for Monday morning of the Houston IETF. We will make the announcement of the directorate membership before then (soon), and we hope that many of the directorate members will be around during that plenary session. A 60 minute time period is reserved for questions and discussion following the presentation. Following the question session will be 10-minute updates on each of the IPng proposals. We invited a group of internetters to meet with us for an "advice meeting". This took place at SIGCOMM, in San Francisco, on September 17. The purpose of this IPNG meeting was to give us a kind of focus group, to let us discuss the IPNG area and the potential IPNG directorate informally and in a preliminary manner. The group that met was purposely not an early version of the IPNG directorate, nor was the meeting conducted in as structured a way as we expect of the directorate meetings, i.e. no minutes were taken. Several results came from this meeting: - The directorate should not include IESG or IAB members. - An IETF WG, Address Lifetime Expectations (ALE), was formed, whose mission is to quantify the lifetime of internet address space. Frank Solensky will chair. - Our generalized task is to develop a plan for the Internet future--it will have milestones at different times depending on the actual growth that occurs. The participants were: Scott Bradner, Harvard University Ross Callon, Wellfleet Jon Crowcroft, University College London John Curran, NEARnet Steve Deering, Xerox PARC Paul Francis, Bellcore Dave Katz, Cisco Tony Li, Cisco Allison Mankin, Naval Research Lab Greg Minshall, Novell Craig Partridge, BBN/Stanford University Frank Solensky, FTP Software Lixia Zhang, Xerox PARC The agenda we started with follows: draft agenda - IPng think session Sept. 17 1993 introductions review charge to IPng area additions to charge? mergermania SIPP... white papers < 10 page views from various people on IPng proposals & views of problems Noel, John Curran, TUBA, SIPP ... FYI for the community: IPng area procedures directorate meetings on and off record (minutes or not) telechats face to face at ietf special meetings mailing list public vs private archives standards sequence advance all to experimental when ready after decision, advance one onto track as recommended (move to required eventually?) after delay, others can move to elective parts can move to recommended if good AS directorate issues/suggestions how about IESG members? what WGs are needed? chair suggestions, warnings CIDR issues who knows BSD code? address assignment procedures var length subnets timeframe scope criteria decide consensus building/outreach factors to look at if the sky is not falling flow congestion accounting security advanced policies presentation at IETF in Nov. report to ietf mailing list? From owner-Big-Internet@munnari.OZ.AU Fri Oct 22 00:26:42 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09402; Fri, 22 Oct 1993 00:26:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA07347; Fri, 22 Oct 1993 00:26:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA07333; Fri, 22 Oct 1993 00:14:32 +1000 From: lazear@dockside.mitre.org Received: from gateway.mitre.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03235; Thu, 21 Oct 1993 21:44:57 +1000 (from lazear@dockside.mitre.org) Received: from dockside.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA06468; Thu, 21 Oct 93 07:44:24 -0400 Received: by dockside.mitre.org.mitre.org (4.1/SMI-4.1) id AA01443; Thu, 21 Oct 93 07:44:12 EDT Message-Id: <9310211144.AA01443@dockside.mitre.org.mitre.org> To: mankin@cmf.nrl.navy.mil Cc: big-internet@munnari.OZ.AU, iab@cnri.reston.va.us, iesg@cnri.reston.va.us, ietf@cnri.reston.va.us Subject: Re: The Real IPNG Area Report In-Reply-To: Your message of "Wed, 20 Oct 93 17:06:13 EDT." <9310202106.AA07382@radegond.cmf.nrl.navy.mil> Date: Thu, 21 Oct 93 07:43:45 -0400 radegond.cmf.nrl.navy.mil ^^^^^^^^ Will this never end!? :-) :-) See you in Houston! Walt From owner-Big-Internet@munnari.OZ.AU Fri Oct 22 05:31:15 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17073; Fri, 22 Oct 1993 04:27:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA07637; Fri, 22 Oct 1993 04:26:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA07623; Fri, 22 Oct 1993 04:19:32 +1000 Received: from sun2.nsfnet-relay.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14843; Fri, 22 Oct 1993 03:16:48 +1000 (from @aston.ac.uk:HAMMERE@bravo.aston.ac.uk) Message-Id: <9310211716.14843@munnari.oz.au> Via: uk.ac.aston; Thu, 21 Oct 1993 16:59:21 +0100 Received: from bravo.aston.ac.uk by email.aston.ac.uk with SMTP (PP) id <25830-0@email.aston.ac.uk>; Thu, 21 Oct 1993 16:58:21 +0100 Received: from BRAVO/MERCURY by bravo.aston.ac.uk (Mercury 1.1); Thu, 21 Oct 93 16:57:34 +00 To: lazear@dockside.mitre.org From: "E.HAMMER" Organization: Aston University Date: Thu, 21 Oct 1993 16:57:14 GMT+1 Subject: Re: The Real IPNG Area Report Cc: big-internet@munnari.OZ.AU, iab@CNRI.Reston.VA.US, iesg@CNRI.Reston.VA.US, ietf@CNRI.Reston.VA.US X-Pmrqc: 1 Return-Receipt-To: "E.HAMMER" Priority: urgent X-Mailer: WinPMail v1.0 (R1) > To: mankin@cmf.nrl.navy.mil > Cc: big-internet@munnari.oz.au, iab@CNRI.Reston.VA.US, iesg@CNRI.Reston.VA.US, > ietf@CNRI.Reston.VA.US > Subject: Re: The Real IPNG Area Report > Date: Thu, 21 Oct 93 07:43:45 -0400 > From: lazear@dockside.mitre.org > radegond.cmf.nrl.navy.mil > ^^^^^^^^ > > Will this never end!? :-) :-) > > See you in Houston! > > Walt > STOP Edwin Hammer Floor 12, Room B3, Dalton Tower, Aston Street, Aston Triangle, BIRMINGHAM. West Midlands. GB - B4 7EQ +44 (021) 6935278 From owner-Big-Internet@munnari.OZ.AU Fri Oct 22 15:27:04 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12773; Fri, 22 Oct 1993 15:27:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA08196; Fri, 22 Oct 1993 15:26:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA08179; Fri, 22 Oct 1993 15:17:00 +1000 From: peter@goshawk.lanl.gov Received: from mailhost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09093; Fri, 22 Oct 1993 14:03:14 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by mailhost.lanl.gov (4.1/1.2) id AA04442; Thu, 21 Oct 93 22:02:42 MDT Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA24358; Thu, 21 Oct 93 22:03:09 MDT Message-Id: <9310220403.AA24358@goshawk.lanl.gov> To: Ran Atkinson Cc: big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of Thu, 21 Oct 93 20:35:02 -0400. <9310220035.AA28789@itd.nrl.navy.mil> Date: Thu, 21 Oct 93 22:03:09 MST Ran, Thanks for the comments. >>> >>> TUBA out of the box at present does not support: >>> >>> (1) multicasting >>> (present in IPv4 and used on several continents >>> with the MBone; increasingly used in private IP >>> networks as well). SIP has this. The TUBA group has already stated that we can use the same architecture that SIP/IPv4 multicast uses for CLNP multicast. It is also the case that there is multicast work within the ISO community. We hope to work on this stuff in the OSIXTND effort, IESG permitting. An experimental implementation of class D style multicast is underway in the BSDI TUBA system as a proof of concept. We are also hoping to take advantage of work from the IDMR working group. >>> (2) efficient use of my low bandwidth (2400 baud) RF. >>> These are known to carry IPv4 traffic tolerably well. >>> SIP is actually more efficient than than IPv4 here. There is some work on compression wrt CLNP, but nothing has been written down as of yet. Hopefully we will see some stuff on this during Houston IETF. >>> (3) real-time flow IDs >>> Present in SIP. TUBA should be able to add them. >>> This is the one case where you do not say they are in use in your network. How would you use the 28 bits in the SIP flow ID? If it is possible to classify packets without flow ids would you still make them a requirement? Is it a given that the same functionality can not be done as an option? regards, peter From owner-Big-Internet@munnari.OZ.AU Fri Oct 22 15:32:31 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12942; Fri, 22 Oct 1993 15:32:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA08211; Fri, 22 Oct 1993 15:32:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA08182; Fri, 22 Oct 1993 15:24:26 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12652; Fri, 22 Oct 1993 15:24:23 +1000 (from jcurran@nic.near.net) Message-Id: <9310220524.12652@munnari.oz.au> Received: from nic.near.net by nic.near.net id aa08674; 22 Oct 93 1:24 EDT To: Ran Atkinson Cc: big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of Thu, 21 Oct 1993 20:35:02 -0400. <9310220035.AA28789@itd.nrl.navy.mil> Date: Fri, 22 Oct 1993 01:24:07 -0400 From: John Curran -------- ] From: Ran Atkinson ] To: ietf@isi.edu ] Subject: Peter's note on TUBA ] Date: Thu, 21 Oct 93 20:35:02 EDT ] ... ] (1) multicasting ] (present in IPv4 and used on several continents ] with the MBone; increasingly used in private IP ] networks as well). SIP has this. Hmm. Multicasting is still quite developmental (i.e. while the packet forwarding is mature, the routing is rather young) but I do agree that IPng candidates should do "at least as well as IPv4" in this area. Satisfactory? ] (2) efficient use of my low bandwidth (2400 baud) RF. ] These are known to carry IPv4 traffic tolerably well. ] SIP is actually more efficient than than IPv4 here. Agreed. Presuambly the TUBA folks will do a PPP w/hdr compression to handle this, but if it is not defined, then no partial credit... ] (3) real-time flow IDs ] Present in SIP. TUBA should be able to add them. Mumble... I will defer to folks with more experience, as I can not vouch for the need for flow IDs in the absence of experience with them. If they should prove valuable, then it would be nice if IPng candidates either included flow-ids or were sufficiently flexible to allow the addition of extremely efficient options. Seems to me that these are all reasonable concerns: we don't want to lose ground, we need IPng to work over a wide range of conditions, and we plan for potential changes in the packet forwarding model. /John From owner-Big-Internet@munnari.OZ.AU Fri Oct 22 16:56:42 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16123; Fri, 22 Oct 1993 16:56:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA08321; Fri, 22 Oct 1993 16:56:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA08307; Fri, 22 Oct 1993 16:52:26 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15972; Fri, 22 Oct 1993 16:52:18 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA18117 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Thu, 21 Oct 1993 23:52:09 -0700 Date: Thu, 21 Oct 1993 23:52:09 -0700 From: Tony Li Message-Id: <199310220652.AA18117@lager.cisco.com> To: jcurran@nic.near.net (John Curran) Cc: big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA ] (2) efficient use of my low bandwidth (2400 baud) RF. ] These are known to carry IPv4 traffic tolerably well. ] SIP is actually more efficient than than IPv4 here. Agreed. Presuambly the TUBA folks will do a PPP w/hdr compression to handle this, but if it is not defined, then no partial credit... John, I think that this is very dangerous. We are doing this complete decision based on "partial credit" in the sense that none of the proposals is being asked to put forth a _completely_ defined solution. Nor would such be tractable. It's taken us quite a while to get IPv4 to the point it's at, and it's going to take quite a while to get IPng that far too. We certainly don't have the personpower (Whew... almost slipped ;-) to provide complete definitions of all features for all contenders. Thus, we are in the situation where we are evaluating the contenders based on our understanding of how our current IPv4 technology can be "ported" to the contender. And just to keep our arguments at a minimum, where we can clearly see that such ports are possible, we assume such a port exists unless stated otherwise. I think that this will help us to focus on the real issues and allow us to bypass all of the common items on the checklist. Tony From owner-Big-Internet@munnari.OZ.AU Fri Oct 22 22:11:38 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26092; Fri, 22 Oct 1993 22:11:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA08595; Fri, 22 Oct 1993 22:11:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA08581; Fri, 22 Oct 1993 22:08:39 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26037; Fri, 22 Oct 1993 22:08:40 +1000 (from jcurran@nic.near.net) Message-Id: <9310221208.26037@munnari.oz.au> Received: from nic.near.net by nic.near.net id aa24234; 22 Oct 93 8:08 EDT To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of Thu, 21 Oct 1993 23:52:09 -0700. <199310220652.AA18117@lager.cisco.com> Date: Fri, 22 Oct 1993 08:08:33 -0400 From: John Curran -------- ] From: Tony Li ] Subject: Re: Peter's note on TUBA ] Date: Thu, 21 Oct 1993 23:52:09 -0700 ] ] Agreed. Presuambly the TUBA folks will do a PPP w/hdr compression ] to handle this, but if it is not defined, then no partial credit... ] ... ] Nor would such be tractable. It's taken us quite a while to get IPv4 ] to the point it's at, and it's going to take quite a while to get IPng ] that far too. We certainly don't have the personpower (Whew... almost ] slipped ;-) to provide complete definitions of all features for all ] contenders. Agreed. ] Thus, we are in the situation where we are evaluating the contenders ] based on our understanding of how our current IPv4 technology can be ] "ported" to the contender. We're in agreement here as well. To mandate a complete specification is not realistic. On the other hand, there needs to be at least a minimal effort to resolve reasonable concerns raised by the IETF community. In this case, Ran indicated that effecient use of slow speed links is desired. ] And just to keep our arguments at a ] minimum, where we can clearly see that such ports are possible, we ] assume such a port exists unless stated otherwise. Certainly but we need to record the fact that "TUBA will use PPP with a IPv4- like header compression" -or- "TUBA will have its own slow link protocol". It would only take a page or so to desribe the relevant changes in the former case, while a more complete desription is going to be needed in the case of a totally new approach. I am not comfortable with presuming that a particular issue will be handled by "the equivalent IPv4 protocol" without at least a minimal statement which discusses the changes. Without such analysis, it's quite possible that we will lull ourselves into false sense of security regarding the actual feasibility of extending a given IPv4 support protocol. /John From owner-Big-Internet@munnari.OZ.AU Sat Oct 23 00:27:19 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01258; Sat, 23 Oct 1993 00:27:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA08733; Sat, 23 Oct 1993 00:26:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA08719; Sat, 23 Oct 1993 00:22:35 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28966; Fri, 22 Oct 1993 23:28:17 +1000 (from lyman@BBN.COM) Message-Id: <9310221328.28966@munnari.oz.au> From: Lyman Chapin Subject: Re: Peter's note on TUBA To: jcurran@nic.near.net Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU In-Reply-To: <9310220524.12652@munnari.oz.au> Date: Fri, 22 Oct 93 09:08:05 EDT Mail-System-Version: >To: Ran Atkinson >Cc: big-internet@munnari.oz.au >Subject: Re: Peter's note on TUBA >Date: Fri, 22 Oct 1993 01:24:07 -0400 >From: John Curran > >-------- >] From: Ran Atkinson >] To: ietf@isi.edu >] Subject: Peter's note on TUBA >] Date: Thu, 21 Oct 93 20:35:02 EDT >] ... >] (1) multicasting >] (present in IPv4 and used on several continents >] with the MBone; increasingly used in private IP >] networks as well). SIP has this. > > Hmm. Multicasting is still quite developmental (i.e. while the > packet forwarding is mature, the routing is rather young) but I > do agree that IPng candidates should do "at least as well as IPv4" > in this area. Satisfactory? John, This made me wonder about how "well" the current IPv4 multicast is considered to work. My reading is that if MBONE-enhanced events became anything like a regular occurrence, the Internet would be in serious trouble. An interesting, albeit disruptive, experiment that can be run successfully by talented engineers if it is carefully set up ahead of time, yes; but is this really considered to be a generally useful capability by more than a small number of Internet users? - Lyman From owner-Big-Internet@munnari.OZ.AU Sat Oct 23 01:56:48 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04357; Sat, 23 Oct 1993 01:56:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA08831; Sat, 23 Oct 1993 01:56:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA08817; Sat, 23 Oct 1993 01:43:46 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01849; Sat, 23 Oct 1993 00:43:51 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9310221443.1849@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 22 Oct 1993 15:42:19 +0100 To: Lyman Chapin Cc: jcurran@nic.near.net, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of "Fri, 22 Oct 93 09:08:05 EDT." <9310221328.28966@munnari.oz.au> Date: Fri, 22 Oct 93 15:42:14 +0100 From: Jon Crowcroft >This made me wonder about how "well" the current IPv4 multicast is >considered to work. My reading is that if MBONE-enhanced events >became anything like a regular occurrence, the Internet would be >in serious trouble. An interesting, albeit disruptive, experiment >that can be run successfully by talented engineers if it is carefully >set up ahead of time, yes; but is this really considered to be a >generally useful capability by more than a small number of Internet >users? Lyman the answer to your last question is simply: Yes. we are funding specific multicvast support for the SUperJANET network in the UK, because multicast multimedia distribution is necessary to stop multiple unicast multimedia feeds breaking the network MORE . the experts on multicast have a good handle on the scalability arguments, and even the WORST mutlciast is a lot less bad than multiple unicast problems seen on the mbone would be as nothing to problems seen on the Internet if the users got going without it. jon p.s. if you want a list of users, we have Specialist Teaching Weather Analysts Global Mapping Medical Image Dissemination HEP Collaborations all running NOW. if IPng doesnt do multicast from day 1, these users WON'T adopt it. From owner-Big-Internet@munnari.OZ.AU Sat Oct 23 04:26:57 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09328; Sat, 23 Oct 1993 04:26:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA09047; Sat, 23 Oct 1993 04:26:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA09028; Sat, 23 Oct 1993 04:14:44 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04213; Sat, 23 Oct 1993 01:51:52 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA08009; Fri, 22 Oct 1993 16:53:30 +0100 Message-Id: <199310221553.AA08009@mitsou.inria.fr> To: Lyman Chapin Cc: jcurran@nic.near.net, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of "Fri, 22 Oct 93 09:08:05 EDT." <9310221328.28966@munnari.oz.au> Date: Fri, 22 Oct 93 16:53:29 +0100 From: Christian Huitema Lyman, Current MBONE events stress 2 new functionalities of the net, i.e. multicast and real time. As you note, the MBONE is still largely an experiment, but the understanding and the specifcation of both multicast and realtime is progressing arpidly, largely as a consequence of being stressed. - For multicast, we can consider that the "host" and the "IGP" part are reasonably stable now. SGMP is quite stable at the host level, and we dont see major reason to change it in the short term. Either the combination of DVMRP + "broadcast and prune" or MOSPF provide satisfactory solution for "small" or "private" network. The "EGP" part is on the other end not so stable -- it still relies on the "broadcast and prune" strategy, which is arguably inadequate for a sparse groups. Several solutions are being studied in the research groups. - For "real time", we are progressing fast towards the implementation of "end to end" solutions -- without modifying IP. We will have to deploy better "flow separation" algorithms in the Internet gateways (e.g. fair queuing) and will also have to implement some form of resource reservation (e.g. RSVP). The end to end solutions, alone, would probably suffice in "protecting the Internet". The internetwork solutions are needed for a better "quality of service". It is fair to assert that most of the experience on these topics has been gained on IP, and that some of the algorithms rely on IP features such as protocol encapsulation or test of patterns under bit mask. These would not necessarily fit well in CLNP due to either a large overhead (one hesitate to duplicate the CLNP header through encapsulation) or variable length formats. At the very least, the CLNP team will need more than a handwave to claim these problems solved! Christian Huitema From owner-Big-Internet@munnari.OZ.AU Sat Oct 23 06:08:34 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10395; Sat, 23 Oct 1993 04:57:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA09091; Sat, 23 Oct 1993 04:56:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA09077; Sat, 23 Oct 1993 04:52:19 +1000 Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10244; Sat, 23 Oct 1993 04:52:10 +1000 (from hinden@jurassic.Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15133; Fri, 22 Oct 93 11:51:58 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA28529; Fri, 22 Oct 93 11:51:43 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA24688; Fri, 22 Oct 1993 11:51:53 +0800 Date: Fri, 22 Oct 1993 11:51:53 +0800 From: hinden@jurassic.Eng.Sun.COM (Bob Hinden) Message-Id: <9310221851.AA24688@jurassic.Eng.Sun.COM> To: Lyman Chapin Cc: jcurran@nic.near.net, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU In-Reply-To: <9310221328.28966@munnari.oz.au> Subject: Re: Peter's note on TUBA Lyman, > This made me wonder about how "well" the current IPv4 multicast is > considered to work. My reading is that if MBONE-enhanced events > became anything like a regular occurrence, the Internet would be > in serious trouble. An interesting, albeit disruptive, experiment > that can be run successfully by talented engineers if it is carefully > set up ahead of time, yes; but is this really considered to be a > generally useful capability by more than a small number of Internet > users? I think you are assuming the only current use of the multicast technology is across the global internet. Remember that most of the deployment of IP technology is inside of organizations. Today Sun and a number of other companies ship IP multicast in their products. We use IP multicast inside of Sun (we have a very large internet of our own) for a variety of purposes (conferencing, training, etc). We use it as part of our business. The current IP multicast technology works today and scales quite well in this environment. Bob From owner-Big-Internet@munnari.OZ.AU Sat Oct 23 07:57:23 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17093; Sat, 23 Oct 1993 07:57:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA09259; Sat, 23 Oct 1993 07:56:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA09245; Sat, 23 Oct 1993 07:42:33 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16570; Sat, 23 Oct 1993 07:42:35 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA10556; Fri, 22 Oct 93 17:32:28 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA02208; Fri, 22 Oct 93 17:45:11 EDT Date: Fri, 22 Oct 93 17:45:11 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9310222145.AA02208@cabernet.wellfleet> To: jcurran@nic.near.net, tli@cisco.com Subject: Re: Peter's note on TUBA Cc: big-internet@munnari.OZ.AU ... We are doing this complete decision based on "partial credit" in the sense that none of the proposals is being asked to put forth a _completely_ defined solution. Nor would such be tractable. It's taken us quite a while to get IPv4 to the point it's at, and it's going to take quite a while to get IPng that far too. We certainly don't have the personpower (Whew... almost slipped ;-) to provide complete definitions of all features for all contenders. Thus, we are in the situation where we are evaluating the contenders based on our understanding of how our current IPv4 technology can be "ported" to the contender. And just to keep our arguments at a minimum, where we can clearly see that such ports are possible, we assume such a port exists unless stated otherwise. I think that this will help us to focus on the real issues and allow us to bypass all of the common items on the checklist. Tony As usual, I agree with Tony on this. None of the current IPng proposals have a complete and satisfactory solutions to all of the IPng requirements. I would prefer to see a solution which does solve all of these requirements, but at a minimum would be very concerned if a winning proposal does not provide realistic and deployable solutions to what I consider to be the two most difficult problems: A migration/transition scheme, and an addressing and scaling plan. I think that these are the two most critical problems, and the only two problems where TUBA has a considerable advantage (and where the TUBA proponents have been too polite, in privately pointing out problems to the SIP folks without making a public issue out of them). Adding IP-style multicast and header compression to CLNP is a rather straightforward effort. Similarly resource reservation, while it has consequences on the "fast path" forwarding within routers, is not significantly harder with one protocol than with another (I happen to be a big fan of adding powerful resource reservation capabilities to routers). I recognize that there is no public consensus on what constitutes a realistic addressing plan, nor on what transition scheme is the most deployable. However, I feel very worried seeing the Internet appearing to prefer a solution to these two issues which most of the major router vendors and some of the public service providers feel is not going to work. Ross From owner-Big-Internet@munnari.OZ.AU Sat Oct 23 09:12:06 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19685; Sat, 23 Oct 1993 09:12:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA09343; Sat, 23 Oct 1993 09:11:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA09329; Sat, 23 Oct 1993 09:00:43 +1000 From: peter@goshawk.lanl.gov Received: from mailhost.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14809; Sat, 23 Oct 1993 06:55:55 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by mailhost.lanl.gov (4.1/1.2) id AA09195; Fri, 22 Oct 93 14:55:18 MDT Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA01951; Fri, 22 Oct 93 14:55:46 MDT Message-Id: <9310222055.AA01951@goshawk.lanl.gov> To: Christian Huitema Cc: Lyman Chapin , jcurran@nic.near.net, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of Fri, 22 Oct 93 16:53:29 +0100. <199310221553.AA08009@mitsou.inria.fr> Date: Fri, 22 Oct 93 14:55:45 MST >>> It is fair to assert that most of the experience on these topics has been >>> gained on IP, yes >>> and that some of the algorithms rely on IP features such as >>> protocol encapsulation or test of patterns under bit mask. I don't think these are unique to IP >>> These would not >>> necessarily fit well in CLNP due to either a large overhead (one hesitate to >>> duplicate the CLNP header through encapsulation) or variable length formats. I would think the coding of a multicast group address in an NSAP could be as short as the coding for one in SIP, one advantage of having variable length addresses is that you can size them by need. Do you see any reason why they would need to be larger than 64 bits? I also wasn't thinking multicast in IPng should require encapsulation, do you see the current status quo being the target we should keep in mind for IPng? Hopefully the IPng infrastructure will support native switching of multicast addressed packets. >>> At the very least, the CLNP team will need more than a handwave to claim these >>> problems solved! I don't think anyone has claimed (or even handwaved) that the multicast problem for CLNP has been solved. What I did send out was a status report on what is going on. If you feel what we are proposing to do will not work, I would like to hear what the problems are. cheers, peter From owner-Big-Internet@munnari.OZ.AU Sat Oct 23 09:26:45 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20217; Sat, 23 Oct 1993 09:26:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA09373; Sat, 23 Oct 1993 09:26:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA09359; Sat, 23 Oct 1993 09:22:29 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19471; Sat, 23 Oct 1993 09:06:10 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Fri, 22 Oct 1993 16:05:55 -0700 Date: Fri, 22 Oct 1993 16:05:55 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310222305.AA15007@zephyr.isi.edu> To: rcallon@wellfleet.com Subject: A big fan... Cc: big-internet@munnari.OZ.AU *> Adding IP-style multicast and header compression to CLNP is a *> rather straightforward effort. Similarly resource reservation, *> while it has consequences on the "fast path" forwarding within *> routers, is not significantly harder with one protocol than *> with another (I happen to be a big fan of adding powerful *> resource reservation capabilities to routers). *> A big fan, eh? Boy, have we got the BOF for you! Bob Braden From owner-Big-Internet@munnari.OZ.AU Mon Oct 25 20:28:46 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11558; Mon, 25 Oct 1993 19:28:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA12208; Mon, 25 Oct 1993 19:26:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA12194; Mon, 25 Oct 1993 19:17:41 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07094; Mon, 25 Oct 1993 17:46:20 +1000 (from eesun!iitk.ernet.in!vikas@ern.doe.ernet.in) Received: from spool.uu.net (via LOCALHOST) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AB00366; Mon, 25 Oct 93 03:46:03 -0400 Received: from sangam.UUCP by uucp5.uu.net with UUCP/RMAIL (queueing-rmail) id 034420.3922; Mon, 25 Oct 1993 03:44:20 EDT Received: from eesun!iitk.ernet.in by sangam.ncst.ernet.in (4.1/SMI-4.2-ERNET-relay) with UUCP id AA13761; Mon, 25 Oct 93 13:07:55+0530 Received: from eesun.UUCP by ern.doe.ernet.in (4.1/SMI-4.1-MHS-7.0) id AA01216; Mon, 25 Oct 93 13:04:33+0530 From: Received: by iitk.ernet.in (4.1/SMI-4.1) id AA07980; Mon, 25 Oct 93 12:55:10 IST From: vikas@iitk.ernet.in (Vikas Sinha) Message-Id: <9310250725.AA07980@iitk.ernet.in> Subject: Subscription.. To: big-internet@munnari.OZ.AU Date: Mon, 25 Oct 93 12:55:10 GMT+5:30 Hullo! I would appreciate if you could include me in your mailing list. Sincerely, Vikas.. ______________________________________________________________________ Vikas K Sinha e-mail: vikas@iitk.ernet.in Research Engineer Voice : +91-512-250559 Advanced Center for Electronic Systems +91-512-250697 Indian Institute of Technology, Kanpur FAX : +91-512-250260 Kanpur 208016 (INDIA) ________________________________________________________________ If a little knowledge is dangerous, where is a man [or woman] who has so much as to be out of danger? --Thomas Henry Huxley ----------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 04:57:20 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02391; Tue, 26 Oct 1993 04:57:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA12822; Tue, 26 Oct 1993 04:56:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA12804; Tue, 26 Oct 1993 04:45:54 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01894; Tue, 26 Oct 1993 04:46:03 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from Mordor.Stanford.EDU by shark.mel.dit.csiro.au with SMTP id AA18028 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 26 Oct 1993 04:46:18 +1000 Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA14961; Mon, 25 Oct 93 11:45:34 -0700 Message-Id: <9310251845.AA14961@Mordor.Stanford.EDU> To: Lyman Chapin Cc: hinden@jurassic.eng.sun.com, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Peter's note on TUBA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 25 Oct 93 11:10:27 -0400. <9310251611.26497@munnari.oz.au> Date: Mon, 25 Oct 93 11:45:34 -0700 From: Dave Crocker X-Mts: smtp Lyman, ---- Included message: My concern was about the use of multicast as a general feature of the global Internet. I'd like to see the target for IPng set higher than "as good as IPv4 multicast" (although that might be a reasonabl e acceptability threshhold). I suspect that a major source of confusion and tension about the IPng debate has been classic feature-creep. We began by needing to solve a constrained problem. We then got seduced (...Well, as long as the hood is up, let's take a look at...). To be fair, there also is the legitimate observation that we are not *allowed* to modify anything under the hood very often, so we'd better consider what we can do whenever we *do* get that chance. But it is not clear to me that we are distinguishing must from should from would-be-nice. d/ From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 04:59:15 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02419; Tue, 26 Oct 1993 04:59:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA12841; Tue, 26 Oct 1993 04:58:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA12801; Tue, 26 Oct 1993 04:42:53 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01781; Tue, 26 Oct 1993 04:42:58 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Mon, 25 Oct 1993 11:42:38 -0700 Date: Mon, 25 Oct 1993 11:42:38 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310251842.AA20220@zephyr.isi.edu> To: Lyman@BBN.COM Subject: IPv4 multicast scaling Cc: big-internet@munnari.OZ.AU *> From owner-Big-Internet@munnari.OZ.AU Mon Oct 25 11:34:13 1993 *> From: Lyman Chapin *> Subject: Re: Peter's note on TUBA *> To: J.Crowcroft@cs.ucl.ac.uk *> Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.oz.au, *> jcurran@nic.near.net, lyman@BBN.COM *> Date: Mon, 25 Oct 93 10:59:31 EDT *> Mail-System-Version: *> Content-Length: 1996 *> X-Lines: 54 *> *> Jon, *> *> My point was not that I didn't think multicast was very useful, but *> that I didn't think the current IPv4 support for multicast would scale *> well enough to become a regular feature of life on the Internet. Yes, *> it's much better than multiple unicast, but what I see is a strong *> argument for better multicast support in IPng, not an argument that *> IPv4 multicast is just fine the way it is (and therefore is something *> to which IPng candidates should aspire). *> *> - Lyman Lyman, When you say that IPv4 multicast will not scale, you are referring to the current generation of multicast routing protocols, right? Would you consider CBT or ESL to be IPv4 multicast? They are addressing the scaling issues, I believe. Bob Braden From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 05:57:17 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04892; Tue, 26 Oct 1993 05:57:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA12948; Tue, 26 Oct 1993 05:56:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA12930; Tue, 26 Oct 1993 05:47:48 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04446; Tue, 26 Oct 1993 05:47:55 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA15545; Mon, 25 Oct 93 12:47:51 -0700 Message-Id: <9310251947.AA15545@Mordor.Stanford.EDU> To: braden@ISI.EDU (Bob Braden) Cc: big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 25 Oct 93 12:20:06 -0700. <199310251920.AA20864@zephyr.isi.edu> Date: Mon, 25 Oct 93 12:47:50 -0700 From: Dave Crocker X-Mts: smtp Bob , ---- Included message: In the case of multicast, it is not our features that are creeping (well, actually, deployment of IPv4 multicast is creeping forward, it seems), but the world that is enlarging its demands. Agreed. We ignore those demands at our peril. No suggestion to ignore the issue. Merely to distinguish futures from present and immediate, clear futures from those of more general -- and possibly even researchy -- tone. d/ From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 06:27:19 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05910; Tue, 26 Oct 1993 06:27:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA13024; Tue, 26 Oct 1993 06:26:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA12992; Tue, 26 Oct 1993 06:14:17 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05435; Tue, 26 Oct 1993 06:14:15 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA23016; Mon, 25 Oct 93 16:03:16 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA02900; Mon, 25 Oct 93 16:16:12 EDT Date: Mon, 25 Oct 93 16:16:12 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9310252016.AA02900@cabernet.wellfleet> To: big-internet@munnari.OZ.AU, whyman@mwassocs.demon.co.uk Subject: Re: Peter's note on TUBA Cc: rcallon@wellfleet.com Not surprisingly, the Civil Aviation Community has the same requirement for CLNP compression over low bandwidth RF networks. We went ahead and developed out own specification which should gain approval in its first stage to becoming an ICAO standard next month. There are at least two (and I think a third) implementations under way. Tony; Is this the same CLNP compression that is defined in the CDPD specification? Ross From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 06:33:08 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01171; Tue, 26 Oct 1993 04:27:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA12728; Tue, 26 Oct 1993 04:26:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA12711; Tue, 26 Oct 1993 04:19:47 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27910; Tue, 26 Oct 1993 02:47:24 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9310251647.27910@munnari.oz.au> Received: from danger.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 25 Oct 1993 16:46:38 +0000 To: Lyman Chapin Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU, jcurran@nic.near.net Subject: Re: Peter's note on TUBA In-Reply-To: Your message of "Mon, 25 Oct 93 10:59:31 EDT." Date: Mon, 25 Oct 93 16:46:29 +0000 From: Jon Crowcroft >My point was not that I didn't think multicast was very useful, but >that I didn't think the current IPv4 support for multicast would scale >well enough to become a regular feature of life on the Internet. my point is that the class D host group stuff WILL scale to very very large multicast - the only requirement is to provide sscalable routing protocols, and we believe (in the IDMR working group) that amongs the SRPM, ESL and ESL-DM and CBT proposals, we have something that will scale very very large - at least as well as most of the unicast routing protocols around... >it's much better than multiple unicast, but what I see is a strong >argument for better multicast support in IPng, not an argument that >IPv4 multicast is just fine the way it is (and therefore is something >to which IPng candidates should aspire). the clean-ish independence of packet format/addressing and routing protocols are one of the inherently positive things about IP at all - having said that, if someone can specifiy NSAP group address structure, IGMP for CLNP and an initial multicast IGP (e.g. a version of DVMRP) then they will be nearly level with the IPv4 multicast work unfortuantely, they'd still be some wqay behind the IPng multicast work in SIPP :-) cheers jon From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 06:39:24 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01340; Tue, 26 Oct 1993 04:29:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA12743; Tue, 26 Oct 1993 04:29:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA12705; Tue, 26 Oct 1993 04:18:02 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26497; Tue, 26 Oct 1993 02:11:59 +1000 (from lyman@BBN.COM) Message-Id: <9310251611.26497@munnari.oz.au> From: Lyman Chapin Subject: Re: Peter's note on TUBA To: hinden@jurassic.eng.sun.com Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU, jcurran@nic.near.net, lyman@BBN.COM In-Reply-To: <9310221851.AA24688@jurassic.Eng.Sun.COM> Date: Mon, 25 Oct 93 11:10:27 EDT Mail-System-Version: >Date: Fri, 22 Oct 1993 11:51:53 +0800 >From: hinden@jurassic.Eng.Sun.COM (Bob Hinden) >To: Lyman Chapin >Cc: jcurran@nic.near.net, atkinson@itd.nrl.navy.mil, > big-internet@munnari.oz.au >Subject: Re: Peter's note on TUBA > >Lyman, > > > This made me wonder about how "well" the current IPv4 multicast is > > considered to work. My reading is that if MBONE-enhanced events > > became anything like a regular occurrence, the Internet would be > > in serious trouble. An interesting, albeit disruptive, experiment > > that can be run successfully by talented engineers if it is carefully > > set up ahead of time, yes; but is this really considered to be a > > generally useful capability by more than a small number of Internet > > users? > >I think you are assuming the only current use of the multicast technology >is across the global internet. Remember that most of the deployment of >IP technology is inside of organizations. Today Sun and a number of >other companies ship IP multicast in their products. We use IP multicast >inside of Sun (we have a very large internet of our own) for a variety of >purposes (conferencing, training, etc). We use it as part of our >business. The current IP multicast technology works today and scales >quite well in this environment. Bob, You're right, and this makes sense - I've heard from several people who pointed out why the current (IPv4) multicast capability is useful & "must have" on their networks. My concern was about the use of multicast as a general feature of the global Internet. I'd like to see the target for IPng set higher than "as good as IPv4 multicast" (although that might be a reasonable acceptability threshhold). - Lyman > >Bob > From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 06:40:37 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01396; Tue, 26 Oct 1993 04:31:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA12758; Tue, 26 Oct 1993 04:30:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA12707; Tue, 26 Oct 1993 04:18:18 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26487; Tue, 26 Oct 1993 02:11:20 +1000 (from lyman@BBN.COM) Message-Id: <9310251611.26487@munnari.oz.au> From: Lyman Chapin Subject: Re: Peter's note on TUBA To: J.Crowcroft@cs.ucl.ac.uk Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU, jcurran@nic.near.net, lyman@BBN.COM Date: Mon, 25 Oct 93 10:59:31 EDT Mail-System-Version: Jon, My point was not that I didn't think multicast was very useful, but that I didn't think the current IPv4 support for multicast would scale well enough to become a regular feature of life on the Internet. Yes, it's much better than multiple unicast, but what I see is a strong argument for better multicast support in IPng, not an argument that IPv4 multicast is just fine the way it is (and therefore is something to which IPng candidates should aspire). - Lyman >To: Lyman Chapin >cc: jcurran@nic.near.net, atkinson@itd.nrl.navy.mil, big-internet@munnari.oz.au >Subject: Re: Peter's note on TUBA >Date: Fri, 22 Oct 93 15:42:14 +0100 >From: Jon Crowcroft > > > >This made me wonder about how "well" the current IPv4 multicast is > >considered to work. My reading is that if MBONE-enhanced events > >became anything like a regular occurrence, the Internet would be > >in serious trouble. An interesting, albeit disruptive, experiment > >that can be run successfully by talented engineers if it is carefully > >set up ahead of time, yes; but is this really considered to be a > >generally useful capability by more than a small number of Internet > >users? > > Lyman > >the answer to your last question is simply: Yes. > >we are funding specific multicvast support for the SUperJANET network >in the UK, because multicast multimedia distribution is necessary to >stop multiple unicast multimedia feeds breaking the network MORE . > >the experts on multicast have a good handle on the scalability >arguments, and even the WORST mutlciast is a lot less bad than >multiple unicast > >problems seen on the mbone would be as nothing to problems seen on the >Internet if the users got going without it. > > jon >p.s. if you want a list of users, we have > >Specialist Teaching >Weather Analysts >Global Mapping >Medical Image Dissemination >HEP Collaborations > >all running NOW. if IPng doesnt do multicast from day 1, these users >WON'T adopt it. From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 06:46:25 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01454; Tue, 26 Oct 1993 04:33:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA12773; Tue, 26 Oct 1993 04:32:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA12725; Tue, 26 Oct 1993 04:26:20 +1000 Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29385; Tue, 26 Oct 1993 03:32:12 +1000 (from whyman@mwassocs.demon.co.uk) Date: Mon, 25 Oct 1993 17:30:06 BST Message-Id: <9310251730.aa4911@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: big-internet@munnari.OZ.AU (Big Internet Maillist) Subject: Re: Peter's note on TUBA X-Mailer: Cinetic Mail Manager V2.1 >From: Ran Atkinson >Message-Id: <9310220035.AA28789@itd.nrl.navy.mil> >To: ietf@isi.edu >Subject: Peter's note on TUBA > >Peter, > >TUBA out of the box at present does not support: > > (1) multicasting > (present in IPv4 and used on several continents > with the MBone; increasingly used in private IP > networks as well). SIP has this. > (2) efficient use of my low bandwidth (2400 baud) RF. > These are known to carry IPv4 traffic tolerably well. > SIP is actually more efficient than than IPv4 here. > Not surprisingly, the Civil Aviation Community has the same requirement for CLNP compression over low bandwidth RF networks. We went ahead and developed out own specification which should gain approval in its first stage to becoming an ICAO standard next month. There are at least two (and I think a third) implementations under way. The idea is simple enough and replaces the existing CLNP header by a "compressed" header that can be as small as 5 octets (no segmentation) and is at most 11 octets (segmented). The algorithm can compress any CLNP packet except for those that contain source routing or route recording options. The compressed header contains the segmentation part, PDU priority and QoS bits (if present in the orignal PDU), in as few bits as possible, and replaces the source and destination NSAP Addresses with a single "local reference" which is encoded as one octet (value range 0..127), or two octets (value range 128..32747). The algorithm is specified to work over a connection mode subnetwork (e.g. X.25). The first time that a packet is sent between a given pair of NSAPs over the subnetwork connection, a previously unused local reference is added to the packet header (each side has a range of references from which it is permitted to assign such references). This defines the local reference as being a reference to the NSAP Address pair in the same packet header. From then on either side may compress a packet between the same pair of NSAP Addresses using that local reference in the compressed header to imply the same NSAP Address pair as in the defining packet. The local reference may be used for packets travelling in the opposite direction as well, although obviously the source and destination semantics are reversed. The full specification includes error reporting procedures and procedures to re- use a local reference for a different NSAP Address Pair. I would not claim the existence of such an algorithm to be a particular advantage of CLNP as the same technique can be used with any similar protocol. However, if it is believed to be useful to TUBA, I believe that I can make the full specification available. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 06:52:24 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03487; Tue, 26 Oct 1993 05:27:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA12891; Tue, 26 Oct 1993 05:26:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA12875; Tue, 26 Oct 1993 05:20:21 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03109; Tue, 26 Oct 1993 05:20:27 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Mon, 25 Oct 1993 12:20:06 -0700 Date: Mon, 25 Oct 1993 12:20:06 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199310251920.AA20864@zephyr.isi.edu> To: Lyman@BBN.COM, dcrocker@Mordor.Stanford.EDU Subject: Re: Peter's note on TUBA Cc: hinden@jurassic.eng.sun.com, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU, jcurran@nic.near.net *> *> I suspect that a major source of confusion and tension about the IPng debate *> has been classic feature-creep. We began by needing to solve a constrained *> problem. We then got seduced (...Well, as long as the hood is up, let's take *> a look at...). To be fair, there also is the legitimate observation that we *> are not *allowed* to modify anything under the hood very often, so we'd *> better consider what we can do whenever we *do* get that chance. *> *> But it is not clear to me that we are distinguishing must from should from *> would-be-nice. *> *> d/ *> Dave, In the case of multicast, it is not our features that are creeping (well, actually, deployment of IPv4 multicast is creeping forward, it seems), but the world that is enlarging its demands. We ignore those demands at our peril. Bob Braden From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 07:12:59 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07567; Tue, 26 Oct 1993 07:12:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA13171; Tue, 26 Oct 1993 07:11:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA13144; Tue, 26 Oct 1993 06:57:21 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05330; Tue, 26 Oct 1993 06:10:26 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22966; Mon, 25 Oct 93 16:00:13 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA02896; Mon, 25 Oct 93 16:13:09 EDT Date: Mon, 25 Oct 93 16:13:09 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9310252013.AA02896@cabernet.wellfleet> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Peter's note on TUBA Cc: big-internet@munnari.OZ.AU >My point was not that I didn't think multicast was very useful, but >that I didn't think the current IPv4 support for multicast would scale >well enough to become a regular feature of life on the Internet. my point is that the class D host group stuff WILL scale to very very large multicast - the only requirement is to provide scalable routing protocols, and we believe (in the IDMR working group) that amongs the SRPM, ESL and ESL-DM and CBT proposals, we have something that will scale very very large - at least as well as most of the unicast routing protocols around... Jon; There are at least two directions for scaling of multicast. I believe that the current proposals will scale to a few extremely large multicast groups. Also there is clearly some market for having a few very large multicast groups in a large network. However, do you think that the current IP multicast will scale to a situation in which a public carrier is supporting a hundred thousand different multicast groups, each with three to five participants? Ross From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 19:42:44 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08324; Tue, 26 Oct 1993 19:42:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA13872; Tue, 26 Oct 1993 19:42:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA13858; Tue, 26 Oct 1993 19:37:07 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07045; Tue, 26 Oct 1993 19:01:04 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9310260901.7045@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 26 Oct 1993 09:00:15 +0000 To: rcallon@wellfleet.com (Ross Callon) Cc: big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of "Mon, 25 Oct 93 16:13:09 EDT." <9310252013.AA02896@cabernet.wellfleet> Date: Tue, 26 Oct 93 09:00:06 +0000 From: Jon Crowcroft >However, do you think that the current IP multicast will scale to a >situation in which a public carrier is supporting a hundred thousand >different multicast groups, each with three to five participants? Ross this is exactll why SIPP is the way to go - because the people doing it are doing scalable multicast and flows (in IPv4 now) too ESL will scale to very large numbers of large groups and very very large numbers of small sparse groups - CBT will do these reasonably too...we are debating the details, and quite how large 'large' is as i type. i see no problem for instance with CBT handling 100,000 groups of 5 in todays internet on a state of the art router... ESL might do w whole lot better (and more manageably for some cases...) DVMRP and MOSPF with aggregation techniques (easily applied probably in IP and SIP addressing schemes) not at all a slouch in any case i also dont think something devised in 1988 and now using 7% of the NSFNet backbone bandwidth is a 'creeping feature' - it is a core pice of natural evolution! jon From owner-Big-Internet@munnari.OZ.AU Tue Oct 26 22:28:10 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14046; Tue, 26 Oct 1993 22:28:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA14022; Tue, 26 Oct 1993 22:27:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA14019; Tue, 26 Oct 1993 22:25:11 +1000 From: lazear@dockside.mitre.org Received: from gateway.mitre.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13942; Tue, 26 Oct 1993 22:25:19 +1000 (from lazear@dockside.mitre.org) Received: from dockside.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA17355; Tue, 26 Oct 93 08:25:10 -0400 Received: by dockside.mitre.org.mitre.org (4.1/SMI-4.1) id AA11300; Tue, 26 Oct 93 08:25:03 EDT Message-Id: <9310261225.AA11300@dockside.mitre.org.mitre.org> To: whyman@mwassocs.demon.co.uk Cc: big-internet@munnari.OZ.AU (Big Internet Maillist) Subject: Re: Peter's note on TUBA In-Reply-To: Your message of "Mon, 25 Oct 93 17:30:06 BST." <9310251730.aa4911@mwassocs.demon.co.uk> Date: Tue, 26 Oct 93 08:24:49 -0400 > the Civil Aviation Community has the same requirement for >CLNP compression over low bandwidth RF networks... >The idea is simple enough and replaces the existing CLNP header by a >"compressed" header... NATO's SHAPE Technical Center has devised a similar scheme that substitutes a "dictionary" reference for some of the longer fields in the CLNP header. Their scheme is called Subnet Independent Reduction Protocol (SNIRP). It might be useful for the aviation and military to collaborate on a single compressed header scheme. To me, the disturbing aspect of these lower layer schemes is that they prevent any usage of COTS and infrastructure. They cannot be routed, parsed for debugging by sniffers, and they create yet another proprietary island of protocol. They even hide their proprietary-ness by claiming to be a derivative or extension of a standard protocol. Sorry, but except for being able to algorithmically convert from a standard protocol to the proprietary version, it's still a different protocol and requires all the hassles of gateways (discovery, routing, etc). Walt From owner-Big-Internet@munnari.OZ.AU Wed Oct 27 02:43:23 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19145; Wed, 27 Oct 1993 00:27:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA14137; Wed, 27 Oct 1993 00:27:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA14123; Wed, 27 Oct 1993 00:19:10 +1000 Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16154; Tue, 26 Oct 1993 23:17:57 +1000 (from lyman@BBN.COM) Message-Id: <9310261317.16154@munnari.oz.au> From: Lyman Chapin Subject: Re: IPv4 multicast scaling To: braden@isi.edu Cc: big-internet@munnari.OZ.AU, Lyman@BBN.COM In-Reply-To: <199310251842.AA20220@zephyr.isi.edu> Date: Tue, 26 Oct 93 08:58:41 EDT Mail-System-Version: >Date: Mon, 25 Oct 1993 11:42:38 -0700 >From: braden@ISI.EDU (Bob Braden) >To: Lyman@BBN.COM >Subject: IPv4 multicast scaling >Cc: big-internet@munnari.oz.au > > > *> From owner-Big-Internet@munnari.OZ.AU Mon Oct 25 11:34:13 1993 > *> From: Lyman Chapin > *> Subject: Re: Peter's note on TUBA > *> To: J.Crowcroft@cs.ucl.ac.uk > *> Cc: atkinson@itd.nrl.navy.mil, big-internet@munnari.oz.au, > *> jcurran@nic.near.net, lyman@BBN.COM > *> Date: Mon, 25 Oct 93 10:59:31 EDT > *> Mail-System-Version: > *> Content-Length: 1996 > *> X-Lines: 54 > *> > *> Jon, > *> > *> My point was not that I didn't think multicast was very useful, but > *> that I didn't think the current IPv4 support for multicast would scale > *> well enough to become a regular feature of life on the Internet. Yes, > *> it's much better than multiple unicast, but what I see is a strong > *> argument for better multicast support in IPng, not an argument that > *> IPv4 multicast is just fine the way it is (and therefore is something > *> to which IPng candidates should aspire). > *> > *> - Lyman > >Lyman, > >When you say that IPv4 multicast will not scale, you are referring to the >current generation of multicast routing protocols, right? Would you >consider CBT or ESL to be IPv4 multicast? They are addressing the scaling >issues, I believe. > >Bob Braden Bob, Yes, I intended the reference to "current IPv4 multicast" to include the current generation of multicast routing protocols (not just IPv4 itself, which is a very small part of the problem). The current "production software" of the Internet does not support the large-scale use of wide- area multicast; the newer stuff that does is still experimental (even DVMRP and MOSPF, although I agree with several other people who responded to my message that some of these are "stable"). By "experimental", I certainly don't mean "no good", or "interesting only to a bunch of researchers" - my background is commercial software development, in which the distinction between a "production system" and a "development system" is very well understood! - Lyman From owner-Big-Internet@munnari.OZ.AU Wed Oct 27 22:44:24 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02897; Wed, 27 Oct 1993 20:43:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA15261; Wed, 27 Oct 1993 20:42:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA15247; Wed, 27 Oct 1993 20:29:06 +1000 Received: from gate.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29900; Wed, 27 Oct 1993 19:13:36 +1000 (from whyman@mwassocs.demon.co.uk) Received: from mwassocs.demon.co.uk by gate.demon.co.uk id aa26968; 27 Oct 93 9:07 GMT Date: Wed, 27 Oct 1993 09:00:23 BST Message-Id: <9310270900.aa5011@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: Tony Whyman To: lazear@dockside.mitre.org Cc: big-internet@munnari.OZ.AU, TSGCEE SG9 WG5 Subject: Re: Peter's note on TUBA X-Mailer: Cinetic Mail Manager V2.1 >From: lazear@dockside.mitre.org > >> the Civil Aviation Community has the same requirement for >>CLNP compression over low bandwidth RF networks... >>The idea is simple enough and replaces the existing CLNP header by a >>"compressed" header... > >NATO's SHAPE Technical Center has devised a similar scheme >that substitutes a "dictionary" reference for some of the >longer fields in the CLNP header. Their scheme is called >Subnet Independent Reduction Protocol (SNIRP). It might be >useful for the aviation and military to collaborate on a >single compressed header scheme. > As it happens both I and the author of the NATO spec. discussed CLNP compression before we wrote our respective pieces. How's that for co- operation:-) There are genuine differences between the requirements of the tactical environment that NATO is interested in, and civilian air traffic control. However, a comment that there should not be unnecessary differences is well taken - and I must try and find where I put that NATO spec.... >To me, the disturbing aspect of these lower layer schemes >is that they prevent any usage of COTS and infrastructure. >They cannot be routed, parsed for debugging by sniffers, >and they create yet another proprietary island of protocol. >They even hide their proprietary-ness by claiming to be >a derivative or extension of a standard protocol. Sorry, >but except for being able to algorithmically convert from >a standard protocol to the proprietary version, it's still >a different protocol and requires all the hassles of gateways >(discovery, routing, etc). > > Walt > I think your main concern is that there is no agreed standard for CLNP compression. If there were, then COTS software should become available and it would not be unreasonable to expect protocol analysers to recognise such protocol. I think that this would be a good idea. However, when I have brought up the subject in the past, there has been little interest from those mainly interested in fixed data links (who are more interested in V.42BIS). Interest in CLNP header compression seems to be confined to those who have short lived low bandwidth RF communications links. > -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-Big-Internet@munnari.OZ.AU Thu Oct 28 00:42:42 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11297; Thu, 28 Oct 1993 00:42:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA15476; Thu, 28 Oct 1993 00:42:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA15459; Thu, 28 Oct 1993 00:33:59 +1000 Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11091; Thu, 28 Oct 1993 00:33:10 +1000 (from 0003858921@mcimail.com) Received: from mcimail.com by MCIGATEWAY.MCIMail.com id at08268; 27 Oct 93 14:00 GMT Date: Wed, 27 Oct 93 13:59 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Peter's note on TUBA Message-Id: <83931027135938/0003858921NA4EM@mcimail.com> Tony Whyman said: >However, when I have brought up the subject in the past, there has been >little interest from those mainly interested in fixed data links (who are >more interested in V.42BIS). Interest in CLNP header compression seems to >be confined to those who have short lived low bandwidth RF communications >links. I've thought a bit about this. I use V.42bis capable modems for my dial up users. But our DSU/CSUs don't have it. Also what about ISDN. That is why I'm looking at this new draft for software compression for a PPP link with real interest. Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Thu Oct 28 01:25:02 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11504; Thu, 28 Oct 1993 00:45:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA15491; Thu, 28 Oct 1993 00:45:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA15462; Thu, 28 Oct 1993 00:37:25 +1000 Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11187; Thu, 28 Oct 1993 00:37:24 +1000 (from 0003858921@mcimail.com) Received: from mcimail.com by MCIGATEWAY.MCIMail.com id at08268; 27 Oct 93 14:00 GMT Date: Wed, 27 Oct 93 13:59 GMT From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: Peter's note on TUBA Message-Id: <83931027135938/0003858921NA4EM@mcimail.com> Tony Whyman said: >However, when I have brought up the subject in the past, there has been >little interest from those mainly interested in fixed data links (who are >more interested in V.42BIS). Interest in CLNP header compression seems to >be confined to those who have short lived low bandwidth RF communications >links. I've thought a bit about this. I use V.42bis capable modems for my dial up users. But our DSU/CSUs don't have it. Also what about ISDN. That is why I'm looking at this new draft for software compression for a PPP link with real interest. Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Thu Oct 28 05:42:59 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22110; Thu, 28 Oct 1993 05:42:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA15806; Thu, 28 Oct 1993 05:42:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA15792; Thu, 28 Oct 1993 05:33:18 +1000 From: CM0BCAIP@staffordshire.ac.uk Received: from letterbox.rl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21522; Thu, 28 Oct 1993 05:33:03 +1000 (from CM0BCAIP@staffordshire.ac.uk) Via: uk.ac.staffordshire; Wed, 27 Oct 1993 19:33:26 +0000 Date: Wed, 27 OCT 93 19:32:36 GMT To: big-internet Sender: JANET "CM0BCAIP@UK.AC.STAFFS" Message-Id: <00003303_000735D8.00974A887A535B80$24_1@UK.AC.STAFFS> Originally-To: EARN%"big-internet@munnari.oz.au" Originally-From: CM0BCAIP "ABIGAIL PUGH, BC4" Mailer: Janet_Mailshr V3.4 (23-May-1989) From owner-Big-Internet@munnari.OZ.AU Fri Oct 29 20:07:01 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10076; Fri, 29 Oct 1993 17:44:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA17629; Fri, 29 Oct 1993 17:42:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA17615; Fri, 29 Oct 1993 17:38:32 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09222; Fri, 29 Oct 1993 17:11:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00920; Fri, 29 Oct 93 03:08:47 -0400 Date: Fri, 29 Oct 93 03:08:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9310290708.AA00920@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, rcallon@wellfleet.com Subject: Re: Peter's note on TUBA Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu ESL will scale to very large numbers of large groups and very very large numbers of small sparse groups - CBT will do these reasonably too...we are debating the details, and quite how large 'large' is as i type. I don't know the details of ESL (does anyone in IDMR ever post I-D's? :-), but I'm not sure how efficient CBT trees will be for large groups (unless CBT has changed a lot since the I-D I read). The calculation of the topology of the spanning tree is not exactly a very optimal design. It just grows, bit by bit, in an uncoordinated way. The fact that the tree grows by routing from sites which want to join, back toward the core router, until it happens to get to a router which already has the tree in it, means that it is possible to have pretty non-optimal trees grow in a haphazard way. E.g. a pair of branches (to a pair of sites) which are long and parallel, where a more optimal design would be to only have a single branch which split near the sites. Sure, it won't be utterly loony, since the path from each site back to the core is reasonably optimal in and of itself, without reference to the rest of the tree, but that can still produce some pretty ugly spanning trees. This is more a less a consequence of the fact that the complete spanning tree is never calculated as such, either by a distributed algorithm, (a la MOSPF or DVMRP, which have their own scaling problems in number of multicast groups supported), or a localized algorithm (a la IDPR). i see no problem for instance with CBT handling 100,000 groups of 5 in todays internet on a state of the art router... Once the spanning trees are calculated, the groups themselves shouldn't present a much worse scaling problem than unicast flows, in terms of state in the routers (which we already know is manageable). I am *wayyyy* to short on brain cells at this hour to do the model, but I reckon for small multicast groups (the bulkl of them) the model looks pretty similar to the unicast one. DVMRP and MOSPF with aggregation techniques (easily applied probably in IP and SIP addressing schemes) not at all a slouch in any case Tilt. As Steve Deering (??) pointed out, there is effectively no useful aggregation in multicast group addresses, especially when the members are widely scattered. These algorithms both calculate the spanning trees in a distributed algorithm, which means the total cost of using them is something vaguely like the number of nodes doing the distributed calculation times the number of extant groups, and both of them get pretty large. I don't think either one will work well for many, many, many small, widely scattered, groups. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 29 20:43:31 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16139; Fri, 29 Oct 1993 20:43:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA17791; Fri, 29 Oct 1993 20:42:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA17777; Fri, 29 Oct 1993 20:29:21 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12975; Fri, 29 Oct 1993 19:02:11 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9310290902.12975@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 29 Oct 1993 09:01:40 +0000 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: rcallon@wellfleet.com, big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of "Fri, 29 Oct 93 03:08:47 -0400." <9310290708.AA00920@ginger.lcs.mit.edu> Date: Fri, 29 Oct 93 09:01:39 +0000 From: Jon Crowcroft > ESL will scale to very large numbers of large groups and very very > large numbers of small sparse groups - CBT will do these reasonably > too...we are debating the details, and quite how large 'large' is as i > type. > >I don't know the details of ESL (does anyone in IDMR ever post I-D's? :-), then join idmr by sending to idmr-request@cs.ucl.ac.uk a lot of work has gone on but its stil la little bit early to put ESL out (very soon i imagine). a key thing to remember is that while the steinar tree problem is NP-bad, luckily a single tree which happens to be minimum cost in links can be got to a good approximation by many hueristics, and in hierarchical nets, its very easy, and in nets with several backbones, you use multiple cores with several easy approximations,. meanwhile, for SPT approaches, the link cost in most simulations (see liming or matt doars wirk)shows you are still not far away from link minimal costs - while you gain the minimal delay (or other metric) that some applications want... >toward the core router, until it happens to get to a router which already has >the tree in it, means that it is possible to have pretty non-optimal trees >grow in a haphazard way. E.g. a pair of branches (to a pair of sites) which >are long and parallel, where a more optimal design would be to only have a >single branch which split near the sites. Sure, it won't be utterly loony, >since the path from each site back to the core is reasonably optimal in and of >itself, without reference to the rest of the tree, but that can still produce >some pretty ugly spanning trees. yes, but it doesnt much in practice... > DVMRP and MOSPF with aggregation techniques (easily applied probably in > IP and SIP addressing schemes) not at all a slouch in any case > >Tilt. As Steve Deering (??) pointed out, there is effectively no useful >aggregation in multicast group addresses, especially when the members are >widely scattered. > >These algorithms both calculate the spanning trees in a distributed algorithm, >which means the total cost of using them is something vaguely like the number >of nodes doing the distributed calculation times the number of extant groups, >and both of them get pretty large. I don't think either one will work well for >many, many, many small, widely scattered, groups. right, they wont work for the large # of sparse groups. please read the ESL stuff... jon From owner-Big-Internet@munnari.OZ.AU Fri Oct 29 21:13:10 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16965; Fri, 29 Oct 1993 21:13:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA17833; Fri, 29 Oct 1993 21:12:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA17819; Fri, 29 Oct 1993 20:58:49 +1000 Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16581; Fri, 29 Oct 1993 20:58:51 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from [132.236.236.44] (CU-DIALUP-0202.CIT.CORNELL.EDU [132.236.236.44]) by mitchell.cit.cornell.edu (8.6.3/8.6.3) with SMTP id GAA14117; Fri, 29 Oct 1993 06:58:08 -0400 Message-Id: <199310291058.GAA14117@mitchell.cit.cornell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Oct 1993 06:57:33 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa), J.Crowcroft@cs.ucl.ac.uk, rcallon@wellfleet.com From: Scott W Brim Subject: Re: Peter's note on TUBA Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu >I don't know the details of ESL (does anyone in IDMR ever post I-D's? :-), I'll bet we get some drafts out after this meeting. You would like the proposed protocols to be internally consistent, wouldn't you ;-)? >The fact that the tree grows by routing from sites which want to join, back >toward the core router, until it happens to get to a router which already has >the tree in it, means that it is possible to have pretty non-optimal trees >grow in a haphazard way. E.g. a pair of branches (to a pair of sites) which >are long and parallel, where a more optimal design would be to only have a >single branch which split near the sites. NP-completeness alert! > DVMRP and MOSPF with aggregation techniques (easily applied probably in > IP and SIP addressing schemes) not at all a slouch in any case > >Tilt. As Steve Deering (??) pointed out, there is effectively no useful >aggregation in multicast group addresses, especially when the members are >widely scattered. These are claimed to be effective for *local* use -- and local is defined as local enough that the lack of scaling doesn't matter. >These algorithms both calculate the spanning trees in a distributed algorithm, >which means the total cost of using them is something vaguely like the number >of nodes doing the distributed calculation times the number of extant groups, >and both of them get pretty large. I don't think either one will work well for >many, many, many small, widely scattered, groups. A node only participates in the distributed calculation if it receives information that the group is active. All of the new schemes try to limit the spread of that knowledge. Time to change the subject of this thread? From owner-Big-Internet@munnari.OZ.AU Sat Oct 30 02:28:31 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28057; Sat, 30 Oct 1993 02:28:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA18155; Sat, 30 Oct 1993 02:27:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA18141; Sat, 30 Oct 1993 02:19:40 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25011; Sat, 30 Oct 1993 01:05:50 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03976; Fri, 29 Oct 93 10:55:12 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA01456; Fri, 29 Oct 93 11:08:24 EDT Date: Fri, 29 Oct 93 11:08:24 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9310291508.AA01456@cabernet.wellfleet> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: Peter's note on TUBA Cc: big-internet@munnari.OZ.AU, rcallon@wellfleet.com i see no problem for instance with CBT handling 100,000 groups of 5 in todays internet on a state of the art router... Once the spanning trees are calculated, the groups themselves shouldn't present a much worse scaling problem than unicast flows, in terms of state in the routers (which we already know is manageable). I am *wayyyy* to short on brain cells at this hour to do the model, but I reckon for small multicast groups (the bulk of them) the model looks pretty similar to the unicast one. My understanding is that CBT requires that all routers on the tree keep explicit cache information for every CBT tree which goes through them. This is very different from normal unicast routing. There is no problem forwarding unicast packets between 10,000 different {source,destination} pairs of hosts, since you can just forward each packet and then forget about it. It is somewhat harder if you have to keep state information on every flow individually. Ross From owner-Big-Internet@munnari.OZ.AU Sat Oct 30 03:58:25 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01160; Sat, 30 Oct 1993 03:58:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA18247; Sat, 30 Oct 1993 03:57:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA18244; Sat, 30 Oct 1993 03:56:34 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01154; Sat, 30 Oct 1993 03:56:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03987; Fri, 29 Oct 93 13:56:13 -0400 Date: Fri, 29 Oct 93 13:56:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9310291756.AA03987@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: Peter's note on TUBA Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, rcallon@wellfleet.com > I don't know the details of ESL (does anyone in IDMR ever post I-D's?) then join idmr by sending to idmr-request@cs.ucl.ac.uk What, are you kidding? I can't really keep up with the few mailing lists I am already on! :-) Anyway, Lyman sent me a copy. its stil la little bit early to put ESL out (very soon i imagine). "Speak of the Devil, and hear the sound of his wings..." :-) Just go the I-D announcements! a key thing to remember is that while the steinar tree problem is NP-bad, luckily a single tree which happens to be minimum cost in links can be got to a good approximation by many hueristics Yes, I know, I'm just wondering if the independant distributed Reverse Path method used by both CBT and ESL to create the distribution tree (if I'm understanding ESL right here; short on sleep.. :-) is going to produce acceptable results always (especially when different people have different ideas of "acceptable"). meanwhile, for SPT approaches, the link cost in most simulations (see liming or matt doars wirk)shows you are still not far away from link minimal costs - while you gain the minimal delay (or other metric) that some applications want... The latter is a good point, but not everyone wants that, right? I'm not familiar with their simulations, but I think the thing you need to look at is not averages, but what the shape of the curve is. I.e., it's usually more important to people (in pretty much any service measurement) that the worst case be no worse than X, rather than that 98% of cases are better than Y. In this regard, I'd be thinking that you want to go for a system where the computation of the distribution tree is a separate local algorithm, which people can replace or modify as they wish, to get the results they want. > it is possible to have pretty non-optimal trees grow in a haphazard way. yes, but it doesnt much in practice... Again, what about the exception cases, differening requirements by different users, etc, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Sat Oct 30 04:13:11 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01577; Sat, 30 Oct 1993 04:13:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA18290; Sat, 30 Oct 1993 04:12:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA18263; Sat, 30 Oct 1993 04:03:55 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01294; Sat, 30 Oct 1993 04:04:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04068; Fri, 29 Oct 93 14:03:53 -0400 Date: Fri, 29 Oct 93 14:03:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9310291803.AA04068@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, swb@nr-tech.cit.cornell.edu Subject: Re: Peter's note on TUBA Cc: jnc@ginger.lcs.mit.edu NP-completeness alert! Yes, I know, absolutely guaranteed optimal is NP, but as Jon points out, there are good approximations. Again, given that newer and better algorithms are coming out in this area, I'd think you'd want a design where new algorithms can be deployed incrementally without a massive upheaval. > These algorithms both calculate the spanning trees in a distributed > algorithm, which means the total cost of using them is something vaguely > like the number of nodes doing the distributed calculation times the > number of extant groups, A node only participates in the distributed calculation if it receives information that the group is active. All of the new schemes try to limit the spread of that knowledge. Pruning works best in a network which is more of a tree than a mesh; i.e. router R can be sure that it doesn't have any subsidiary nodes which are part of the tree. However, things like robustness, load-sharing, etc drive you more toward the mesh state, so we'll have to see how much you can limit that spread in practise. Time to change the subject of this thread? As in, move it to IDMR? I dunno, I like to look at things at a high level, and I think Big-I's the place for that sort of thing. Noel From owner-Big-Internet@munnari.OZ.AU Sat Oct 30 04:43:10 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02756; Sat, 30 Oct 1993 04:43:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA18337; Sat, 30 Oct 1993 04:42:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA18323; Sat, 30 Oct 1993 04:30:43 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02407; Sat, 30 Oct 1993 04:30:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04458; Fri, 29 Oct 93 14:30:26 -0400 Date: Fri, 29 Oct 93 14:30:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9310291830.AA04458@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu, rcallon@wellfleet.com Subject: Re: Peter's note on TUBA Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu > Once the spanning trees are calculated, the groups themselves shouldn't > present a much worse scaling problem than unicast flows, in terms of > state in the routers (which we already know is manageable). My understanding is that CBT requires that all routers on the tree keep explicit cache information for every CBT tree which goes through them. This is very different from normal unicast routing. ... It is somewhat harder if you have to keep state information on every flow individually. Err, I thought I indicated that I was thinking of the case where we kept state info on each unicast flow; perhaps I didn't say this explicitly enough. In case you didn't read the Noelgram, I provided a longish "proof" to the mailing list some while back that flow state growth in routers could not (under some loose assumptions which seem pretty reasonable, such as the bandwidth requirement of the average flow not going down over time) exceed the bandwidth growth through the router. This is an important result since it ties state growth in routers to conditions *local* to the router, not in the network as a whole. There's an even more interesting facet, which is that chip speed increases are at best linearly related to the decrease in feature size, so you halve the feature size and get a chip that's twice as fast. However, note that every time a new generation of memory chips comes out, it's *four* times as large as the previous one (i.e. 16K -> 64K -> 256K -> 1M etc)? That's because memory capacity goes as the *square* of the reduction in feature size. So, this, together with the result above, tells me that state growth is not going to be a problem in the long run. Noel From owner-Big-Internet@munnari.OZ.AU Sat Oct 30 05:13:20 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03689; Sat, 30 Oct 1993 05:13:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA18381; Sat, 30 Oct 1993 05:12:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA18367; Sat, 30 Oct 1993 05:06:12 +1000 Received: from munin.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03467; Sat, 30 Oct 1993 05:06:21 +1000 (from crawdad@munin.fnal.gov) Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA01989 (5.65c+/IDA-1.4.4 for big-internet@munnari.oz.au); Fri, 29 Oct 1993 14:06:09 -0500 Message-Id: <199310291906.AA01989@munin.fnal.gov> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Peter's note on TUBA In-Reply-To: Your message of Fri, 29 Oct 93 14:30:26 EDT. <9310291830.AA04458@ginger.lcs.mit.edu> Date: Fri, 29 Oct 93 14:06:09 -0500 From: Matt Crawford > There's an even more interesting facet, which is that chip speed > increases are at best linearly related to the decrease in feature > size, so you halve the feature size and get a chip that's twice as > fast. However, ... memory capacity goes as the *square* of the > reduction in feature size. So, this, together with the result > above, tells me that state growth is not going to be a problem in > the long run. It might be logarithmically a problem. If N ~ 1/(feature size), then processor speed and presumed bandwidth ~ N, capacity for state information ~ N^2. But the processor cycles to access the state info would probably ~ N log N, wouldn't it? So assume engineering breakthroughs ~ log N ... :-) _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Sat Oct 30 09:13:15 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12080; Sat, 30 Oct 1993 09:13:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA18591; Sat, 30 Oct 1993 09:12:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA18577; Sat, 30 Oct 1993 08:58:13 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11490; Sat, 30 Oct 1993 08:58:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07408; Fri, 29 Oct 93 18:58:11 -0400 Date: Fri, 29 Oct 93 18:58:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9310292258.AA07408@ginger.lcs.mit.edu> To: crawdad@munin.fnal.gov, jnc@ginger.lcs.mit.edu Subject: State growth issues Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu > There's an even more interesting facet, which is that chip speed > increases are at best linearly related to the decrease in feature > size, so you halve the feature size and get a chip that's twice as > fast. However, ... memory capacity goes as the *square* of the > reduction in feature size. It might be logarithmically a problem. If N ~ 1/(feature size), then processor speed and presumed bandwidth ~ N, capacity for state information ~ N^2. But the processor cycles to access the state info would probably ~ N log N, wouldn't it? So assume engineering breakthroughs ~ log N ... :-) I assume that really tremendously fast switches "here in the future" are going to be either fully hardware (for normal user data traffic which is part of existing flows), or have hardware assist of various kinds. In either case, the lookup could be in parallel. Alternatively, I'm not sure the cost to get to the data really is N log N; if you have a flow id in the packets, you should be able to pick it up, hash it, and get the associated state block in less than N log N cycles, no? I mean, does it take N log N cycles to look up an entry in the routing tables now? Noel