From owner-Big-Internet@munnari.OZ.AU Wed Nov 3 02:32:52 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02019; Wed, 3 Nov 1993 02:32:52 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19746; Wed, 3 Nov 1993 02:31:30 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19743; Wed, 3 Nov 1993 02:24:11 +1100 Received: from munin.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29582; Wed, 3 Nov 1993 01:31:28 +1100 (from crawdad@munin.fnal.gov) Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA06893 (5.65c+/IDA-1.4.4 for big-internet@munnari.oz.au); Tue, 2 Nov 1993 08:32:13 -0600 Message-Id: <199311021432.AA06893@munin.fnal.gov> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: State growth issues In-Reply-To: Your message of Fri, 29 Oct 93 18:58:11 EDT. <9310292258.AA07408@ginger.lcs.mit.edu> Date: Tue, 02 Nov 93 08:32:12 -0600 From: Matt Crawford > processor speed and presumed bandwidth ~ N, ... > But the processor cycles to access the state info > would probably ~ N log N, wouldn't it? > > 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? I was estimating N log N to process an amount of traffic of O(N), not to process each packet. But maybe your O(N^2) memory lets you keep your hash tables so big you can access data in O(1) time? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Thu Nov 4 11:03:43 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03080; Thu, 4 Nov 1993 02:34:15 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA19927; Thu, 4 Nov 1993 02:33:24 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA19924; Thu, 4 Nov 1993 02:23:32 +1100 Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02613; Thu, 4 Nov 1993 02:23:17 +1100 (from whyman@mwassocs.demon.co.uk) Date: Wed, 03 Nov 1993 13:46:11 GMT Message-Id: <9311031346.aa5234@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: koelman@stc.nato.int Cc: lazear@dockside.mitre.org, big-internet@munnari.OZ.AU, sg9wg5@stc.nato.int, robinson@issun3.stc.nato.int Subject: Re: We really ought to do an RFC on SNIRP i.e. CLNP header compression. (was Re: Peter's note on TUBA) X-Mailer: Cinetic Mail Manager V2.1 >I purposely ignored Tony's spec initially because it seemed it a bit >X.25 biased i.e. it had to operate over an X.25 type of service. >SNIRP is totally subnet independent and cleanly (architecturally >at least....) slides between CLNP (the Subnetwork Service user) >and any Subnetwork Service provider. >So the SNIRP entity has the identical service at its top and >bottom. It just 'massages' the QoS somewhat i.e it puts out >less SN user data to the subnet and (a bit) more SN-Unitdata >request primitives. X.25 was rather forced on me by an ICAO decision. The ideal spec. would take note of whether the data link was CO or CL mode and vary its procedures appropriately. > >BTW, the SNIRP spec (first draft) is STC (SHAPE Technical Centre) >Technical Note TN-491, >available upon request. It is (slowly) finding its way into >the DoD and at some point will probably hit the OIW. >I should be throwing it at EWOS as well... > I've looked under my pillow, and its not there. Can you send me another copy please. >The SNIRP spec is being implemented and evaluated within CSNI >(a collaborative NATO networking research project). The plan is to come > >up with a NATO STANAG (Standard Agreement) for it at some point. > >> > >It's time for an RFC really. > > Ok, let's do it. >--- >Ton Koelman e-mail: koelman@stc.nato.int (NeXT Mail Welcome!) >SHAPE Technical Centre, P.O. Box 174, 2501 CD The Hague >The Netherlands (voice: 31-70-3142431, fax: 31-70-3142111) > > -- 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 Nov 4 11:18:50 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13056; Thu, 4 Nov 1993 06:34:07 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA20028; Thu, 4 Nov 1993 06:33:34 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA20023; Thu, 4 Nov 1993 06:18:50 +1100 Received: from issun3.stc.nato.int by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20487; Wed, 3 Nov 1993 21:20:04 +1100 (from koelman@issun3.stc.nato.int) Received: from cuby.stc.nato.int by stc.nato.int with SMTP id AA18561 (5.65c/IDA-1.4.4 for ); Wed, 3 Nov 1993 11:13:10 +0100 Received: by cuby.stc.nato.int (NX5.67c/NeXT-2.0) id AA00465; Wed, 3 Nov 93 12:04:27 +0100 Date: Wed, 3 Nov 93 12:04:27 +0100 From: koelman@issun3.stc.nato.int (Ton Koelman) Message-Id: <9311031104.AA00465@cuby.stc.nato.int> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: whyman@mwassocs.demon.co.uk Subject: We really ought to do an RFC on SNIRP i.e. CLNP header compression. (was Re: Peter's note on TUBA) Cc: lazear@dockside.mitre.org, big-internet@munnari.OZ.AU, sg9wg5@stc.nato.int (TSGCEE SG9 WG5), robinson@issun3.stc.nato.int Reply-To: koelman@stc.nato.int > > > >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. Indeed. I am the author of that spec BTW. > > 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.... Have a look under your pillow :-) I purposely ignored Tony's spec initially because it seemed it a bit X.25 biased i.e. it had to operate over an X.25 type of service. SNIRP is totally subnet independent and cleanly (architecturally at least....) slides between CLNP (the Subnetwork Service user) and any Subnetwork Service provider. So the SNIRP entity has the identical service at its top and bottom. It just 'massages' the QoS somewhat i.e it puts out less SN user data to the subnet and (a bit) more SN-Unitdata request primitives. BTW, the SNIRP spec (first draft) is STC (SHAPE Technical Centre) Technical Note TN-491, available upon request. It is (slowly) finding its way into the DoD and at some point will probably hit the OIW. I should be throwing it at EWOS as well... The SNIRP spec is being implemented and evaluated within CSNI (a collaborative NATO networking research project). The plan is to come up with a NATO STANAG (Standard Agreement) for it at some point. > > > 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. It's time for an RFC really. --- Ton Koelman e-mail: koelman@stc.nato.int (NeXT Mail Welcome!) SHAPE Technical Centre, P.O. Box 174, 2501 CD The Hague The Netherlands (voice: 31-70-3142431, fax: 31-70-3142111) From owner-Big-Internet@munnari.OZ.AU Thu Nov 4 11:19:49 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18753; Thu, 4 Nov 1993 08:49:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA20055; Thu, 4 Nov 1993 08:48:39 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA20052; Thu, 4 Nov 1993 08:46:34 +1100 Received: from gateway.mitre.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01101; Thu, 4 Nov 1993 01:40:00 +1100 (from lazear@gateway.mitre.org) Received: by gateway.mitre.org (5.61/SMI-2.2) id AA19489; Wed, 3 Nov 93 09:39:49 -0500 Date: Wed, 3 Nov 93 09:39:49 -0500 From: lazear@gateway.mitre.org (Walt Lazear) Message-Id: <9311031439.AA19489@gateway.mitre.org> To: koelman@stc.nato.int, whyman@mwassocs.demon.co.uk Subject: Re: We really ought to do an RFC on SNIRP i.e. CLNP header compression. (was Re: Peter's note on TUBA) Cc: big-internet@munnari.OZ.AU, lazear@dockside.mitre.org, robinson@issun3.stc.nato.int, sg9wg5@stc.nato.int I have been attending the Internet Engineering Task Force meeting in Houston and have found that the electric utilities are doing their own bandwidth- reducing exercise on the OSI stack. I think they will be extremely interested in the SNIRP proposal as a way of saving bandwidth and not having to invent such a scheme themselves. The fellow I met here is Daniel E. Nordell from Northern States Power Company, 414 Nicollet Mall, Minneapolis, Minnesota 55401. He does *not* have e-mail access, but his phone is (612)330-5822 and his FAX is (612)330-6810. The electric industry is looking at putting small processors on electric poles and home entry points. They are interested in the mOSI/ThinOSI work (which helps their small processors) and in collaborating with others to reduce bandwidth. Walt How can I obtain a copy of the SNIRP spec? Is it available online? From owner-Big-Internet@munnari.OZ.AU Tue Nov 9 06:23:05 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13731; Tue, 9 Nov 1993 06:23:05 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA25853; Tue, 9 Nov 1993 06:22:37 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA25850; Tue, 9 Nov 1993 06:19:53 +1100 From: b32357@achilles.ctd.anl.gov Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13656; Tue, 9 Nov 1993 06:20:05 +1100 (from b32357@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA10142; Mon, 8 Nov 93 13:16:39 CST Message-Id: <9311081916.AA10142@achilles.ctd.anl.gov> To: "Gary C. Kessler, +1 802-655-8633" Cc: atm@hpl.hp.com, big-internet@munnari.OZ.AU, bmwg@harvard.edu, comp.dcom.cell-relay@indiana.edu, cellular@dfv.rwth-aachen.de, com-priv@psi.com, confctrl@isi.edu, dqlist@atri.curtin.edu.au, end2end-interest@isi.edu, fca@amcc.com, fddi-sync@merit.edu, frftc@nsco.network.com, hippi@think.com, ietf@cnri.reston.va.us, isdn@list.prime.com, members@farnet.org, nren-discuss@psi.com, ospf@trantor.umd.edu, repeater%sunoco@relay.nswc.navy.mil, rolc@network.com, sci_announce@hplsci.hpl.hp.com, scsi@wichitaks.ncr.com, smdstc@nsco.network.com, smds-users@nas.nasa.gov, snmp@uu.psi.com, tcp-ip@nic.ddn.mil, tuba@lanl.gov, wireless@tandem.com, b32357@achilles.ctd.anl.gov Subject: Re: 19th Conf. on Local Computer Networks Call for Papers... In-Reply-To: (Your message of 08 Nov 93 13:02:27 EST.) <01H52NY70F1I8YAIHP@SMCVAX.SMCVT.EDU> Date: Mon, 08 Nov 93 13:16:32 -0600 This call for papers fits right in with our research activities. Please note submission date of March 7, 1994. Linda From owner-Big-Internet@munnari.OZ.AU Tue Nov 9 08:19:43 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11330; Tue, 9 Nov 1993 05:23:28 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA25787; Tue, 9 Nov 1993 05:22:37 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA25784; Tue, 9 Nov 1993 05:14:01 +1100 Received: from smcvax.smcvt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10663; Tue, 9 Nov 1993 05:08:07 +1100 (from KUMQUAT@SMCVAX.SMCVT.EDU) Received: from SMCVAX.SMCVT.EDU by SMCVAX.SMCVT.EDU (PMDF #3520 ) id <01H52NY70F1G8YAIHP@SMCVAX.SMCVT.EDU>; Mon, 8 Nov 1993 13:02:28 EST Date: 08 Nov 1993 13:02:27 -0500 (EST) From: "Gary C. Kessler, +1 802-655-8633" Subject: 19th Conf. on Local Computer Networks Call for Papers... To: atm@hpl.hp.com, big-internet@munnari.OZ.AU, bmwg@harvard.edu, comp.dcom.cell-relay@indiana.edu, cellular@dfv.rwth-aachen.de, com-priv@psi.com, confctrl@isi.edu, dqlist@atri.curtin.edu.au, end2end-interest@isi.edu, fca@amcc.com, fddi-sync@merit.edu, frftc@nsco.network.com, hippi@think.com, ietf@cnri.reston.va.us, isdn@list.prime.com, members@farnet.org, nren-discuss@psi.com, ospf@trantor.umd.edu, repeater%sunoco@relay.nswc.navy.mil, rolc@network.com, sci_announce@hplsci.hpl.hp.com, scsi@wichitaks.ncr.com, smdstc@nsco.network.com, smds-users@nas.nasa.gov, snmp@uu.psi.com, tcp-ip@nic.ddn.mil, tuba@lanl.gov, wireless@tandem.com Message-Id: <01H52NY70F1I8YAIHP@SMCVAX.SMCVT.EDU> X-Vms-To: @LCNLIST Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT ********** CALL FOR PAPERS ********** 19th Annual Conference on Local Computer Networks "The Conference on Practical Leading Edge Computer Networking" October 2-5, 1994, Minneapolis, Minnesota, USA ============================================================================ Sponsored by: IEEE Computer Society TC - Computer Communications ============================================================================ Theme: The emphasis on this year's conference is on practical experience using local computer networks. This unique approach simulates a workshop environment and allows for an effective interchange among users, researchers, and vendors. Some of the primary goals of the conference are to enable those involved in the local computer network field to share experiences, lessons learned, and prototype data and analysis. Because of these objectives, papers based on experience are especially solicited. The focus of the 19th LCN will be Interconnection and Extension of Applications and Services Beyond the LAN. Papers that cover these areas are explicitly sought and will be given preference. Information for Authors: All authors must submit 5 full copies of the full technical paper by mail or delivery service. DO NOT SUBMIT COMPLETE PAPERS BY FAX. The first page must contain: title of the paper, author's names including affiliations, complete mailing address, telephone and FAX numbers, Internet or Bitnet address, and a 250 word (maximum) abstract (double-spaced) in English to Gary Kessler, Program Chair, at the address below. Sessions are being organized on: o Internetworking/Routers/Bridges o Multimedia o Distributed Applications o Wide Area Networks o ATM o Fibre Channel Networking o High Speed Networks o Error Control Techniques o Congestion Control o High Performance Protocols o Metropolitan Area Networks o LAN/MAN/WAN Integration o Standards o Network Management o Remote Monitoring o Wireless Networks o Emerging Technologies o FDDI and FDDI-II o Realtime Networks Send papers to: Gary C. Kessler, Program Chair Important Dates Hill Associates Submission: March 7, 1994 17 Roosevelt Highway Acceptance: June 20, 1994 Colchester, VT 05446 USA Camera Copy: July 20, 1994 +1 802-655-0940 (main office) +1 802-655-8633 (direct) Conference Summary +1 802-655-7974 (fax) - Tutorials kumquat@smcvax.smcvt.edu - Technical Paper Sessions kumquat@smcvax.bitnet - Panel Discussions From owner-Big-Internet@munnari.OZ.AU Wed Nov 10 02:39:32 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05564; Wed, 10 Nov 1993 01:54:11 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA26861; Wed, 10 Nov 1993 01:53:28 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA26858; Wed, 10 Nov 1993 01:42:09 +1100 Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02323; Wed, 10 Nov 1993 00:33:44 +1100 (from kasten@ftp.com) Received: by ftp.com id AA19737; Tue, 9 Nov 93 08:31:45 -0500 Date: Tue, 9 Nov 93 08:31:45 -0500 Message-Id: <9311091331.AA19737@ftp.com> To: vaf@valinor.stanford.edu, big-internet@munnari.OZ.AU Subject: Re: Statistics and the utilization of IP address space From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Vince Fuller wrote on the IETF list: > We need CIDR now to solve the routing table explosion problem. Current rough > estimates are that the RS6000 routers which make up the ANS/NSFNET backbone > will not be able to handle more than around 25K routes and that 16MB cisco > CSC/4-based routers, upon which much of the Internet infrastrcture is built, > will not be able to handle more than around 29K. At the current exponential > growth rate of tables in well-connected routers, these limits will be exceeded > in less than a year. Vince, What is the basis for these numbers? Is it memory constraints? Is it constraints of the algorithms used to generate routes? Is it constraints in the protocols used to pass route information around? Is it simply a lack of CPU power in the routers? What is the failure mode when the limits are reached? Does the router die? Do the excess routes get lost? Does performance degrade slowly? It seems to me that we have a unique opportunity here to study and characterize routing exhaustion and that we should do this, the better to understand the problem(s) and be able to deal with it the next time it happens (and/or device ways to prevent it from occuring in the future at all). I've moved this to big-internet since I think that that list is a more appropriate forum for this sort of discussion. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Nov 10 17:02:33 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09210; Wed, 10 Nov 1993 14:25:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA27492; Wed, 10 Nov 1993 14:24:03 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA27489; Wed, 10 Nov 1993 14:10:19 +1100 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08558; Wed, 10 Nov 1993 14:10:22 +1100 (from asp@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA20620; Tue, 9 Nov 93 22:10:02 -0500 From: asp@uunet.uu.net (Andrew Partan) Message-Id: <9311100310.AA20620@rodan.UU.NET> Subject: Re: Statistics and the utilization of IP address space To: kasten@ftp.com Date: Tue, 9 Nov 1993 22:10:01 -0500 (EST) Cc: vaf@valinor.stanford.edu, big-internet@munnari.OZ.AU In-Reply-To: <9311091331.AA19737@ftp.com> from "Frank Kastenholz" at Nov 9, 93 08:31:45 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1569 > What is the basis for these numbers? Is it memory constraints? Is it > constraints of the algorithms used to generate routes? Is it constraints > in the protocols used to pass route information around? Is it simply a > lack of CPU power in the routers? The RS6000s have space for 25,000 routes on their boards. My understanding is that it is not possible to upgrade them any further. Folks at ANS would have more details if you are interested. Some folks at cisco have done an estimate of the memory use of their routers for holding BGP routes, and estimate that 16 Meg of memory will be able to hold approx 28,000 to 29,000 routes. I do not know of any cisco router that has more than 16 Meg of memory right now (it should be possible to put 64 Meg in a cisco 7000, but I have never done it). There are currently 13,500 routes available on the Internet (I have a router that has full routing; it had 13,757 routes right now). This means that we have about 1 doubling (in terms of routing table growth) left before those routers that have a full routing table run out of memory to hold the routes. If we deploy BGP4 and start using prefix routes, we will save a large number of routes in most routing tables. If AlterNet took its current 2157 routes (individual class A/B/C nets) and did as much compression as we could, we would be announcing just 676 prefixes to the rest of the world. Any non-European router should be able to take the current 2500 European nets in 193.*.*.* and reduce this to just one prefix route. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Wed Nov 10 20:55:00 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26861; Wed, 10 Nov 1993 20:55:00 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA27844; Wed, 10 Nov 1993 20:54:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA27841; Wed, 10 Nov 1993 20:46:55 +1100 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26509; Wed, 10 Nov 1993 20:47:01 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9311100947.26509@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 10 Nov 1993 09:46:19 +0000 To: Christian Huitema Cc: asp@uunet.uu.net (Andrew Partan), big-internet@munnari.OZ.AU Subject: Re: Statistics and the utilization of IP address space In-Reply-To: Your message of "Wed, 10 Nov 93 10:20:19 +0100." <199311100920.AA28818@mitsou.inria.fr> Date: Wed, 10 Nov 93 09:46:18 +0000 From: Jon Crowcroft >Don't bet on that! There is no really any such thing as unified Europe when >it comes to networking -- not any more than one single entry for North >America. What you will probably get is one entry per European network >provider, which would already be a big saving. Christian well, there might be a single provider one day soon the question is whether its BT+MCI or the new AT&T/FrenchPTT+Bundespost:-) jon From owner-Big-Internet@munnari.OZ.AU Wed Nov 10 21:58:58 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25561; Wed, 10 Nov 1993 20:25:41 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA27802; Wed, 10 Nov 1993 20:24:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA27799; Wed, 10 Nov 1993 20:17:51 +1100 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25257; Wed, 10 Nov 1993 20:17:59 +1100 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA28818; Wed, 10 Nov 1993 10:20:20 +0100 Message-Id: <199311100920.AA28818@mitsou.inria.fr> To: asp@uunet.uu.net (Andrew Partan) Cc: big-internet@munnari.OZ.AU Subject: Re: Statistics and the utilization of IP address space In-Reply-To: Your message of "Tue, 09 Nov 1993 22:10:01 EST." <9311100310.AA20620@rodan.UU.NET> Date: Wed, 10 Nov 1993 10:20:19 +0100 From: Christian Huitema >Any non-European router should be able to take the current 2500 >European nets in 193.*.*.* and reduce this to just one prefix route. Don't bet on that! There is no really any such thing as unified Europe when it comes to networking -- not any more than one single entry for North America. What you will probably get is one entry per European network provider, which would already be a big saving. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 03:40:07 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14486; Thu, 11 Nov 1993 03:40:07 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA28284; Thu, 11 Nov 1993 03:39:39 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA28281; Thu, 11 Nov 1993 03:38:51 +1100 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14433; Thu, 11 Nov 1993 03:38:54 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA04713 for big-internet@munnari.oz.au; Wed, 10 Nov 93 11:38:35 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA29543; Wed, 10 Nov 93 08:38:03 PST Message-Id: <9311101638.AA29543@aland.bbn.com> To: Frank Kastenholz Cc: big-internet@munnari.OZ.AU Subject: Re: Statistics and the utilization of IP address space From: Craig Partridge Date: Wed, 10 Nov 93 08:38:02 -0800 Sender: craig@aland.bbn.com > If I understand you properly, this is "simply" a hardware problem? > Not enough ram in the box (maybe not enough address lines on the > backplane -- sounds familiar, doesn't it?). I tend to agree with this view, at least in part. RS6000s are old technology these days and if they don't have enough memory, we should throw them out and use a more current router. I'm not interested in changing the Internet routing architectures to save five year old, fully depreciated, systems. However, more broadly, as I understand matters, the cost of a given amount of memory is going down about 40% a year (same money buys 1.6 times as much memory as it did last year), while our routing table sizes are growing on the order of 150% a year (need 2.5 times as much memory next year as we do this year). So we have a long-term mismatch -- we need to get our routing table growth rate down to 60% a year or so to be safe. And that's CIDR's job. Craig From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 03:40:23 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09120; Thu, 11 Nov 1993 01:40:41 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA28108; Thu, 11 Nov 1993 01:39:37 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA28093; Thu, 11 Nov 1993 01:33:40 +1100 Received: from smtp.sprint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08750; Thu, 11 Nov 1993 01:33:47 +1100 (from amr@smtp.sprint.com) Received: from [160.81.48.79] by smtp.sprint.com for big-internet@munnari.oz.au (4.1/(Sprint International ->>sendmail.cf<<-)) id AA23078; Wed, 10 Nov 93 09:33:32 EST Message-Id: <9311101433.AA23078@smtp.sprint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 10 Nov 1993 09:33:18 -0500 To: J.Crowcroft@cs.ucl.ac.uk From: amr@smtp.sprint.com (Tony Rutkowski) Subject: Single provider Cc: big-internet@munnari.OZ.AU, Christian.Huitema@sophia.inria.fr Jon, It cannot happen. There will be maybe a half dozen vigorously competing. Pipes will be a commodity business, and the better carriers (read those who understand anything above level 2 services) will be going after an ever evolving market for upper layer services that prominently include the internetworking marketplace. >>To: Christian Huitema >>Cc: asp@uunet.uu.net (Andrew Partan), big-internet@munnari.oz.au >>Subject: Re: Statistics and the utilization of IP address space >>Date: Wed, 10 Nov 93 09:46:18 +0000 >>From: Jon Crowcroft >> >> >> >Don't bet on that! There is no really any such thing as unified Europe when >> >it comes to networking -- not any more than one single entry for North >> >America. What you will probably get is one entry per European network >> >provider, which would already be a big saving. >> >>Christian >> >>well, there might be a single provider one day soon >>the question is whether its BT+MCI or the new >>AT&T/FrenchPTT+Bundespost:-) >> >> jon +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Tony Rutkowski tel: +1 703 689 5080 | | Sprint International fax: +1 703 689 7718 | | 12490 Sunrise Valley Drive | | Reston VA 22096 | | USA | | Bringing Internetworking Services to the World | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 04:23:32 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13109; Thu, 11 Nov 1993 03:10:22 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA28240; Thu, 11 Nov 1993 03:09:39 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA28237; Thu, 11 Nov 1993 03:00:21 +1100 Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06989; Thu, 11 Nov 1993 00:49:00 +1100 (from kasten@ftp.com) Received: by ftp.com id AA01224; Wed, 10 Nov 93 08:44:54 -0500 Date: Wed, 10 Nov 93 08:44:54 -0500 Message-Id: <9311101344.AA01224@ftp.com> To: asp@uunet.uu.net Subject: Re: Statistics and the utilization of IP address space From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: vaf@valinor.stanford.edu, big-internet@munnari.OZ.AU Andrew, If I understand you properly, this is "simply" a hardware problem? Not enough ram in the box (maybe not enough address lines on the backplane -- sounds familiar, doesn't it?). The simplistic solution would be bigger router memories (and faster CPUs to do routing lookups over a larger table). Another possibility might be to use fewer interfaces per cpu -- thereby having more cpu per interface. Just some random thoughts before the morning caffeine kicks in. > > What is the basis for these numbers? Is it memory constraints? Is it > > constraints of the algorithms used to generate routes? Is it constraints > > in the protocols used to pass route information around? Is it simply a > > lack of CPU power in the routers? > > The RS6000s have space for 25,000 routes on their boards. My > understanding is that it is not possible to upgrade them any further. > Folks at ANS would have more details if you are interested. > > Some folks at cisco have done an estimate of the memory use of their > routers for holding BGP routes, and estimate that 16 Meg of memory will > be able to hold approx 28,000 to 29,000 routes. I do not know of any > cisco router that has more than 16 Meg of memory right now (it should > be possible to put 64 Meg in a cisco 7000, but I have never done it). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 05:09:45 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15256; Thu, 11 Nov 1993 03:55:15 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA28314; Thu, 11 Nov 1993 03:54:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA28311; Thu, 11 Nov 1993 03:43:18 +1100 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14714; Thu, 11 Nov 1993 03:43:28 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18026; Wed, 10 Nov 93 11:43:15 -0500 Date: Wed, 10 Nov 93 11:43:15 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9311101643.AA18026@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kasten@ftp.com Subject: Re: Statistics and the utilization of IP address space Cc: jnc@ginger.lcs.mit.edu If I understand you properly, this is "simply" a hardware problem? It's also a people problem; bigger routing tables mean more management and configuration. Not enough ram in the box (maybe not enough address lines on the backplane -- sounds familiar, doesn't it?). The simplistic solution would be bigger router memories (and faster CPUs to do routing lookups over a larger table). We are dealing with an exponential curve here, though... It's doubling somewhat faster than the chip feature size is being halved, so the exponential on memory chip sizes is not going to keep up. We need CIDR. Another possibility might be to use fewer interfaces per cpu -- thereby having more cpu per interface. This won't help. The problem is the size of the routing database; i.e. the number of destinations in the Internet. This is not related to the number of interfaces on the box.... Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 05:10:08 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18182; Thu, 11 Nov 1993 05:10:08 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA28477; Thu, 11 Nov 1993 05:09:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA28474; Thu, 11 Nov 1993 04:58:23 +1100 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17771; Thu, 11 Nov 1993 04:58:33 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12450(2)>; Wed, 10 Nov 1993 09:58:17 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 10 Nov 1993 09:58:07 -0800 To: big-internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: questions about backbone routing Date: Wed, 10 Nov 1993 09:57:53 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Nov10.095807pst.12171@skylark.parc.xerox.com> Someone told me recently that routing in the "backbone" networks is done on AS numbers rather than IP network numbers. I assumed he meant that the actual routing protocol exchanges were in terms of AS numbers, and that the forwarding decision consisted (logically) of mapping a packet's destination network number into an AS number and then looking up the AS number in the routing table. Is that true for all or any of the default-free transit networks? Is the backbone router problem with IP address space growth confined to the growth of a network-number-to-AS-number mapping table, or does it also include growth of routing protocol overhead (i.e, router- to-router updates and route computation time)? If routing were to be done in terms of AS numbers, would it be reasonable to store the mapping table (which would be less volatile than the dynamic routing table) on disk and keep only a cache of recently-used mappings in RAM, in order to reduce the amount of RAM required in routers? Steve From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 05:19:38 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16233; Thu, 11 Nov 1993 04:25:32 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA28368; Thu, 11 Nov 1993 04:24:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA28363; Thu, 11 Nov 1993 04:16:22 +1100 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB15860; Thu, 11 Nov 1993 04:16:07 +1100 (from asp@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA12175; Wed, 10 Nov 93 12:15:42 -0500 From: asp@uunet.uu.net (Andrew Partan) Message-Id: <9311101715.AA12175@rodan.UU.NET> Subject: Re: Statistics and the utilization of IP address space To: kasten@ftp.com Date: Wed, 10 Nov 1993 12:15:41 -0500 (EST) Cc: vaf@valinor.stanford.edu, big-internet@munnari.OZ.AU In-Reply-To: <9311101344.AA01224@ftp.com> from "Frank Kastenholz" at Nov 10, 93 08:44:54 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 576 > If I understand you properly, this is "simply" a hardware problem? > Not enough ram in the box (maybe not enough address lines on the > backplane -- sounds familiar, doesn't it?). Its "simply" a hardware problem. However, its also a real problem, unless you want to toss out nearly 100% of the exiting routers on the Internet & start over with something newer & bigger. Note that you have to do this w/in the year. We have to deply BGP4 and CIDR as fast as we can. There are no alternatives that I can see. "CIDR, default, or die." --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 05:25:36 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16345; Thu, 11 Nov 1993 04:28:59 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA28394; Thu, 11 Nov 1993 04:28:30 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA28355; Thu, 11 Nov 1993 04:11:17 +1100 Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15712; Thu, 11 Nov 1993 04:11:32 +1100 (from dkatz@cisco.com) Received: by large.cisco.com id AA16771 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Wed, 10 Nov 1993 09:11:11 -0800 Date: Wed, 10 Nov 1993 09:11:11 -0800 From: Dave Katz Message-Id: <199311101711.AA16771@large.cisco.com> To: craig@aland.bbn.com Cc: kasten@ftp.com, big-internet@munnari.OZ.AU In-Reply-To: Craig Partridge's message of Wed, 10 Nov 93 08:38:02 -0800 <9311101638.AA29543@aland.bbn.com> Subject: Statistics and the utilization of IP address space Not to be an apologist for the RS/6000s, but (a) they're certainly not five years old and they're probably not fully depreciated, and (b) it's not a lack of memory in the RS/6000 (I'm sure you can install gigs of real memory if you have megs of cash :-) ) but more likely a lack of memory in the interface cards, which is a thornier problem (lack of real estate, etc.) There are obvious workarounds to this problem, but they tend to radically change the dynamics of the system, which I would imagine the IBM folks are understandably nervous about. In any case, it's easy to say "just throw more memory at the problem," but the providers would presumably like to not have unbounded growth in the amount of money they have to spend on memory. It's also the case that it may be tough to make a business case for building a router with a huge amount of memory, because there's really not that much demand for them (thus exacerbating the cash problem for the providers). From: Craig Partridge Date: Wed, 10 Nov 93 08:38:02 -0800 Sender: craig@aland.bbn.com > If I understand you properly, this is "simply" a hardware problem? > Not enough ram in the box (maybe not enough address lines on the > backplane -- sounds familiar, doesn't it?). I tend to agree with this view, at least in part. RS6000s are old technology these days and if they don't have enough memory, we should throw them out and use a more current router. I'm not interested in changing the Internet routing architectures to save five year old, fully depreciated, systems. However, more broadly, as I understand matters, the cost of a given amount of memory is going down about 40% a year (same money buys 1.6 times as much memory as it did last year), while our routing table sizes are growing on the order of 150% a year (need 2.5 times as much memory next year as we do this year). So we have a long-term mismatch -- we need to get our routing table growth rate down to 60% a year or so to be safe. And that's CIDR's job. Craig From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 05:25:53 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17705; Thu, 11 Nov 1993 04:55:09 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA28432; Thu, 11 Nov 1993 04:54:40 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA28422; Thu, 11 Nov 1993 04:41:11 +1100 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17009; Thu, 11 Nov 1993 04:41:11 +1100 (from craig@aland.bbn.com) Received: from port10.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA13347 for big-internet@munnari.oz.au; Wed, 10 Nov 93 12:40:32 -0500 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA00416; Wed, 10 Nov 93 09:39:57 PST Message-Id: <9311101739.AA00416@aland.bbn.com> To: Dave Katz Cc: kasten@ftp.com, big-internet@munnari.OZ.AU Subject: re: Statistics and the utilization of IP address space From: Craig Partridge Date: Wed, 10 Nov 93 09:39:56 -0800 Sender: craig@aland.bbn.com Dave: Maybe my memory is playing tricks with me but I seem to recall the RS6000s were being tested in late '89, and since they are under 5 year depreciation rules, that means they're fully depreciated as of January 1st (or next July 1, depending on the ANS fiscal year). More generally, I think service providers have to accept that a certain amount of money must be regularly spent on equipment upgrades. Parts of this debate remind me of why folks stopped buying mainframes -- the support centers kept resisting capital spending. Craig From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 05:26:10 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17725; Thu, 11 Nov 1993 04:56:47 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA28458; Thu, 11 Nov 1993 04:56:18 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA28427; Thu, 11 Nov 1993 04:50:21 +1100 Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17442; Thu, 11 Nov 1993 04:50:31 +1100 (from dkatz@cisco.com) Received: by large.cisco.com id AA20798 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Wed, 10 Nov 1993 09:50:25 -0800 Date: Wed, 10 Nov 1993 09:50:25 -0800 From: Dave Katz Message-Id: <199311101750.AA20798@large.cisco.com> To: craig@aland.bbn.com Cc: kasten@ftp.com, big-internet@munnari.OZ.AU In-Reply-To: Craig Partridge's message of Wed, 10 Nov 93 09:39:56 -0800 <9311101739.AA00416@aland.bbn.com> Subject: Statistics and the utilization of IP address space My memory is hazy, but I believe that the RS/6000s went into production (such as it was) on 1/1/91. I don't know when the clock started for depreciation. I agree that there's a cost of doing business that the providers will have to deal with; however, the economic implications of carrying routing information are very interesting--those poor folks that need to have full or near-full routing may have their routing tables grow at a rate faster than income (since they not only have to carry their own customers' routes, but everybody elses customers' routes. But I think we're in violent agreement that CIDR is necessary. From: Craig Partridge Date: Wed, 10 Nov 93 09:39:56 -0800 Sender: craig@aland.bbn.com Dave: Maybe my memory is playing tricks with me but I seem to recall the RS6000s were being tested in late '89, and since they are under 5 year depreciation rules, that means they're fully depreciated as of January 1st (or next July 1, depending on the ANS fiscal year). More generally, I think service providers have to accept that a certain amount of money must be regularly spent on equipment upgrades. Parts of this debate remind me of why folks stopped buying mainframes -- the support centers kept resisting capital spending. Craig From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 08:05:43 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22888; Thu, 11 Nov 1993 06:55:39 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA28585; Thu, 11 Nov 1993 06:54:41 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA28582; Thu, 11 Nov 1993 06:40:49 +1100 Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22302; Thu, 11 Nov 1993 06:40:50 +1100 (from almes@ans.net) Received: by interlock.ans.net id AA21269 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Wed, 10 Nov 1993 14:39:22 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 10 Nov 1993 14:39:22 -0500 Date: Wed, 10 Nov 93 14:40:33 EST From: Guy Almes To: Craig Partridge Cc: big-internet@munnari.OZ.AU Subject: re: Statistics and the utilization of IP address space In-Reply-To: Your message of Wed, 10 Nov 93 09:39:56 -0800 Message-Id: Craig, We obviously agree. The RS/6000 routers have been upgraded several times, and will be upgraded again. And eventually, I'm sure, replaced. We acquired our RS/6000 routers mostly during 1991; you have to think of when most of them were acquired -- not when the first ones were. Your positive point about CIDR is one we very much endorse! We were active (with many others) in the work two years ago that led to CIDR, and we plan to deploy it within a month. -- Guy From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 08:10:10 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25989; Thu, 11 Nov 1993 08:10:10 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA28663; Thu, 11 Nov 1993 08:09:42 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA28660; Thu, 11 Nov 1993 08:07:38 +1100 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25864; Thu, 11 Nov 1993 08:07:14 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12484(2)>; Wed, 10 Nov 1993 13:06:50 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Wed, 10 Nov 1993 13:06:47 -0800 To: Tony Li Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: questions about backbone routing In-Reply-To: Your message of "Wed, 10 Nov 93 11:42:49 PST." <199311101942.AA00562@lager.cisco.com> Date: Wed, 10 Nov 1993 13:06:32 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Nov10.130647pst.12171@skylark.parc.xerox.com> > Please look down. One of your legs is missing. Someone has pulled it > clean off. ;-) Yes, I thought I felt a tug. That's why I posted my questions. Surprisingly, the person who claimed that backbone routing was based on AS numbers rather than network numbers is someone who usually knows what he is talking about. > c) The "backbone router problem" is with the size of the routing > table, not with address space growth. You're confusing trucks #2 and > #3 again. I was not confused (and what do you mean "again"?!) but my writing was less than clear. I should have referred to the backbone routing problem of insufficient address hierarchy or aggregation. > f) The real issue here is the speed of deployment of CIDR. I wasn't trying to suggest otherwise. Thanks for the clarifications, Tony. Steve From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 08:25:10 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26684; Thu, 11 Nov 1993 08:25:10 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA28696; Thu, 11 Nov 1993 08:24:43 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA28693; Thu, 11 Nov 1993 08:24:07 +1100 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22375; Thu, 11 Nov 1993 06:42:56 +1100 (from tli@cisco.com) Received: by lager.cisco.com id AA00562 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Wed, 10 Nov 1993 11:42:49 -0800 Date: Wed, 10 Nov 1993 11:42:49 -0800 From: Tony Li Message-Id: <199311101942.AA00562@lager.cisco.com> To: deering@parc.xerox.com (Steve Deering) Cc: big-internet@munnari.OZ.AU Subject: questions about backbone routing Steve, Please look down. One of your legs is missing. Someone has pulled it clean off. ;-) Someone told me recently that routing in the "backbone" networks is done on AS numbers rather than IP network numbers. I assumed he meant that the actual routing protocol exchanges were in terms of AS numbers, and that the forwarding decision consisted (logically) of mapping a packet's destination network number into an AS number and then looking up the AS number in the routing table. Is that true for all or any of the default-free transit networks? Is the backbone router problem with IP address space growth confined to the growth of a network-number-to-AS-number mapping table, or does it also include growth of routing protocol overhead (i.e, router- to-router updates and route computation time)? If routing were to be done in terms of AS numbers, would it be reasonable to store the mapping table (which would be less volatile than the dynamic routing table) on disk and keep only a cache of recently-used mappings in RAM, in order to reduce the amount of RAM required in routers? Facts: a) Routing in the "backbone" networks is done via BGP (or EGP, for those really ancient, non-progressive backbones). BGP propagates network numbers and routing is done on addresses, as always. b) Filtering is frequently done on AS number. c) The "backbone router problem" is with the size of the routing table, not with address space growth. You're confusing trucks #2 and #3 again. CPU time is NOT an issue. It is soley a problem in the amount of memory needed to hold the routing tables. d) The vast majority of all routers do not have a significant disk. e) Even if they did, you would not want to store the mapping table on disk. Consider the performance hit of a "page fault". Certain traffic patterns would cause the router to drop to 10s of packets per second (if that). f) The real issue here is the speed of deployment of CIDR. "CIDR, default or DIE" By Christmas. Tony From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 08:26:20 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26755; Thu, 11 Nov 1993 08:26:20 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA28722; Thu, 11 Nov 1993 08:25:50 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA28690; Thu, 11 Nov 1993 08:13:17 +1100 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19498; Thu, 11 Nov 1993 05:39:57 +1100 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18996; Wed, 10 Nov 93 13:39:49 -0500 Date: Wed, 10 Nov 93 13:39:49 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9311101839.AA18996@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: questions about backbone routing Cc: jnc@ginger.lcs.mit.edu Someone told me recently that routing in the "backbone" networks is done on AS numbers rather than IP network numbers. I assumed he meant that the actual routing protocol exchanges were in terms of AS numbers, and that the forwarding decision consisted (logically) of mapping a packet's destination network number into an AS number and then looking up the AS number in the routing table. This is not true, to the best of my knowledge. CIDR wouldn't really work if it were, since AS numbers are completely flat. There are a couple of ways they might have thought this: - The NSF policy database is in terms of AS's, so the "primary", "secondary" and "tertiary" *allowed* advertisers of routes to given destinations are in terms of AS's. - BGP includes AS's in the "path vector" information, but the routes are still to classic IP addresses (and masks, in BGP-4, which is CIDRized). - IDPR's toplogy maps are in terms of AS's, and to use IDPR you have to have a mapping from destination IP address to destination AS before you can construct an IDPR path. However, IDPR is not going to be used as the basic routing mechanism in the backbone. I'm not sure of the exact terminology for the first point, but that's the way it works. Is the backbone router problem with IP address space growth confined to the growth of a network-number-to-AS-number mapping table, or does it also include growth of routing protocol overhead (i.e, router- to-router updates and route computation time)? Assuming an approximately linear relationship between the "size" of the Internet and the number of AS's, doing routing on AS numbers would not help with the routing scaling problem, since the overhead of all routing algorithms grows as something like O(NlogN). The lack of hierarchy in AS numbers would soon make AS numbers useless for routing; hierarchy is the only way to combat routing overhead scaling, as far as I know... If routing were to be done in terms of AS numbers, would it be reasonable to store the mapping table (which would be less volatile than the dynamic routing table) on disk and keep only a cache of recently-used mappings in RAM, in order to reduce the amount of RAM required in routers? Wow! Here I am thinking that people are going to be unhappy with the time to instantiate a flow block when setting up a flow to a new destination! At least I don't have to spin "round brown"! :-) Noel From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 09:25:14 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29114; Thu, 11 Nov 1993 09:25:14 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA28777; Thu, 11 Nov 1993 09:24:43 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA28774; Thu, 11 Nov 1993 09:20:21 +1100 Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28938; Thu, 11 Nov 1993 09:19:59 +1100 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03864; Wed, 10 Nov 93 17:07:51 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA00459; Wed, 10 Nov 93 17:21:54 EST Date: Wed, 10 Nov 93 17:21:54 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9311102221.AA00459@cabernet.wellfleet> To: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: questions about backbone routing Cc: rcallon@wellfleet.com Someone told me recently that routing in the "backbone" networks is done on AS numbers rather than IP network numbers. I assumed he meant that the actual routing protocol exchanges were in terms of AS numbers, and that the forwarding decision consisted (logically) of mapping a packet's destination network number into an AS number and then looking up the AS number in the routing table. Is that true for all or any of the default-free transit networks? Is the backbone router problem with IP address space growth confined to the growth of a network-number-to-AS-number mapping table, or does it also include growth of routing protocol overhead (i.e, router- to-router updates and route computation time)? If routing were to be done in terms of AS numbers, would it be reasonable to store the mapping table (which would be less volatile than the dynamic routing table) on disk and keep only a cache of recently-used mappings in RAM, in order to reduce the amount of RAM required in routers? Steve; Two questions: First, did someone say that it *was* being done this way, or that it *could* be done this way? Also, did they say based on *AS Number*, or based on *Provider*. Clearly, you *could* in principle route based on provider, and use a relatively static "network number to provider" map, along with a somewhat more dynamic "provider to route" map. However, this is of course not the way that it is done today. It appears that CIDR has eliminated the need to even consider such a drastic change in how we do routing. Ross From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 18:11:18 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19130; Thu, 11 Nov 1993 18:11:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA29222; Thu, 11 Nov 1993 18:10:03 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA29216; Thu, 11 Nov 1993 17:56:07 +1100 Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18808; Thu, 11 Nov 1993 17:56:21 +1100 (from hwb@upeksa.sdsc.edu) Received: by upeksa.sdsc.edu (AIX 3.2/UCB 5.64/4.03) id AA14396; Wed, 10 Nov 1993 22:56:18 -0800 From: hwb@upeksa.sdsc.edu (Hans-Werner Braun) Message-Id: <9311110656.AA14396@upeksa.sdsc.edu> Subject: Re: questions about backbone routing To: deering@parc.xerox.com (Steve Deering) Date: Wed, 10 Nov 93 22:56:18 PST Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <93Nov10.095807pst.12171@skylark.parc.xerox.com>; from "Steve Deering" at Nov 10, 93 9:57 am Steve: Since 1988 the NSFNET backbone had been for packet forwarding decisions first mapped the destination IP address to an AS number, and then via a second table mapped the AS number to the next hop gateway. This made certain re-mappings easier. Hans-Werner From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 18:40:37 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20259; Thu, 11 Nov 1993 18:40:37 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA29264; Thu, 11 Nov 1993 18:40:04 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA29258; Thu, 11 Nov 1993 18:36:04 +1100 Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20092; Thu, 11 Nov 1993 18:36:15 +1100 (from jgs@merit.edu) Received: from localhost.merit.edu by merit.edu (5.65/1123-1.0) id AA09509; Thu, 11 Nov 93 02:36:54 -0500 Date: Thu, 11 Nov 93 02:36:54 -0500 From: "John Scudder" Message-Id: <9311110736.AA09509@merit.edu> To: merit.big-internet@merit.edu Newsgroups: merit.big-internet Subject: Re: questions about backbone routing References: <93Nov10.095807pst.12171@skylark.parc.xerox.com> Organization: Merit Network, Inc. (Ann Arbor, MI) I think a little history is in order to clear up some misconceptions I saw posted in response to this article: In article <93Nov10.095807pst.12171@skylark.parc.xerox.com> Steve Deering writes: > Someone told me recently that routing in the "backbone" networks is done > on AS numbers rather than IP network numbers. I assumed he meant that the > actual routing protocol exchanges were in terms of AS numbers, and that the > forwarding decision consisted (logically) of mapping a packet's destination > network number into an AS number and then looking up the AS number in the > routing table. Is that true for all or any of the default-free transit > networks? Is the backbone router problem with IP address space growth > confined to the growth of a network-number-to-AS-number mapping table, > or does it also include growth of routing protocol overhead (i.e, router- > to-router updates and route computation time)? If routing were to be done > in terms of AS numbers, would it be reasonable to store the mapping table > (which would be less volatile than the dynamic routing table) on disk and > keep only a cache of recently-used mappings in RAM, in order to reduce the > amount of RAM required in routers? > > Steve In fact, this is not all wrong, as a few responders claimed. (It's just a little garbled.) The source of this notion is most likely the fact that the NSFNET routers, until recently, actually forwarded packets via a recursive lookup: First the network address was looked up in a net-to-AS mapping table (which we used to call the "-N" table in the bad old days, in reference to the option to the hacked-up route command one used to look at it), then the AS was looked up in a so-called "regional routes" AS-to-next-hop table (called the "-R" table for similar reasons). Regular old ("-r") routing tables were only used for last-hop routing. The routing carries the AS->next-hop and the internal topology information in the IGP and the net->AS info in IBGP. (Well, this is true of the RS/6000 routers. Let us say no more of the RTs.) The recursive lookup at forwarding time basically trades complexity in the forwarder for a simpler routing daemon (the other option is to have the routing daemon do the net->AS->next hop lookup for itself). You'll have to ask someone who was there when this was designed what the motivations were for taking this path. In other words, Steve's conjecture about the routing was half-right: The lookup is pretty much as he describes, but the routing protocols carry ALL the nets around: IBGP gives you the net->AS mapping, and the IGP give you AS->next-hop. In response to another of Steve's questions, the eGP routing exchanges did and still are do carry network numbers, not just ASes. By the way, this approach is not used on the RS/6000 routers any more, I think since the move from AIX 3.1 to AIX 3.2 on the backbone routers. The routing daemon still thinks it's installing AS and net routes, but an intermediate layer does the lookup and feeds the kernel routing table with plain old net->next-hop mappings. (I think this is right; my memory is a bit fuzzy on the subject and it's late.) When rcp_routed is replaced by gated the last vestige of the old approach will go away. This approach has never, to my knowledge, been used anywhere other than the NSFNET. Oh, and by the way, if you really want to store all of your net->AS mappings on disk you don't need to separate them out explicitly, just keep a big routing table on a router with not too much RAM but lots of swap (hint: this turns out to be a big loser in the real world). --John Scudder From owner-Big-Internet@munnari.OZ.AU Thu Nov 11 23:15:59 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24319; Thu, 11 Nov 1993 20:26:41 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA29371; Thu, 11 Nov 1993 20:25:05 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA29353; Thu, 11 Nov 1993 20:10:03 +1100 Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20871; Thu, 11 Nov 1993 18:52:36 +1100 (from dkatz@cisco.com) Received: by large.cisco.com id AA07895 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Wed, 10 Nov 1993 23:52:14 -0800 Date: Wed, 10 Nov 1993 23:52:14 -0800 From: Dave Katz Message-Id: <199311110752.AA07895@large.cisco.com> To: jgs@merit.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: "John Scudder"'s message of Thu, 11 Nov 93 02:36:54 -0500 <9311110736.AA09509@merit.edu> Subject: questions about backbone routing One of the original motivations was the fact that each route in 4.3BSD took an mbuf; there was only 4MB of RAM in the RTs, so using individual route entries for every destination net would quickly exhaust memory. Instead, the net->AS mapping was in a densely packed table, and the AS->next hop mapping was in individual mbufs. Another motivation was the observation that oftentimes (basically close to always) whole blocks of routes would change together. (If a link in the middle of the backbone goes down, all routes going out the same exit point would change the same way.) This fact was leveraged in the protocol between the RCP and PSPs; just a single short message could be downloaded (a new route to the AS) rather than a whole slew of routes. There are probably other things that fell out of this design, but this is ancient history. (Funny how quickly things become ancient in this business.) Date: Thu, 11 Nov 93 02:36:54 -0500 From: "John Scudder" Newsgroups: merit.big-internet References: <93Nov10.095807pst.12171@skylark.parc.xerox.com> Organization: Merit Network, Inc. (Ann Arbor, MI) I think a little history is in order to clear up some misconceptions I saw posted in response to this article: In article <93Nov10.095807pst.12171@skylark.parc.xerox.com> Steve Deering writes: > Someone told me recently that routing in the "backbone" networks is done > on AS numbers rather than IP network numbers. I assumed he meant that the > actual routing protocol exchanges were in terms of AS numbers, and that the > forwarding decision consisted (logically) of mapping a packet's destination > network number into an AS number and then looking up the AS number in the > routing table. Is that true for all or any of the default-free transit > networks? Is the backbone router problem with IP address space growth > confined to the growth of a network-number-to-AS-number mapping table, > or does it also include growth of routing protocol overhead (i.e, router- > to-router updates and route computation time)? If routing were to be done > in terms of AS numbers, would it be reasonable to store the mapping table > (which would be less volatile than the dynamic routing table) on disk and > keep only a cache of recently-used mappings in RAM, in order to reduce the > amount of RAM required in routers? > > Steve In fact, this is not all wrong, as a few responders claimed. (It's just a little garbled.) The source of this notion is most likely the fact that the NSFNET routers, until recently, actually forwarded packets via a recursive lookup: First the network address was looked up in a net-to-AS mapping table (which we used to call the "-N" table in the bad old days, in reference to the option to the hacked-up route command one used to look at it), then the AS was looked up in a so-called "regional routes" AS-to-next-hop table (called the "-R" table for similar reasons). Regular old ("-r") routing tables were only used for last-hop routing. The routing carries the AS->next-hop and the internal topology information in the IGP and the net->AS info in IBGP. (Well, this is true of the RS/6000 routers. Let us say no more of the RTs.) The recursive lookup at forwarding time basically trades complexity in the forwarder for a simpler routing daemon (the other option is to have the routing daemon do the net->AS->next hop lookup for itself). You'll have to ask someone who was there when this was designed what the motivations were for taking this path. In other words, Steve's conjecture about the routing was half-right: The lookup is pretty much as he describes, but the routing protocols carry ALL the nets around: IBGP gives you the net->AS mapping, and the IGP give you AS->next-hop. In response to another of Steve's questions, the eGP routing exchanges did and still are do carry network numbers, not just ASes. By the way, this approach is not used on the RS/6000 routers any more, I think since the move from AIX 3.1 to AIX 3.2 on the backbone routers. The routing daemon still thinks it's installing AS and net routes, but an intermediate layer does the lookup and feeds the kernel routing table with plain old net->next-hop mappings. (I think this is right; my memory is a bit fuzzy on the subject and it's late.) When rcp_routed is replaced by gated the last vestige of the old approach will go away. This approach has never, to my knowledge, been used anywhere other than the NSFNET. Oh, and by the way, if you really want to store all of your net->AS mappings on disk you don't need to separate them out explicitly, just keep a big routing table on a router with not too much RAM but lots of swap (hint: this turns out to be a big loser in the real world). --John Scudder From owner-Big-Internet@munnari.OZ.AU Fri Nov 12 07:27:17 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13569; Fri, 12 Nov 1993 04:26:10 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA29849; Fri, 12 Nov 1993 04:25:07 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA29835; Fri, 12 Nov 1993 04:15:50 +1100 Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13116; Fri, 12 Nov 1993 04:15:18 +1100 (from curtis@ans.net) Received: by interlock.ans.net id AA10131 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 11 Nov 1993 12:13:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 11 Nov 1993 12:13:40 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 11 Nov 1993 12:13:40 -0500 From: Curtis Villamizar Message-Id: <199311111714.AA63541@foo.ans.net> To: big-internet@munnari.OZ.AU Cc: Mark Knopper , rcallon@wellfleet.com (Ross Callon), deering@parc.xerox.com, curtis@ans.net Subject: Re: questions about backbone routing (LONG) Date: Thu, 11 Nov 93 12:14:50 -0500 To whom it may confuse, Rumor has it that there is a discussion of how routing and forwarding is done on the ANSnet backbone (as opposed to one of the other major backbones - routine flamage avoidance). I don't read big-internet so I've missed this discussion (see attached). I maintain the current routing code, so hopefully I understand how this works :). While I'm at it, I'll give some background. The backbone routers are called NSS (Network Switching Systems) for some archane reason. These are all IBM RS/6K with specially designed forwarding cards for HSSI (T3), FDDI, V.35 (T1) and ethernet. The Core NSS (CNSS) sit within the backbone itself and generally don't announce external routes (with an exception explained shortly). End System NSS (ENSS) sit on customer premise and always announce external routes. The CNSS are colocated at a given carrier Point of Presence (POP). There are typically 3-4 CNSS at a POP. CNSS are designated as either T3-B, T3-C, and T1-C. The T3-B CNSS (backbone) terminates the T3 backbone links to other POPs. The T3-C CNSS (T3 concentrator) terminates T3 ENSS circuits. The T1-C CNSS (T1 concentrator) terminate T1 attached ENSS and also serve the 56K concentrator at the POP which is a Cisco router. The 56K concentrators are not in AS 690 (the ANS backbone AS number) and so the T1-C CNSS advertise external routes (slightly blurring the CNSS/ENSS designation). All of the CNSS and ENSS comprise AS 690. We are currently in the process of changing the connectivity within the POP (between T3-B, T3-C and T1-C) from null HSSI connections to a FDDI ring as part of a hardware upgrade. The interior routing protocol (or interior gateway protocol - IGP) carries only routes considered internal to AS 690. The IGP is an early version of ISIS predating standardization. Since it is not compatible with the ISIS that was standardized, we sometimes call it SLSP (simple link state protocol) particularly in gated which now implements both. SLSP carries only routes to the backbone routers themselves and carries routes to each AS announced by an exterior routing protocol (or exterior gateway protocol - egp). There are two supported egp - the EGP protocol (which has miserable characterisitic) and the Border Gateway Protocol (BGP-2). The external routes are carried by IBGP (Internal BGP) from the NSS where the route is advertised to all other NSS. This means that every NSS that announces external networks must have an IBGP session with every other NSS. NSS that do not announce external nets do not need IBGP sessions to other NSS that do not announce external nets. At every ENSS we validate all of the network announcements against a list (to prevent misconfigurations made elsewhere from propogating and unauthorized use of NSFNET funded facilities - flames to /dev/null please). In doing so we also assign a policy metric. We propogate the announcement (of the best route at that NSS) via IBGP with the policy metric carried in the InterAS metric attribute (as LOCAL_PREF is now defined for BGP4). This use of InterAS metric is not standards compliant, but we also use the authentication field in IBGP. We remain standards compliant in external BGP (EBGP). At each node receiving an IBGP update, the policy metric is compared with any other route available and the best is chosen. This is used to map the network number to the AS number announcing the route. Before installing the route, the best route to that AS is found, which was learned from SLSP and contains an IP address as the next hop. The two peices of information are combined in the routing daemon and the route that gets installed in the forwarding table maps the destination IP address to a next hop IP address. Prior to AIX 3.2, the mapping was done at forwarding time. A prior (at least perceived) benefit of the two stage mapping performed at forwarding time was that if an internal route was changed, only a single route change needed to be made. By moving this to the routing daemon, often thousands of route changes need to be made. BTW - The answer is to make route installation fast and keep internal routing stable. A consequence of involving the AS number in routing is that if an AS touches AS 690 at two places, AS 690 will forward to the nearest exit point to that AS. This is not usually desirable. If AS 690 is faster or less congested than the other AS, a more desirable way to route is to set policy at each entry point so that the primary exit point from AS 690 will be to the entry point to the other AS which has the shortest internal distance within the other AS when all links are up. If the other AS routes to the closest exit point to AS 690, the routing will be symetric (considered goodness) and have the least impact on the slower or more congested network. In order to accomplish this, another AS number is artificially introduced at some of the exit points. Requiring this additional AS number is considered undesirable. Much of the discussion (that I've seen up to now) has to do with the need for these extra AS numbers. Because the AS number mapping is only done within the routing daemon and eventually resolves to an IP address next hop, an alternate mapping could be used. The IBGP also implicitely carries the NSS number and explicitly carries the next hop which is an address on the peer router. SLSP only carries routes to the other NSS. The existing routing daemon could be changed to map destination network to NSS and NSS to IP address next hop. This is done by gated, which should be replacing rcp_routed very soon. Had it not been for the fact that rcp_routed is scheduled to be replaced very soon, this would also be changed in rcp_routed (and at least BGP-3 implemented since it is just a matter of changing the BGP open). This will eliminate the need for extra AS numbers. A change has already been made to the configuration database to allow an AS number and NSS number to be associated with policy metric and used to generate configurations. Some time after gated gets deployed, we will be switching from SLSP to a standards compliant ISIS. ISIS is capable of carrying the routes to the NSS external interfaces. This will enable us to map from destination address to IBGP next hop to ISIS next hop. This brings us in full compliance in our IBGP usage (except that we use the authentication field). What was the question again? :-) BTW - (looking at the discussions below) the mapping from destination network to AS number is not at all static, it is constantly changing. The average network is announced by 2-1/2 AS numbers and we only use the primary path about 95% of the time (OK often over 95% - the last figure I saw was 96% based on the offnet statistical sampling). That means that on average 5% of the paths are to secondary AS. The more the world topology changes from a hierarchy (which it clearly is not today) to a well connected mesh, the more dynamic that mapping will be (unless the whole topology gets a lot more stable). Storing this on disk is absurd (sorry Ross - OK, I'll be nice - not feasible :). BTW2 - The scaling problems have to do with lots of routes requiring lots of memory and the frequency with which those routes change. The latter currently requires processing power within the main processor and processing power within the forwarding engine to keep changing cache entries while simultaneously forwarding lots of packets. This is where today's commercial routers currently fall flat on their face. We have addressed this very thoroughly in the NSS routers and are now proposing means to dampen route oscillations when propogating route changes without reducing route convergence time for well behaved routes. This will help reduce the burden on routers outside ANSnet and may reduce route flap due to these routers getting CPU overloaded. In the worst case, we could see sustained oscillations. We have reported the levels of route flap observed advertised to us by BGP in the last 3-4 IETFs. We have seen growth from ~1,000 destinations declared unreachable per hour to ~2,000 per hour over the past ten months (see attached plot). There is some evidience that briefly sustained oscillations may already be occurring in parts of the Internet. Stay tuned to joint IDRP/BGP WG for details. Back to work now. I don't read big-internet and problably won't have the time to follow up on questions. Curtis =========================================================================== Curtis Villamizar Advanced Network & Services 100 Clearbrook Road ** #include ** Elmsford, NY 10523 ------- Forwarded Message Received: from interlock.ans.net by home.ans.net with SMTP id AA100713 (5.65c/IDA-1.4.4 for ); Wed, 10 Nov 1993 21:28:43 -0500 Received: from merit.edu by interlock.ans.net with SMTP id AA26008 (InterLock SMTP Gateway 1.1 for ); Wed, 10 Nov 1993 21:27:28 -0500 Return-Path: Received: by merit.edu (5.65/1123-1.0) id AA22144; Wed, 10 Nov 93 21:29:15 -0500 Message-Id: <9311110229.AA22144@merit.edu> To: curtis@ans.net Subject: questions about backbone routing Date: Wed, 10 Nov 1993 21:29:14 -0500 From: Mark Knopper Curtis, There is a somewhat confused discussion going on in big-internet about whether backbone routing is done by AS numbers or destination IP net numbers. Presumably the answer is that this is the way things used to work pre-3.2 but not any more. Perhaps you could sent a note and clarify this? Mark > From: rcallon@wellfleet.com (Ross Callon) > To: big-internet@munnari.oz.au, deering@parc.xerox.com > CC: rcallon@wellfleet.com > > > Someone told me recently that routing in the "backbone" networks is don e > on AS numbers rather than IP network numbers. I assumed he meant that the > actual routing protocol exchanges were in terms of AS numbers, and that the > forwarding decision consisted (logically) of mapping a packet's destina tion > network number into an AS number and then looking up the AS number in t he > routing table. Is that true for all or any of the default-free transit > networks? Is the backbone router problem with IP address space growth > confined to the growth of a network-number-to-AS-number mapping table, > or does it also include growth of routing protocol overhead (i.e, route r- > to-router updates and route computation time)? If routing were to be d one > in terms of AS numbers, would it be reasonable to store the mapping tab le > (which would be less volatile than the dynamic routing table) on disk a nd > keep only a cache of recently-used mappings in RAM, in order to reduce the > amount of RAM required in routers? > > Steve; > > Two questions: > > First, did someone say that it *was* being done this way, or that > it *could* be done this way? > > Also, did they say based on *AS Number*, or based on *Provider*. > > Clearly, you *could* in principle route based on provider, and > use a relatively static "network number to provider" map, along > with a somewhat more dynamic "provider to route" map. However, > this is of course not the way that it is done today. It appears > that CIDR has eliminated the need to even consider such a drastic > change in how we do routing. > > Ross > ------- End of Forwarded Message %!PS-Adobe-2.0 %%Creator: gnuplot %%DocumentFonts: Courier %%BoundingBox: 50 50 554 770 %%Pages: (atend) %%EndComments /gnudict 40 dict def gnudict begin /Color false def /gnulinewidth 5.000 def /vshift -46 def /dl {10 mul} def /hpt 31.5 def /vpt 31.5 def /vpt2 vpt 2 mul def /hpt2 hpt 2 mul def /Lshow { currentpoint stroke moveto 0 vshift rmoveto show } def /Rshow { currentpoint stroke moveto dup stringwidth pop neg vshift rmoveto show } def /Cshow { currentpoint stroke moveto dup stringwidth pop -2 div vshift rmoveto show } def /DL { Color {setrgbcolor [] 0 setdash pop} {pop pop pop 0 setdash} ifelse } def /BL { stroke gnulinewidth 2 mul setlinewidth } def /AL { stroke gnulinewidth 2 div setlinewidth } def /PL { stroke gnulinewidth setlinewidth } def /LTb { BL [] 0 0 0 DL } def /LTa { AL [1 dl 2 dl] 0 setdash 0 0 0 setrgbcolor } def /LT0 { PL [] 0 1 0 DL } def /LT1 { PL [4 dl 2 dl] 0 0 1 DL } def /LT2 { PL [2 dl 3 dl] 1 0 0 DL } def /LT3 { PL [1 dl 1.5 dl] 1 0 1 DL } def /LT4 { PL [5 dl 2 dl 1 dl 2 dl] 0 1 1 DL } def /LT5 { PL [4 dl 3 dl 1 dl 3 dl] 1 1 0 DL } def /LT6 { PL [2 dl 2 dl 2 dl 4 dl] 0 0 0 DL } def /LT7 { PL [2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 1 0.3 0 DL } def /LT8 { PL [2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 2 dl 4 dl] 0.5 0.5 0.5 DL } def /M {moveto} def /L {lineto} def /P { stroke [] 0 setdash currentlinewidth 2 div sub moveto 0 currentlinewidth rlineto stroke } def /D { stroke [] 0 setdash 2 copy vpt add moveto hpt neg vpt neg rlineto hpt vpt neg rlineto hpt vpt rlineto hpt neg vpt rlineto closepath stroke P } def /A { stroke [] 0 setdash vpt sub moveto 0 vpt2 rlineto currentpoint stroke moveto hpt neg vpt neg rmoveto hpt2 0 rlineto stroke } def /B { stroke [] 0 setdash 2 copy exch hpt sub exch vpt add moveto 0 vpt2 neg rlineto hpt2 0 rlineto 0 vpt2 rlineto hpt2 neg 0 rlineto closepath stroke P } def /C { stroke [] 0 setdash exch hpt sub exch vpt add moveto hpt2 vpt2 neg rlineto currentpoint stroke moveto hpt2 neg 0 rmoveto hpt2 vpt2 rlineto stroke } def /T { stroke [] 0 setdash 2 copy vpt 1.12 mul add moveto hpt neg vpt -1.62 mul rlineto hpt 2 mul 0 rlineto hpt neg vpt 1.62 mul rlineto closepath stroke P } def /S { 2 copy A C} def end %%EndProlog %%Page: 1 1 gnudict begin gsave 50 50 translate 0.100 0.100 scale 90 rotate 0 -5040 translate 0 setgray /Courier findfont 140 scalefont setfont newpath LTa 1008 491 M 6969 491 L 1008 491 M 1008 4689 L LTb 1008 491 M 1071 491 L 6969 491 M 6906 491 L 924 491 M (0) Rshow 1008 1239 M 1071 1239 L 6969 1239 M 6906 1239 L 924 1239 M (2000) Rshow 1008 1988 M 1071 1988 L 6969 1988 M 6906 1988 L 924 1988 M (4000) Rshow 1008 2736 M 1071 2736 L 6969 2736 M 6906 2736 L 924 2736 M (6000) Rshow 1008 3484 M 1071 3484 L 6969 3484 M 6906 3484 L 924 3484 M (8000) Rshow 1008 4233 M 1071 4233 L 6969 4233 M 6906 4233 L 924 4233 M (10000) Rshow 1008 491 M 1008 554 L 1008 4689 M 1008 4626 L 1008 351 M (Jan 1) Cshow 6397 491 M 6397 554 L 6397 4689 M 6397 4626 L 6397 351 M (Oct 1) Cshow 1620 491 M 1620 554 L 1620 4689 M 1620 4626 L 1620 351 M (Feb 1) Cshow 2173 491 M 2173 554 L 2173 4689 M 2173 4626 L 2173 351 M (Mar 1) Cshow 2784 491 M 2784 554 L 2784 4689 M 2784 4626 L 2784 351 M (Apr 1) Cshow 3377 491 M 3377 554 L 3377 4689 M 3377 4626 L 3377 351 M (May 1) Cshow 3989 491 M 3989 554 L 3989 4689 M 3989 4626 L 3989 351 M (Jun 1) Cshow 4581 491 M 4581 554 L 4581 4689 M 4581 4626 L 4581 351 M (Jul 1) Cshow 5193 491 M 5193 554 L 5193 4689 M 5193 4626 L 5193 351 M (Aug 1) Cshow 5804 491 M 5804 554 L 5804 4689 M 5804 4626 L 5804 351 M (Sep 1) Cshow LTb 1008 491 M 6969 491 L 6969 4689 L 1008 4689 L 1008 491 L 3988 4829 M (External Route Flap \(EBGP+EGP\) - unreachable routes / hour) Cshow LT0 LT0 6486 4486 M () Rshow 6570 4486 M 6822 4486 L 1047 603 M 1047 603 L 1067 613 L 1087 683 L 1107 1010 L 1126 801 L 1146 793 L 1166 987 L 1186 618 L 1205 730 L 1225 784 L 1245 844 L 1265 690 L 1284 727 L 1304 800 L 1324 751 L 1344 599 L 1363 662 L 1383 818 L 1403 727 L 1423 732 L 1442 825 L 1462 621 L 1482 1065 L 1501 745 L 1521 764 L 1541 881 L 1561 2167 L 1580 831 L 1600 660 L 1620 678 L 1659 866 L 1679 861 L 1699 789 L 1719 1000 L 1738 1108 L 1758 954 L 1778 1064 L 1798 1094 L 1817 735 L 1837 771 L 1857 737 L 1876 623 L 1896 651 L 1916 748 L 1936 801 L 1955 735 L 1975 951 L 1995 816 L 2015 618 L 2034 665 L 2054 734 L 2074 878 L 2094 811 L 2113 792 L 2133 965 L 2153 667 L 2173 678 L 2212 868 L 2232 1442 L 2252 945 L 2271 1045 L 2291 776 L 2311 706 L 2330 766 L 2350 926 L 2370 779 L 2390 947 L 2409 949 L 2429 678 L 2449 952 L 2469 701 L 2488 940 L 2508 851 L 2528 1022 L 2548 1257 L 2567 810 L 2587 791 L 2607 890 L 2627 957 L 2646 931 L 2666 808 L 2686 1010 L 2706 802 L 2725 738 L 2745 918 L 2765 1144 L 2784 777 L 2824 915 L 2844 856 L 2863 747 L 2883 850 L 2903 826 L 2923 992 L 2942 1219 L 2962 981 L 2982 733 L 3002 700 L 3021 710 L 3041 972 L 3061 989 L 3081 922 L 3100 968 L 3120 684 L 3140 957 L 3159 1104 L 3179 1085 L 3199 1109 L 3219 800 L 3238 871 L 3258 784 L 3278 589 L 3298 864 L 3317 880 L 3337 751 L 3357 809 L 3377 843 L 3416 807 L 3436 797 L 3456 920 L 3475 892 L 3495 801 L 3515 899 L 3535 728 L 3653 1039 L 3673 765 L 3692 916 L 3712 815 L 3732 910 L 3752 866 L 3771 836 L 3791 1014 L 3811 1151 L 3831 703 L 3850 713 L 3870 1140 L 3890 992 L 3910 855 L 3929 1553 L 3949 986 L 3969 696 L 3989 1087 L 4028 1226 L 4048 881 L 4067 933 L 4087 1678 L 4107 884 L 4146 1119 L 4166 1072 L 4186 1015 L 4206 996 L 4225 853 L 4245 670 L 4265 1070 L 4285 1533 L 4304 1319 L 4324 1195 L 4344 953 L 4364 750 L 4383 758 L 4403 1462 L 4423 1551 L 4442 1007 L 4462 920 L 4482 1070 L 4502 880 L 4521 705 L 4541 865 L 4561 1049 L 4581 1688 L 4620 897 L 4640 730 L 4660 753 L 4679 1415 L 4699 1102 L 4719 1202 L 4739 1450 L 4758 1752 L 4778 1172 L 4798 1348 L 4818 1505 L 4837 1270 L 4857 1122 L 4877 1123 L 4896 1273 L 4916 972 L 4936 1121 L 4956 1103 L 4975 1336 L 4995 975 L 5015 784 L 5035 1246 L 5054 1679 L 5074 1133 L 5094 1026 L 5114 808 L 5133 1128 L 5153 1484 L 5173 1243 L 5193 961 L 5311 1976 L 5331 828 L 5350 796 L 5370 1029 L 5390 1158 L 5410 1201 L 5429 1366 L 5449 2314 L 5469 1146 L 5489 978 L 5508 1225 L 5528 1375 L 5548 967 L 5568 1208 L 5587 1508 L 5607 865 L 5627 1131 L 5647 1140 L 5666 989 L 5686 1390 L 5706 1069 L 5725 1339 L 5745 1147 L 5765 931 L 5785 994 L 5804 929 L 5923 1353 L 5943 958 L 5962 1175 L 5982 1491 L 6002 1565 L 6022 864 L 6041 915 L 6061 1650 L 6081 1609 L 6101 1525 L 6120 1266 L 6140 2657 L 6160 993 L 6179 900 L 6199 1242 L 6219 1537 L 6239 1791 L 6258 2218 L 6278 1574 L 6298 801 L 6318 1011 L 6337 1243 L 6357 1405 L 6377 1504 L 6397 1441 L 6436 901 L 6456 892 L 6476 1201 L 6495 1299 L 6515 1359 L 6535 1349 L 6554 1514 L 6574 916 L 6594 1099 L 6614 1146 L 6633 1301 L 6653 1492 L 6673 1333 L 6693 1389 L 6712 862 L 6732 932 L 6752 1244 L 6772 1410 L 6791 1449 L 6811 1157 L 6831 1401 L 6851 919 L 6870 1264 L 6890 1246 L 6910 1355 L 6930 4308 L 6949 2015 L LT1 6486 4346 M () Rshow 6570 4346 M 6822 4346 L 1314 807 M 1314 807 L 1896 819 L 2479 904 L 3081 880 L 3683 915 L 4285 1075 L 4887 1170 L 5498 1192 L 6101 1387 L 6703 1361 L stroke grestore end showpage %%Trailer %%Pages: 1 From owner-Big-Internet@munnari.OZ.AU Fri Nov 12 12:31:48 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29154; Fri, 12 Nov 1993 10:43:40 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA00271; Fri, 12 Nov 1993 10:40:09 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA00257; Fri, 12 Nov 1993 10:38:19 +1100 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23342; Fri, 12 Nov 1993 08:38:37 +1100 (from bound@zk3.dec.com) Received: by inet-gw-1.pa.dec.com; id AA24576; Thu, 11 Nov 93 13:37:28 -0800 Received: by xirtlu.zk3.dec.com; id AA09669; Thu, 11 Nov 1993 16:36:06 -0500 Message-Id: <9311112136.AA09669@xirtlu.zk3.dec.com> To: Curtis Villamizar Cc: big-internet@munnari.OZ.AU, Mark Knopper , rcallon@wellfleet.com (Ross Callon), deering@parc.xerox.com Subject: Re: questions about backbone routing (LONG) In-Reply-To: Your message of "Thu, 11 Nov 93 12:14:50 EST." <199311111714.AA63541@foo.ans.net> Date: Thu, 11 Nov 93 16:36:00 -0500 X-Mts: smtp Thanks for the clarity and depth. I was beginning to feel like I was in the YIN and YANG at the same time. Steve is right ..oh Steve is half right. Seems like Steve was right. I wont ask more questions but it relates indirectly to how I am designing a translator on a Host. thanks again, /jim From owner-Big-Internet@munnari.OZ.AU Sat Nov 13 12:05:06 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26896; Sat, 13 Nov 1993 09:59:19 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA01429; Sat, 13 Nov 1993 09:55:19 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA01415; Sat, 13 Nov 1993 09:41:40 +1100 Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26127; Sat, 13 Nov 1993 09:41:39 +1100 (from solensky@ftp.com) Received: from solensky.fenway.ftp.com by ftp.com via PCMAIL with DMSP id AA16899; Fri, 12 Nov 93 17:41:09 -0500 Date: Fri, 12 Nov 93 17:41:09 -0500 Message-Id: <9311122241.AA16899@ftp.com> To: ietf@cnri.reston.va.us, big-internet@munnari.OZ.AU Subject: Forwarded: 'IPv4-ALE' list From: solensky@ftp.com (Frank T Solensky) Sender: solensky@ftp.com Repository: babyoil.ftp.com Originating-Client: fenway.ftp.com >Date: Fri, 12 Nov 93 14:43:00 -0500 >To: ipv4-ale@ftp.com >From: solensky@ftp.com (Frank T Solensky) > >The 'ipv4-ale' list is now set up. The initial membership is made up >of [most of] the people who signed the attendence sheet at the BOF >last week plus a few others. > >As always, list add/change/remove requests should be sent to >"ipv4-ale-request@ftp.com". The list is being archived; I should be >able to tell you exactly where you can access it from by Monday. > >For the first couple days, error messages may get bounced back to >the message originator rather than the administrator. That should >also be corrected by Monday. The first discussion item will be to put the finishing touches on the working group charter. The main goals of the working group that Tony Li and I will be co-chairing will be to develop an estimate for the remaining lifetime for the IPv4 address space and to analyze the impact that various changes in address assignment policy will have. > -- Frank From owner-Big-Internet@munnari.OZ.AU Sat Nov 13 12:26:23 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02983; Sat, 13 Nov 1993 12:26:23 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA01567; Sat, 13 Nov 1993 12:25:20 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA01553; Sat, 13 Nov 1993 12:22:59 +1100 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29418; Sat, 13 Nov 1993 10:59:06 +1100 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12358(1)>; Fri, 12 Nov 1993 15:58:36 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 12 Nov 1993 15:57:50 -0800 To: big-internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: address space consumption Date: Fri, 12 Nov 1993 15:57:36 PST Sender: Steve Deering From: Steve Deering Message-Id: <93Nov12.155750pst.12171@skylark.parc.xerox.com> Here's a question for the new ALE WG, sent to the big-internet list because I don't think there's an ale list yet. Tony Li presented some very interesting graphs at the opening plenary in Houston. A surprising observation was that, though the size of the backbone routing tables has been growing exponentially, the amount of allocated IP address space has been growing only linearly. Can anyone explain that? I can think of two possible explanations: (1) the rate of allocation of address space to new sites has been constant, but the number of such sites choosing to connect to the Internet has been growing exponentially, or (2) the amount of address space allocated to new sites has been decreasing exponentially. Perhaps it's a bit of both? If so, how much can we count on those phenomena continuing to be true? (There's an obvious limit on the second phenomenon!) Any other explanations? (Is incorrect data a possibility?) Steve From owner-Big-Internet@munnari.OZ.AU Sat Nov 13 22:06:01 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17784; Sat, 13 Nov 1993 19:11:59 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA01909; Sat, 13 Nov 1993 19:10:22 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA01895; Sat, 13 Nov 1993 18:57:23 +1100 Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11372; Sat, 13 Nov 1993 16:09:57 +1100 (from hwb@upeksa.sdsc.edu) Received: by upeksa.sdsc.edu (AIX 3.2/UCB 5.64/4.03) id AA09703; Fri, 12 Nov 1993 21:09:38 -0800 From: hwb@upeksa.sdsc.edu (Hans-Werner Braun) Message-Id: <9311130509.AA09703@upeksa.sdsc.edu> Subject: address space consumption (fwd) To: big-internet@munnari.OZ.AU Date: Fri, 12 Nov 93 21:09:37 PST I will attach an postscript image regarding committed address space. Looking at it, it seems dangerous to make statements based on the growth of all compounded ClassA*2^24 + ClassB*2^16 + ClassC*2^8 figures, as the lesser Class A and Class B growth dwarfs the Class C changes in terms of *total committed address space* (not network numbers). Isolated Class C committed space growth has clearly been exponental, and is even accelerating more over the last year. If current growth patterns persist, the exponential growth of the Class C *committed address space* will outperform the effects of the Class A and Class B changes. The figures are *only* about committed space, and based on network numbers configured on the NSFNET backbone (with public history.netcount data from nic.nsf.net). --- %!PS-Adobe-2.0 EPSF-1.2 %%BoundingBox: 18 18 536 724 %%Creator: ACE/gr (xmgr) v3.00 %%Title: pout.dat %%EndComments /m {moveto} bind def /l {lineto} bind def /RJ { stringwidth neg exch neg exch rmoveto } bind def /CS { stringwidth 2 div neg exch 2 div neg exch rmoveto } bind def 0.25 0.25 scale 1 setlinecap 2384 0 translate 90 rotate 0.000000 0.000000 0.000000 setrgbcolor 1 setlinewidth /Times-Italic findfont 60 scalefont setfont [] 0 setdash 377 298 m 377 1147 l 2883 1147 l 2883 298 l 377 298 l stroke [] 0 setdash 561 298 m 561 308 l 720 298 m 720 308 l 878 298 m 878 308 l 1036 298 m 1036 308 l 1194 298 m 1194 308 l 1353 298 m 1353 308 l 1511 298 m 1511 308 l 1669 298 m 1669 308 l 1828 298 m 1828 308 l 1986 298 m 1986 308 l 2144 298 m 2144 308 l 2303 298 m 2303 308 l 2461 298 m 2461 308 l 2619 298 m 2619 308 l 2778 298 m 2778 308 l 561 1147 m 561 1137 l 720 1147 m 720 1137 l 878 1147 m 878 1137 l 1036 1147 m 1036 1137 l 1194 1147 m 1194 1137 l 1353 1147 m 1353 1137 l 1511 1147 m 1511 1137 l 1669 1147 m 1669 1137 l 1828 1147 m 1828 1137 l 1986 1147 m 1986 1137 l 2144 1147 m 2144 1137 l 2303 1147 m 2303 1137 l 2461 1147 m 2461 1137 l 2619 1147 m 2619 1137 l 2778 1147 m 2778 1137 l stroke 561 298 m 561 318 l 720 298 m 720 318 l 878 298 m 878 318 l 1036 298 m 1036 318 l 1194 298 m 1194 318 l 1353 298 m 1353 318 l 1511 298 m 1511 318 l 1669 298 m 1669 318 l 1828 298 m 1828 318 l 1986 298 m 1986 318 l 2144 298 m 2144 318 l 2303 298 m 2303 318 l 2461 298 m 2461 318 l 2619 298 m 2619 318 l 2778 298 m 2778 318 l 561 1147 m 561 1127 l 720 1147 m 720 1127 l 878 1147 m 878 1127 l 1036 1147 m 1036 1127 l 1194 1147 m 1194 1127 l 1353 1147 m 1353 1127 l 1511 1147 m 1511 1127 l 1669 1147 m 1669 1127 l 1828 1147 m 1828 1127 l 1986 1147 m 1986 1127 l 2144 1147 m 2144 1127 l 2303 1147 m 2303 1127 l 2461 1147 m 2461 1127 l 2619 1147 m 2619 1127 l 2778 1147 m 2778 1127 l /Times-Italic findfont 48 scalefont setfont /Helvetica findfont 48 scalefont setfont stroke 561 258 m gsave 561 258 translate 0 rotate 0 -16 m (Jan 89) CS (Jan 89) show grestore newpath 720 258 m gsave 720 258 translate 0 rotate 0 -16 m (Jul 89) CS (Jul 89) show grestore newpath 878 258 m gsave 878 258 translate 0 rotate 0 -16 m (Jan 90) CS (Jan 90) show grestore newpath 1036 258 m gsave 1036 258 translate 0 rotate 0 -16 m (Jul 90) CS (Jul 90) show grestore newpath 1194 258 m gsave 1194 258 translate 0 rotate 0 -16 m (Jan 91) CS (Jan 91) show grestore newpath 1353 258 m gsave 1353 258 translate 0 rotate 0 -16 m (Jul 91) CS (Jul 91) show grestore newpath 1511 258 m gsave 1511 258 translate 0 rotate 0 -16 m (Jan 92) CS (Jan 92) show grestore newpath 1669 258 m gsave 1669 258 translate 0 rotate 0 -16 m (Jul 92) CS (Jul 92) show grestore newpath 1828 258 m gsave 1828 258 translate 0 rotate 0 -16 m (Jan 93) CS (Jan 93) show grestore newpath 1986 258 m gsave 1986 258 translate 0 rotate 0 -16 m (Jul 93) CS (Jul 93) show grestore newpath 2144 258 m gsave 2144 258 translate 0 rotate 0 -16 m (Jan 94) CS (Jan 94) show grestore newpath 2303 258 m gsave 2303 258 translate 0 rotate 0 -16 m (Jul 94) CS (Jul 94) show grestore newpath 2461 258 m gsave 2461 258 translate 0 rotate 0 -16 m (Jan 95) CS (Jan 95) show grestore newpath 2619 258 m gsave 2619 258 translate 0 rotate 0 -16 m (Jul 95) CS (Jul 95) show grestore newpath 2778 258 m gsave 2778 258 translate 0 rotate 0 -16 m (Jan 96) CS (Jan 96) show grestore newpath 377 298 m 387 298 l 377 343 m 387 343 l 377 370 m 387 370 l 377 389 m 387 389 l 377 403 m 387 403 l 377 415 m 387 415 l 377 425 m 387 425 l 377 434 m 387 434 l 377 442 m 387 442 l 377 449 m 387 449 l 377 494 m 387 494 l 377 521 m 387 521 l 377 539 m 387 539 l 377 554 m 387 554 l 377 566 m 387 566 l 377 576 m 387 576 l 377 585 m 387 585 l 377 592 m 387 592 l 377 599 m 387 599 l 377 645 m 387 645 l 377 671 m 387 671 l 377 690 m 387 690 l 377 705 m 387 705 l 377 717 m 387 717 l 377 727 m 387 727 l 377 735 m 387 735 l 377 743 m 387 743 l 377 750 m 387 750 l 377 795 m 387 795 l 377 822 m 387 822 l 377 841 m 387 841 l 377 855 m 387 855 l 377 867 m 387 867 l 377 877 m 387 877 l 377 886 m 387 886 l 377 894 m 387 894 l 377 901 m 387 901 l 377 946 m 387 946 l 377 973 m 387 973 l 377 991 m 387 991 l 377 1006 m 387 1006 l 377 1018 m 387 1018 l 377 1028 m 387 1028 l 377 1037 m 387 1037 l 377 1045 m 387 1045 l 377 1051 m 387 1051 l 377 1097 m 387 1097 l 377 1123 m 387 1123 l 377 1142 m 387 1142 l 2883 298 m 2873 298 l 2883 343 m 2873 343 l 2883 370 m 2873 370 l 2883 389 m 2873 389 l 2883 403 m 2873 403 l 2883 415 m 2873 415 l 2883 425 m 2873 425 l 2883 434 m 2873 434 l 2883 442 m 2873 442 l 2883 449 m 2873 449 l 2883 494 m 2873 494 l 2883 521 m 2873 521 l 2883 539 m 2873 539 l 2883 554 m 2873 554 l 2883 566 m 2873 566 l 2883 576 m 2873 576 l 2883 585 m 2873 585 l 2883 592 m 2873 592 l 2883 599 m 2873 599 l 2883 645 m 2873 645 l 2883 671 m 2873 671 l 2883 690 m 2873 690 l 2883 705 m 2873 705 l 2883 717 m 2873 717 l 2883 727 m 2873 727 l 2883 735 m 2873 735 l 2883 743 m 2873 743 l 2883 750 m 2873 750 l 2883 795 m 2873 795 l 2883 822 m 2873 822 l 2883 841 m 2873 841 l 2883 855 m 2873 855 l 2883 867 m 2873 867 l 2883 877 m 2873 877 l 2883 886 m 2873 886 l 2883 894 m 2873 894 l 2883 901 m 2873 901 l 2883 946 m 2873 946 l 2883 973 m 2873 973 l 2883 991 m 2873 991 l 2883 1006 m 2873 1006 l 2883 1018 m 2873 1018 l 2883 1028 m 2873 1028 l 2883 1037 m 2873 1037 l 2883 1045 m 2873 1045 l 2883 1051 m 2873 1051 l 2883 1097 m 2873 1097 l 2883 1123 m 2873 1123 l 2883 1142 m 2873 1142 l stroke 377 298 m 397 298 l 377 449 m 397 449 l 377 599 m 397 599 l 377 750 m 397 750 l 377 901 m 397 901 l 377 1051 m 397 1051 l 2883 298 m 2863 298 l 2883 449 m 2863 449 l 2883 599 m 2863 599 l 2883 750 m 2863 750 l 2883 901 m 2863 901 l 2883 1051 m 2863 1051 l /Helvetica findfont 60 scalefont setfont stroke 339 298 m gsave 339 298 translate 0 rotate 0 -20 m (104) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (4) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 449 m gsave 339 449 translate 0 rotate 0 -20 m (105) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (5) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 599 m gsave 339 599 translate 0 rotate 0 -20 m (106) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (6) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 750 m gsave 339 750 translate 0 rotate 0 -20 m (107) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (7) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 901 m gsave 339 901 translate 0 rotate 0 -20 m (108) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (8) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 1051 m gsave 339 1051 translate 0 rotate 0 -20 m (109) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (9) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath /Helvetica findfont 60 scalefont setfont 207 722 m gsave 207 722 translate 90 rotate 0 0 m (available address space) CS (available address space) show grestore newpath 403 1101 m 429 1101 l 456 1101 l 482 1101 l 508 1101 l 535 1101 l 561 1101 l 588 1101 l 614 1101 l 640 1101 l 667 1101 l 693 1101 l 720 1101 l 746 1101 l 772 1101 l 799 1101 l 825 1101 l 851 1101 l 878 1101 l 904 1101 l 931 1101 l 957 1101 l 983 1101 l 1010 1101 l 1036 1101 l 1063 1101 l 1089 1101 l 1115 1101 l 1142 1101 l 1168 1101 l 1194 1101 l 1221 1101 l 1247 1101 l 1274 1101 l 1300 1101 l 1326 1101 l 1353 1101 l 1379 1101 l 1406 1101 l 1432 1101 l 1458 1101 l 1485 1101 l 1511 1101 l 1537 1101 l 1564 1101 l 1590 1101 l 1617 1101 l 1643 1101 l 1669 1101 l 1696 1101 l 1722 1101 l 1749 1101 l 1775 1101 l 1801 1101 l 1828 1101 l 1854 1101 l 1880 1101 l 1907 1101 l 1933 1101 l 1960 1101 l 1986 1101 l 2012 1101 l 2039 1101 l 2065 1101 l stroke 1.000000 0.000000 0.000000 setrgbcolor 403 1056 m 429 1056 l 456 1056 l 482 1056 l 508 1056 l 535 1056 l 561 1056 l 588 1056 l 614 1056 l 640 1056 l 667 1056 l 693 1056 l 720 1056 l 746 1056 l 772 1056 l 799 1056 l 825 1056 l 851 1056 l 878 1056 l 904 1056 l 931 1056 l 957 1056 l 983 1056 l 1010 1056 l 1036 1056 l 1063 1056 l 1089 1056 l 1115 1056 l 1142 1056 l 1168 1056 l 1194 1056 l 1221 1056 l 1247 1056 l 1274 1056 l 1300 1056 l 1326 1056 l 1353 1056 l 1379 1056 l 1406 1056 l 1432 1056 l 1458 1056 l 1485 1056 l 1511 1056 l 1537 1056 l 1564 1056 l 1590 1056 l 1617 1056 l 1643 1056 l 1669 1056 l 1696 1056 l 1722 1056 l 1749 1056 l 1775 1056 l 1801 1056 l 1828 1056 l 1854 1056 l 1880 1056 l 1907 1056 l 1933 1056 l 1960 1056 l 1986 1056 l 2012 1056 l 2039 1056 l 2065 1056 l stroke 0.000000 0.000000 0.000000 setrgbcolor 0.000000 1.000000 0.000000 setrgbcolor 403 1011 m 429 1011 l 456 1011 l 482 1011 l 508 1011 l 535 1011 l 561 1011 l 588 1011 l 614 1011 l 640 1011 l 667 1011 l 693 1011 l 720 1011 l 746 1011 l 772 1011 l 799 1011 l 825 1011 l 851 1011 l 878 1011 l 904 1011 l 931 1011 l 957 1011 l 983 1011 l 1010 1011 l 1036 1011 l 1063 1011 l 1089 1011 l 1115 1011 l 1142 1011 l 1168 1011 l 1194 1011 l 1221 1011 l 1247 1011 l 1274 1011 l 1300 1011 l 1326 1011 l 1353 1011 l 1379 1011 l 1406 1011 l 1432 1011 l 1458 1011 l 1485 1011 l 1511 1011 l 1537 1011 l 1564 1011 l 1590 1011 l 1617 1011 l 1643 1011 l 1669 1011 l 1696 1011 l 1722 1011 l 1749 1011 l 1775 1011 l 1801 1011 l 1828 1011 l 1854 1011 l 1880 1011 l 1907 1011 l 1933 1011 l 1960 1011 l 1986 1011 l 2012 1011 l 2039 1011 l 2065 1011 l stroke 0.000000 0.000000 0.000000 setrgbcolor 403 784 m 429 829 l 456 856 l 482 889 l 508 889 l 535 889 l 561 901 l 588 901 l 614 901 l 640 901 l 667 901 l 693 920 l 720 928 l 746 928 l 772 928 l 799 928 l 825 928 l 851 928 l 878 947 l 904 947 l 931 947 l 957 947 l 983 947 l 1010 952 l 1036 952 l 1063 952 l 1089 952 l 1115 952 l 1142 952 l 1168 952 l 1194 952 l 1221 952 l 1247 952 l 1274 957 l 1300 957 l 1326 961 l 1353 961 l 1379 961 l 1406 965 l 1432 965 l 1458 965 l 1485 965 l 1511 965 l 1537 965 l 1564 969 l 1590 973 l 1617 973 l 1643 973 l 1669 977 l 1696 977 l 1722 977 l 1749 980 l 1775 980 l 1801 995 l 1828 995 l 1854 992 l 1880 989 l 1907 989 l 1933 989 l 1960 992 l 1986 997 l 2012 997 l 2039 1000 l 2065 1000 l stroke 1.000000 0.000000 0.000000 setrgbcolor 403 739 m 429 741 l 456 744 l 482 759 l 508 766 l 535 769 l 561 772 l 588 778 l 614 784 l 640 791 l 667 799 l 693 802 l 720 805 l 746 814 l 772 820 l 799 822 l 825 827 l 851 829 l 878 855 l 904 856 l 931 859 l 957 863 l 983 865 l 1010 867 l 1036 872 l 1063 877 l 1089 879 l 1115 882 l 1142 884 l 1168 885 l 1194 889 l 1221 891 l 1247 893 l 1274 896 l 1300 899 l 1326 904 l 1353 906 l 1379 910 l 1406 912 l 1432 914 l 1458 916 l 1485 922 l 1511 925 l 1537 929 l 1564 931 l 1590 934 l 1617 935 l 1643 937 l 1669 939 l 1696 941 l 1722 943 l 1749 946 l 1775 947 l 1801 951 l 1828 952 l 1854 953 l 1880 955 l 1907 956 l 1933 958 l 1960 959 l 1986 961 l 2012 962 l 2039 964 l 2065 965 l stroke 0.000000 0.000000 0.000000 setrgbcolor 0.000000 1.000000 0.000000 setrgbcolor 403 294 m 421 298 m 429 299 l 456 307 l 482 317 l 508 325 l 535 330 l 561 336 l 588 346 l 614 353 l 640 364 l 667 376 l 693 383 l 720 387 l 746 398 l 772 404 l 799 406 l 825 416 l 851 418 l 878 453 l 904 456 l 931 460 l 957 465 l 983 467 l 1010 471 l 1036 475 l 1063 482 l 1089 486 l 1115 489 l 1142 494 l 1168 497 l 1194 503 l 1221 505 l 1247 507 l 1274 512 l 1300 515 l 1326 521 l 1353 524 l 1379 528 l 1406 531 l 1432 536 l 1458 541 l 1485 555 l 1511 559 l 1537 562 l 1564 565 l 1590 571 l 1617 575 l 1643 579 l 1669 583 l 1696 589 l 1722 592 l 1749 601 l 1775 607 l 1801 619 l 1828 625 l 1854 629 l 1880 637 l 1907 643 l 1933 651 l 1960 657 l 1986 663 l 2012 669 l 2039 676 l 2065 682 l stroke 0.000000 0.000000 0.000000 setrgbcolor /Helvetica findfont 51 scalefont setfont 1.000000 1.000000 1.000000 setrgbcolor 2120 370 m 2120 754 l 2791 754 l 2791 370 l closepath gsave eofill grestore stroke 0.000000 0.000000 0.000000 setrgbcolor 2120 370 m 2120 754 l 2791 754 l 2791 370 l 2120 370 l stroke /Helvetica findfont 51 scalefont setfont 2150 722 m 2270 722 l stroke 2300 722 m gsave 2300 722 translate 0 rotate 0 -17 m (2^31 \(Class-A total\)) show grestore newpath /Helvetica findfont 51 scalefont setfont 1.000000 0.000000 0.000000 setrgbcolor 2150 658 m 2270 658 l stroke 0.000000 0.000000 0.000000 setrgbcolor 2300 658 m gsave 2300 658 translate 0 rotate 0 -17 m (2^30 \(Class-B total\)) show grestore newpath /Helvetica findfont 51 scalefont setfont 0.000000 1.000000 0.000000 setrgbcolor 2150 594 m 2270 594 l stroke 0.000000 0.000000 0.000000 setrgbcolor 2300 594 m gsave 2300 594 translate 0 rotate 0 -17 m (2^29 \(Class-C total\)) show grestore newpath /Helvetica findfont 51 scalefont setfont 2150 530 m 2270 530 l stroke 2300 530 m gsave 2300 530 translate 0 rotate 0 -17 m (Class-A committed) show grestore newpath /Helvetica findfont 51 scalefont setfont 1.000000 0.000000 0.000000 setrgbcolor 2150 466 m 2270 466 l stroke 0.000000 0.000000 0.000000 setrgbcolor 2300 466 m gsave 2300 466 translate 0 rotate 0 -17 m (Class-B committed) show grestore newpath /Helvetica findfont 51 scalefont setfont 0.000000 1.000000 0.000000 setrgbcolor 2150 402 m 2270 402 l stroke 0.000000 0.000000 0.000000 setrgbcolor 2300 402 m gsave 2300 402 translate 0 rotate 0 -17 m (Class-C committed) show grestore newpath 377 1303 m 377 2152 l 2883 2152 l 2883 1303 l 377 1303 l stroke 561 1303 m 561 1313 l 720 1303 m 720 1313 l 878 1303 m 878 1313 l 1036 1303 m 1036 1313 l 1194 1303 m 1194 1313 l 1353 1303 m 1353 1313 l 1511 1303 m 1511 1313 l 1669 1303 m 1669 1313 l 1828 1303 m 1828 1313 l 1986 1303 m 1986 1313 l 2144 1303 m 2144 1313 l 2303 1303 m 2303 1313 l 2461 1303 m 2461 1313 l 2619 1303 m 2619 1313 l 2778 1303 m 2778 1313 l 561 2152 m 561 2142 l 720 2152 m 720 2142 l 878 2152 m 878 2142 l 1036 2152 m 1036 2142 l 1194 2152 m 1194 2142 l 1353 2152 m 1353 2142 l 1511 2152 m 1511 2142 l 1669 2152 m 1669 2142 l 1828 2152 m 1828 2142 l 1986 2152 m 1986 2142 l 2144 2152 m 2144 2142 l 2303 2152 m 2303 2142 l 2461 2152 m 2461 2142 l 2619 2152 m 2619 2142 l 2778 2152 m 2778 2142 l stroke 561 1303 m 561 1323 l 720 1303 m 720 1323 l 878 1303 m 878 1323 l 1036 1303 m 1036 1323 l 1194 1303 m 1194 1323 l 1353 1303 m 1353 1323 l 1511 1303 m 1511 1323 l 1669 1303 m 1669 1323 l 1828 1303 m 1828 1323 l 1986 1303 m 1986 1323 l 2144 1303 m 2144 1323 l 2303 1303 m 2303 1323 l 2461 1303 m 2461 1323 l 2619 1303 m 2619 1323 l 2778 1303 m 2778 1323 l 561 2152 m 561 2132 l 720 2152 m 720 2132 l 878 2152 m 878 2132 l 1036 2152 m 1036 2132 l 1194 2152 m 1194 2132 l 1353 2152 m 1353 2132 l 1511 2152 m 1511 2132 l 1669 2152 m 1669 2132 l 1828 2152 m 1828 2132 l 1986 2152 m 1986 2132 l 2144 2152 m 2144 2132 l 2303 2152 m 2303 2132 l 2461 2152 m 2461 2132 l 2619 2152 m 2619 2132 l 2778 2152 m 2778 2132 l /Helvetica findfont 48 scalefont setfont stroke 561 1263 m gsave 561 1263 translate 0 rotate 0 -16 m (Jan 89) CS (Jan 89) show grestore newpath 720 1263 m gsave 720 1263 translate 0 rotate 0 -16 m (Jul 89) CS (Jul 89) show grestore newpath 878 1263 m gsave 878 1263 translate 0 rotate 0 -16 m (Jan 90) CS (Jan 90) show grestore newpath 1036 1263 m gsave 1036 1263 translate 0 rotate 0 -16 m (Jul 90) CS (Jul 90) show grestore newpath 1194 1263 m gsave 1194 1263 translate 0 rotate 0 -16 m (Jan 91) CS (Jan 91) show grestore newpath 1353 1263 m gsave 1353 1263 translate 0 rotate 0 -16 m (Jul 91) CS (Jul 91) show grestore newpath 1511 1263 m gsave 1511 1263 translate 0 rotate 0 -16 m (Jan 92) CS (Jan 92) show grestore newpath 1669 1263 m gsave 1669 1263 translate 0 rotate 0 -16 m (Jul 92) CS (Jul 92) show grestore newpath 1828 1263 m gsave 1828 1263 translate 0 rotate 0 -16 m (Jan 93) CS (Jan 93) show grestore newpath 1986 1263 m gsave 1986 1263 translate 0 rotate 0 -16 m (Jul 93) CS (Jul 93) show grestore newpath 2144 1263 m gsave 2144 1263 translate 0 rotate 0 -16 m (Jan 94) CS (Jan 94) show grestore newpath 2303 1263 m gsave 2303 1263 translate 0 rotate 0 -16 m (Jul 94) CS (Jul 94) show grestore newpath 2461 1263 m gsave 2461 1263 translate 0 rotate 0 -16 m (Jan 95) CS (Jan 95) show grestore newpath 2619 1263 m gsave 2619 1263 translate 0 rotate 0 -16 m (Jul 95) CS (Jul 95) show grestore newpath 2778 1263 m gsave 2778 1263 translate 0 rotate 0 -16 m (Jan 96) CS (Jan 96) show grestore newpath 377 1303 m 387 1303 l 377 1349 m 387 1349 l 377 1375 m 387 1375 l 377 1394 m 387 1394 l 377 1409 m 387 1409 l 377 1420 m 387 1420 l 377 1431 m 387 1431 l 377 1439 m 387 1439 l 377 1447 m 387 1447 l 377 1454 m 387 1454 l 377 1499 m 387 1499 l 377 1526 m 387 1526 l 377 1545 m 387 1545 l 377 1559 m 387 1559 l 377 1571 m 387 1571 l 377 1581 m 387 1581 l 377 1590 m 387 1590 l 377 1598 m 387 1598 l 377 1605 m 387 1605 l 377 1650 m 387 1650 l 377 1677 m 387 1677 l 377 1695 m 387 1695 l 377 1710 m 387 1710 l 377 1722 m 387 1722 l 377 1732 m 387 1732 l 377 1741 m 387 1741 l 377 1748 m 387 1748 l 377 1755 m 387 1755 l 377 1801 m 387 1801 l 377 1827 m 387 1827 l 377 1846 m 387 1846 l 377 1861 m 387 1861 l 377 1873 m 387 1873 l 377 1883 m 387 1883 l 377 1891 m 387 1891 l 377 1899 m 387 1899 l 377 1906 m 387 1906 l 377 1951 m 387 1951 l 377 1978 m 387 1978 l 377 1997 m 387 1997 l 377 2011 m 387 2011 l 377 2023 m 387 2023 l 377 2033 m 387 2033 l 377 2042 m 387 2042 l 377 2050 m 387 2050 l 377 2057 m 387 2057 l 377 2102 m 387 2102 l 377 2129 m 387 2129 l 377 2147 m 387 2147 l 2883 1303 m 2873 1303 l 2883 1349 m 2873 1349 l 2883 1375 m 2873 1375 l 2883 1394 m 2873 1394 l 2883 1409 m 2873 1409 l 2883 1420 m 2873 1420 l 2883 1431 m 2873 1431 l 2883 1439 m 2873 1439 l 2883 1447 m 2873 1447 l 2883 1454 m 2873 1454 l 2883 1499 m 2873 1499 l 2883 1526 m 2873 1526 l 2883 1545 m 2873 1545 l 2883 1559 m 2873 1559 l 2883 1571 m 2873 1571 l 2883 1581 m 2873 1581 l 2883 1590 m 2873 1590 l 2883 1598 m 2873 1598 l 2883 1605 m 2873 1605 l 2883 1650 m 2873 1650 l 2883 1677 m 2873 1677 l 2883 1695 m 2873 1695 l 2883 1710 m 2873 1710 l 2883 1722 m 2873 1722 l 2883 1732 m 2873 1732 l 2883 1741 m 2873 1741 l 2883 1748 m 2873 1748 l 2883 1755 m 2873 1755 l 2883 1801 m 2873 1801 l 2883 1827 m 2873 1827 l 2883 1846 m 2873 1846 l 2883 1861 m 2873 1861 l 2883 1873 m 2873 1873 l 2883 1883 m 2873 1883 l 2883 1891 m 2873 1891 l 2883 1899 m 2873 1899 l 2883 1906 m 2873 1906 l 2883 1951 m 2873 1951 l 2883 1978 m 2873 1978 l 2883 1997 m 2873 1997 l 2883 2011 m 2873 2011 l 2883 2023 m 2873 2023 l 2883 2033 m 2873 2033 l 2883 2042 m 2873 2042 l 2883 2050 m 2873 2050 l 2883 2057 m 2873 2057 l 2883 2102 m 2873 2102 l 2883 2129 m 2873 2129 l 2883 2147 m 2873 2147 l stroke 377 1303 m 397 1303 l 377 1454 m 397 1454 l 377 1605 m 397 1605 l 377 1755 m 397 1755 l 377 1906 m 397 1906 l 377 2057 m 397 2057 l 2883 1303 m 2863 1303 l 2883 1454 m 2863 1454 l 2883 1605 m 2863 1605 l 2883 1755 m 2863 1755 l 2883 1906 m 2863 1906 l 2883 2057 m 2863 2057 l /Helvetica findfont 60 scalefont setfont stroke 339 1303 m gsave 339 1303 translate 0 rotate 0 -20 m (104) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (4) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 1454 m gsave 339 1454 translate 0 rotate 0 -20 m (105) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (5) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 1605 m gsave 339 1605 translate 0 rotate 0 -20 m (106) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (6) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 1755 m gsave 339 1755 translate 0 rotate 0 -20 m (107) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (7) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 1906 m gsave 339 1906 translate 0 rotate 0 -20 m (108) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (8) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath 339 2057 m gsave 339 2057 translate 0 rotate 0 -20 m (109) RJ (10) show /Helvetica findfont 36 scalefont setfont 0 36 rmoveto (9) show /Helvetica findfont 60 scalefont setfont 0 -36 rmoveto () show grestore newpath /Helvetica findfont 60 scalefont setfont 207 1727 m gsave 207 1727 translate 90 rotate 0 0 m (available address space) CS (available address space) show grestore newpath /Helvetica findfont 59 scalefont setfont 1630 2263 m gsave 1630 2263 translate 0 rotate 0 0 m (IP address space depletion) CS (IP address space depletion) show grestore newpath /Helvetica findfont 39 scalefont setfont 1630 2185 m gsave 1630 2185 translate 0 rotate 0 0 m (by committed space by net class) CS (by committed space by net class) show grestore newpath 403 1816 m 429 1850 l 456 1872 l 482 1903 l 508 1904 l 535 1904 l 561 1915 l 588 1916 l 614 1917 l 640 1918 l 667 1919 l 693 1935 l 720 1942 l 746 1944 l 772 1945 l 799 1945 l 825 1946 l 851 1946 l 878 1966 l 904 1967 l 931 1967 l 957 1968 l 983 1968 l 1010 1973 l 1036 1974 l 1063 1975 l 1089 1976 l 1115 1976 l 1142 1977 l 1168 1977 l 1194 1978 l 1221 1979 l 1247 1980 l 1274 1984 l 1300 1985 l 1326 1989 l 1353 1990 l 1379 1991 l 1406 1995 l 1432 1995 l 1458 1996 l 1485 1998 l 1511 1999 l 1537 2000 l 1564 2004 l 1590 2007 l 1617 2008 l 1643 2008 l 1669 2011 l 1696 2012 l 1722 2013 l 1749 2016 l 1775 2016 l 1801 2027 l 1828 2027 l 1854 2026 l 1880 2025 l 1907 2026 l 1933 2026 l 1960 2028 l 1986 2032 l 2012 2033 l 2039 2035 l 2065 2036 l stroke 0.000000 1.000000 0.000000 setrgbcolor 403 1300 m 421 1303 m 429 1305 l 456 1312 l 482 1322 l 508 1330 l 535 1336 l 561 1341 l 588 1352 l 614 1358 l 640 1370 l 667 1381 l 693 1388 l 720 1393 l 746 1404 l 772 1409 l 799 1412 l 825 1421 l 851 1423 l 878 1458 l 904 1462 l 931 1465 l 957 1470 l 983 1473 l 1010 1476 l 1036 1480 l 1063 1488 l 1089 1491 l 1115 1495 l 1142 1499 l 1168 1502 l 1194 1508 l 1221 1510 l 1247 1513 l 1274 1517 l 1300 1521 l 1326 1526 l 1353 1529 l 1379 1533 l 1406 1536 l 1432 1541 l 1458 1546 l 1485 1560 l 1511 1564 l 1537 1568 l 1564 1571 l 1590 1576 l 1617 1581 l 1643 1584 l 1669 1588 l 1696 1594 l 1722 1598 l 1749 1607 l 1775 1613 l 1801 1624 l 1828 1630 l 1854 1634 l 1880 1643 l 1907 1649 l 1933 1657 l 1960 1662 l 1986 1668 l 2012 1674 l 2039 1682 l 2065 1688 l stroke 0.000000 0.000000 0.000000 setrgbcolor 0.000000 1.000000 0.000000 setrgbcolor 403 2016 m 429 2016 l 456 2016 l 482 2016 l 508 2016 l 535 2016 l 561 2016 l 588 2016 l 614 2016 l 640 2016 l 667 2016 l 693 2016 l 720 2016 l 746 2016 l 772 2016 l 799 2016 l 825 2016 l 851 2016 l 878 2016 l 904 2016 l 931 2016 l 957 2016 l 983 2016 l 1010 2016 l 1036 2016 l 1063 2016 l 1089 2016 l 1115 2016 l 1142 2016 l 1168 2016 l 1194 2016 l 1221 2016 l 1247 2016 l 1274 2016 l 1300 2016 l 1326 2016 l 1353 2016 l 1379 2016 l 1406 2016 l 1432 2016 l 1458 2016 l 1485 2016 l 1511 2016 l 1537 2016 l 1564 2016 l 1590 2016 l 1617 2016 l 1643 2016 l 1669 2016 l 1696 2016 l 1722 2016 l 1749 2016 l 1775 2016 l 1801 2016 l 1828 2016 l 1854 2016 l 1880 2016 l 1907 2016 l 1933 2016 l 1960 2016 l 1986 2016 l 2012 2016 l 2039 2016 l 2065 2016 l stroke 0.000000 0.000000 0.000000 setrgbcolor 1.000000 0.000000 0.000000 setrgbcolor 403 2061 m 429 2061 l 456 2061 l 482 2061 l 508 2061 l 535 2061 l 561 2061 l 588 2061 l 614 2061 l 640 2061 l 667 2061 l 693 2061 l 720 2061 l 746 2061 l 772 2061 l 799 2061 l 825 2061 l 851 2061 l 878 2061 l 904 2061 l 931 2061 l 957 2061 l 983 2061 l 1010 2061 l 1036 2061 l 1063 2061 l 1089 2061 l 1115 2061 l 1142 2061 l 1168 2061 l 1194 2061 l 1221 2061 l 1247 2061 l 1274 2061 l 1300 2061 l 1326 2061 l 1353 2061 l 1379 2061 l 1406 2061 l 1432 2061 l 1458 2061 l 1485 2061 l 1511 2061 l 1537 2061 l 1564 2061 l 1590 2061 l 1617 2061 l 1643 2061 l 1669 2061 l 1696 2061 l 1722 2061 l 1749 2061 l 1775 2061 l 1801 2061 l 1828 2061 l 1854 2061 l 1880 2061 l 1907 2061 l 1933 2061 l 1960 2061 l 1986 2061 l 2012 2061 l 2039 2061 l 2065 2061 l stroke 0.000000 0.000000 0.000000 setrgbcolor 403 2107 m 429 2107 l 456 2107 l 482 2107 l 508 2107 l 535 2107 l 561 2107 l 588 2107 l 614 2107 l 640 2107 l 667 2107 l 693 2107 l 720 2107 l 746 2107 l 772 2107 l 799 2107 l 825 2107 l 851 2107 l 878 2107 l 904 2107 l 931 2107 l 957 2107 l 983 2107 l 1010 2107 l 1036 2107 l 1063 2107 l 1089 2107 l 1115 2107 l 1142 2107 l 1168 2107 l 1194 2107 l 1221 2107 l 1247 2107 l 1274 2107 l 1300 2107 l 1326 2107 l 1353 2107 l 1379 2107 l 1406 2107 l 1432 2107 l 1458 2107 l 1485 2107 l 1511 2107 l 1537 2107 l 1564 2107 l 1590 2107 l 1617 2107 l 1643 2107 l 1669 2107 l 1696 2107 l 1722 2107 l 1749 2107 l 1775 2107 l 1801 2107 l 1828 2107 l 1854 2107 l 1880 2107 l 1907 2107 l 1933 2107 l 1960 2107 l 1986 2107 l 2012 2107 l 2039 2107 l 2065 2107 l stroke /Helvetica findfont 51 scalefont setfont 1.000000 1.000000 1.000000 setrgbcolor 2115 1370 m 2115 1690 l 2806 1690 l 2806 1370 l closepath gsave eofill grestore stroke 0.000000 0.000000 0.000000 setrgbcolor 2115 1370 m 2115 1690 l 2806 1690 l 2806 1370 l 2115 1370 l stroke /Helvetica findfont 51 scalefont setfont 2145 1658 m 2265 1658 l stroke 2295 1658 m gsave 2295 1658 translate 0 rotate 0 -17 m (all Classes committed) show grestore newpath /Helvetica findfont 51 scalefont setfont 0.000000 1.000000 0.000000 setrgbcolor 2145 1594 m 2265 1594 l stroke 0.000000 0.000000 0.000000 setrgbcolor 2295 1594 m gsave 2295 1594 translate 0 rotate 0 -17 m (Class-C committed) show grestore newpath /Helvetica findfont 51 scalefont setfont 0.000000 1.000000 0.000000 setrgbcolor 2145 1530 m 2265 1530 l stroke 0.000000 0.000000 0.000000 setrgbcolor 2295 1530 m gsave 2295 1530 translate 0 rotate 0 -17 m (2^29 \(Class-C total\)) show grestore newpath /Helvetica findfont 51 scalefont setfont 1.000000 0.000000 0.000000 setrgbcolor 2145 1466 m 2265 1466 l stroke 0.000000 0.000000 0.000000 setrgbcolor 2295 1466 m gsave 2295 1466 translate 0 rotate 0 -17 m (2^30 \(Class-B total\)) show grestore newpath /Helvetica findfont 51 scalefont setfont 2145 1402 m 2265 1402 l stroke 2295 1402 m gsave 2295 1402 translate 0 rotate 0 -17 m (2^31 \(Class-A total\)) show grestore newpath showpage %%Trailer From owner-Big-Internet@munnari.OZ.AU Mon Nov 15 06:16:02 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20576; Mon, 15 Nov 1993 05:27:05 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA03572; Mon, 15 Nov 1993 05:22:27 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA03569; Mon, 15 Nov 1993 05:15:03 +1100 Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18689; Mon, 15 Nov 1993 04:27:07 +1100 (from hwb@upeksa.sdsc.edu) Received: by upeksa.sdsc.edu (AIX 3.2/UCB 5.64/4.03) id AA17162; Sun, 14 Nov 1993 09:26:58 -0800 From: hwb@upeksa.sdsc.edu (Hans-Werner Braun) Message-Id: <9311141726.AA17162@upeksa.sdsc.edu> Subject: Re: address space consumption To: deering@parc.xerox.com (Steve Deering) Date: Sun, 14 Nov 93 9:26:58 PST Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <93Nov12.155750pst.12171@skylark.parc.xerox.com>; from "Steve Deering" at Nov 12, 93 3:57 pm Steve: Being a bit more specific in my response: >Here's a question for the new ALE WG, sent to the big-internet list because >I don't think there's an ale list yet. > >Tony Li presented some very interesting graphs at the opening plenary >in Houston. A surprising observation was that, though the size of the >backbone routing tables has been growing exponentially, the amount of >allocated IP address space has been growing only linearly. Can anyone >explain that? I can think of two possible explanations: > > (1) the rate of allocation of address space to new sites has been > constant, but the number of such sites choosing to connect to > the Internet has been growing exponentially, or > > (2) the amount of address space allocated to new sites has been > decreasing exponentially. > >Perhaps it's a bit of both? If so, how much can we count on those >phenomena continuing to be true? (There's an obvious limit on the >second phenomenon!) > >Any other explanations? (Is incorrect data a possibility?) Until about 3Q92 a requestor of IP network numbers was usually granted a Class-B number with very little difficulty. I.e., the requestor largely had to claim a need for some subnets. By about 3Q92 the address registration authority (then nic.ddn.mil) got word to the effect of not depleting the Class-B space, but rather give people multiple Class-C numbers instead, with anticipation for CIDR based masking. This has let to a lessening of Class-B assignments, and an explosion in Class-C committments, including prior to a CIDR implementation. I.e, Class-C equivalents are less sparsely assigned, than by just giving people 256 eight-bit-subnetable chunks with a Class-B address, as often they only need 8/16/32/... subnets, for which CIDRable Class-C's would suffice. There is another separable issue of sparseness of host assignments (Peter Ford mentioned some interesting thoughts on sparseness issues there before), all of which having to do with inefficient use of a 32 bit addressing space. Inefficiencies are not always avoidable, so we can either continue previous practices until things fall over, manage better what we have, or plan on address spaces that are expandable/structurable and allow specifically for certain inefficiencies. E.g., if I would "own" part of the address space as a service provider (say, as a company like Xerox), I may not even know by the time I get an address assignment what I will do with it years down the road (e.g., for a global company-internal network with many components?). So I would probably want to be able to define and expand a structure below my assignment, and have enough flexibility to do so. Hans-Werner From owner-Big-Internet@munnari.OZ.AU Mon Nov 15 21:25:10 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24328; Mon, 15 Nov 1993 19:55:53 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA04288; Mon, 15 Nov 1993 19:53:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA04285; Mon, 15 Nov 1993 19:42:03 +1100 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23805; Mon, 15 Nov 1993 19:42:18 +1100 (from tli@cisco.com) Received: by lager.cisco.com id AA12439 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Mon, 15 Nov 1993 00:42:11 -0800 Date: Mon, 15 Nov 1993 00:42:11 -0800 From: Tony Li Message-Id: <199311150842.AA12439@lager.cisco.com> To: hwb@upeksa.sdsc.edu (Hans-Werner Braun) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: address space consumption >Tony Li presented some very interesting graphs at the opening plenary >in Houston. A surprising observation was that, though the size of the >backbone routing tables has been growing exponentially, the amount of >allocated IP address space has been growing only linearly. Can anyone >explain that? I can think of two possible explanations: > > (1) the rate of allocation of address space to new sites has been > constant, but the number of such sites choosing to connect to > the Internet has been growing exponentially, or This is my favorite. > (2) the amount of address space allocated to new sites has been > decreasing exponentially. Hard to believe but... Until about 3Q92 a requestor of IP network numbers was usually granted a Class-B number with very little difficulty. I.e., the requestor largely had to claim a need for some subnets. By about 3Q92 the address registration authority (then nic.ddn.mil) got word to the effect of not depleting the Class-B space, but rather give people multiple Class-C numbers instead, with anticipation for CIDR based masking. This has let to a lessening of Class-B assignments, and an explosion in Class-C committments, including prior to a CIDR implementation. I.e, Class-C equivalents are less sparsely assigned, than by just giving people 256 eight-bit-subnetable chunks with a Class-B address, as often they only need 8/16/32/... subnets, for which CIDRable Class-C's would suffice. Nice theory, the only problem is that the exponential growth of the routing table predates 1992. Tony From owner-Big-Internet@munnari.OZ.AU Mon Nov 15 22:09:06 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29273; Mon, 15 Nov 1993 22:09:06 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id WAA04416; Mon, 15 Nov 1993 22:08:28 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id WAA04413; Mon, 15 Nov 1993 22:07:45 +1100 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25315; Mon, 15 Nov 1993 20:20:35 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9311150920.25315@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 15 Nov 1993 09:19:52 +0000 To: Tony Li Cc: hwb@upeksa.sdsc.edu (Hans-Werner Braun), big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: address space consumption In-Reply-To: Your message of "Mon, 15 Nov 93 00:42:11 PST." <199311150842.AA12439@lager.cisco.com> Date: Mon, 15 Nov 93 09:19:52 +0000 From: Jon Crowcroft >Nice theory, the only problem is that the exponential growth of the >routing table predates 1992. Tony its obvious the curve is made out of several factors for instance, in the US, acquisition of computers and net numbers through the 2nd half of the 80s was probably hand in hand so the grwoth was simply a measure of darpa and NSF grants to universities...combined with the decrease in cost of computers...(and ethernet and t1) towards end of 80s and early 90s, the growth has built more from the fact that the addition is in terms of islands of nets being glued into the internet - for instance, a lot of national nets in europe were built, university by universiity, then a number oif countries were added to the internet, nation by nation, now you have more commercial enterprises adding, rather than just national research nets ,you get another step function up in the unit of addition but all the B->C step did was change the unit of aggregation a bit compared with the granularity... i think epidemiologist would find this pretty easy to understand... the internet is growing like a disease with no cure:-) however, there is only one more step to go in the unit of addition (domestic internet...and please dont go on about toasters:-)) jon From owner-Big-Internet@munnari.OZ.AU Tue Nov 16 02:17:29 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02241; Mon, 15 Nov 1993 23:25:16 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA04525; Mon, 15 Nov 1993 23:23:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA04522; Mon, 15 Nov 1993 23:19:59 +1100 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02111; Mon, 15 Nov 1993 23:20:07 +1100 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA14431; Mon, 15 Nov 93 07:19:38 EST Message-Id: <9311151219.AA14431@tipper.oit.unc.edu> To: Jon Crowcroft Cc: Tony Li , hwb@upeksa.sdsc.edu (Hans-Werner Braun), big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: address space consumption In-Reply-To: Your message of "Mon, 15 Nov 93 09:19:52 GMT." <9311150920.25315@munnari.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Nov 93 07:19:37 -0500 From: Simon E Spero Hmmm- If routing table growth is related to the addition of smaller internets to the global internet, then there should be some corelation between the number of top level domains seen on the NSFnet backbone, and the total number of routes. Actually, UCL breaks thinks somewhat; maybe there needs to be a minimum number of nets for a TLD to count. The phenomenon is definitely visible when examing the logs of our information services; every month we try to spot the 'fastest growing country'. If we can get confirmation of this, then we will should be able to get a fairly good handle on how much more routing table growth is pending. Based on what seems to be the pattern in the local area, domestic internets should not be a major cause of routing table growth. As I mentoined on ietf yesterday, the company owning the local CBS affiliate has just purchased the internet services from MCNC; the local newspaper is also setting itself up as an ISP. The model they're working on seems to be an address per household, as opposed to a network per household. This model is intuitively appealing; I'm probably above average in having four computers at home; of these, only two are IP capable (NT/Linux PC & powerbook), I'm working on the newton, and the Sega is there so I can beat things up when the previous three are getting to me... There's no immediate percieved need for toaster-net, and the infrastructue isn't there to support it (I had enough trouble finding Marmite around here, yet alone SNMP compliance). just because it POPs doesn't mean you need to read mail on it. Applications might be there in the future, but if IP-NG isn't ready by that time, then we're copulated anyway. Even without CIDR, the single provider model seems to be the one that people targetting the domestic market are working for; this is enough to keep the tables pretty clean. If the ISP doles out hosts, not networks, then routing table growth from domestics will be lost in the noise. Simon From owner-Big-Internet@munnari.OZ.AU Tue Nov 16 02:54:20 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09105; Tue, 16 Nov 1993 02:54:20 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA04786; Tue, 16 Nov 1993 02:53:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA04783; Tue, 16 Nov 1993 02:53:28 +1100 Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09085; Tue, 16 Nov 1993 02:53:39 +1100 (from hwb@upeksa.sdsc.edu) Received: by upeksa.sdsc.edu (AIX 3.2/UCB 5.64/4.03) id AA10972; Mon, 15 Nov 1993 07:53:20 -0800 From: hwb@upeksa.sdsc.edu (Hans-Werner Braun) Message-Id: <9311151553.AA10972@upeksa.sdsc.edu> Subject: Re: address space consumption To: tli@cisco.com (Tony Li) Date: Mon, 15 Nov 93 7:53:20 PST Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <199311150842.AA12439@lager.cisco.com>; from "Tony Li" at Nov 15, 93 12:42 am > Until about 3Q92 a requestor of IP network numbers was usually granted > a Class-B number with very little difficulty. I.e., the requestor > largely had to claim a need for some subnets. By about 3Q92 the address > registration authority (then nic.ddn.mil) got word to the effect of not > depleting the Class-B space, but rather give people multiple Class-C > numbers instead, with anticipation for CIDR based masking. This has > let to a lessening of Class-B assignments, and an explosion in Class-C > committments, including prior to a CIDR implementation. I.e, Class-C > equivalents are less sparsely assigned, than by just giving people 256 > eight-bit-subnetable chunks with a Class-B address, as often they only > need 8/16/32/... subnets, for which CIDRable Class-C's would suffice. > >Nice theory, the only problem is that the exponential growth of the >routing table predates 1992. Huh? No theory, no opinions, just reporting on a specific effect where growth is shifting. I am quite aware of the pre-1992 growth, sorry. Quite visible in the graph I posted as well, including the post-3Q92 acceleration. Hans-Werner From owner-Big-Internet@munnari.OZ.AU Tue Nov 16 13:54:54 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06016; Tue, 16 Nov 1993 13:54:54 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA05339; Tue, 16 Nov 1993 13:53:47 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA05336; Tue, 16 Nov 1993 13:49:11 +1100 Received: from [134.87.120.1] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25953; Tue, 16 Nov 1993 10:19:59 +1100 (from DWILSON@CRC.SD68.NANAIMO.BC.CA) Date: Mon, 15 Nov 1993 15:21:59 -0800 (PST) From: DWILSON@CRC.SD68.NANAIMO.BC.CA (DOUGLAS P. WILSON) Message-Id: <931115152159.975e@CRC.SD68.NANAIMO.BC.CA> Subject: Internet Encyclopedia (Interpedia) group project and mailing list To: library@axon.EEAP.CWRU.Edu, effnews@eff.org, socicom@auvm.american.edu, tk0jut2@mvs.cso.niu.edu, 21765EDT%MSU@CUNYVM.CUNY.EDU, libref-l@kentvm.kent.edu, NU021172@VM1.NoDak.EDU, big-internet@munnari.OZ.AU, isoc-interest@relay.sgi.com X-Vmsmail-To: @MOD.WHO This is to inform you about the proposed Internet Encyclopedia, or Interpedia and the mailing-list for discussion of it. The original idea, due to Rick Gates, was for volunteers to cooperatively write a new encyclopedia, put it in the public domain, and make it available on the Internet. Participants on the mailing-list have expanded the concept by noting that the bibliography entries and references provided with Interpedia articles could include hypertext links to other resources available on the Internet. Unlike any printed encyclopedia, the Interpedia could be kept completely up-to-date. Indeed, it could include hypertext links to ongoing discussions, and perhaps evolve into a general interface to all resources and activities on the Internet. If you find these ideas interesting, please join the Interpedia mailing-list by sending a message to interpedia-request@telerama.lm.com with the body of the message containing the word 'subscribe' and your e-mail address, as follows: subscribe your_username@your.host.domain ---------------------------------------------------------------------------- Doug Wilson dwilson@crc.sd68.nanaimo.bc.ca or dwilson@chaserv.almanac.bc.ca From owner-Big-Internet@munnari.OZ.AU Wed Nov 17 17:03:42 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24577; Wed, 17 Nov 1993 10:27:29 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA06413; Wed, 17 Nov 1993 10:24:31 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA06399; Wed, 17 Nov 1993 10:09:35 +1100 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16518; Wed, 17 Nov 1993 07:16:17 +1100 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 2983; Tue, 16 Nov 93 15:15:55 EST Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 8842; Tue, 16 Nov 1993 15:15:53 -0500 Date: Tue, 16 Nov 93 15:11:36 EST From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Internet Encyclopedia (Interpedia) group project and mailing list To: "DOUGLAS P. WILSON" , library@axon.EEAP.CWRU.Edu, effnews@eff.org, socicom@auvm.american.edu, tk0jut2@mvs.cso.niu.edu, 21765EDT%MSU@CUNYVM.CUNY.EDU, libref-l@kentvm.kent.edu, NU021172@VM1.NoDak.EDU, big-internet@munnari.OZ.AU, isoc-interest@relay.sgi.com In-Reply-To: <931115152159.975e@CRC.SD68.NANAIMO.BC.CA> Message-Id: <931116.151136.EST.VALDIS@vtvm1.cc.vt.edu> On Mon, 15 Nov 1993 15:21:59 -0800 (PST) you said: >The original idea, due to Rick Gates, was for volunteers to >cooperatively write a new encyclopedia, put it in the public domain, >and make it available on the Internet. Participants on the Doug: Please consult with a lawyer who is knowledgable about copyright law before proceeding any further. I *strongly* suspect that you do *NOT* want to place it in the public domain, but rather, that you retain the copyright and make it freely redistributable. Note that there is a *large* legal difference between the two - in particular, if you place it in the public domain, (a) somebody can take it and market it and not owe you *any* royalties, and (b) you cannot attach a 'hold harmless' clause as a condition of copying. See the GNU Public License or the copyright statement on the X window system for examples of what you are *probably* trying to achieve. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Wed Nov 17 18:36:56 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08144; Wed, 17 Nov 1993 15:28:56 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id PAA06675; Wed, 17 Nov 1993 15:24:33 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id PAA06672; Wed, 17 Nov 1993 15:12:00 +1100 From: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07344; Wed, 17 Nov 1993 15:11:06 +1100 (from bound@zk3.dec.com) Received: by inet-gw-1.pa.dec.com; id AA27938; Tue, 16 Nov 93 20:07:57 -0800 Received: by xirtlu.zk3.dec.com; id AA06671; Tue, 16 Nov 1993 23:07:55 -0500 Message-Id: <9311170407.AA06671@xirtlu.zk3.dec.com> To: big-internet@munnari.OZ.AU Subject: ICMP Big Data Return Date: Tue, 16 Nov 93 23:07:49 -0500 X-Mts: smtp I did not know where to ask such a question so I figured I would attempt it here. One problem we have all seen working on IPng is translation and encapsulation of some sort or another. If in fact this does turn out to be necessary in any place it would be really great if ICMP returned 576 octets of data after the header. Its not lots of code change on a host. Has the Internet any history regarding just changing a protocols data portion to make it bigger and then state it must take place? I felt this was kind of done in 1122 to support at least 576 octets for a LAN MTU. I won't get into the cost of not doing this right now but it involves state, tables, and other overhead costs when you need more than 64 octets returned in ICMP for data. Has this been proposed before? thanks /jim From owner-Big-Internet@munnari.OZ.AU Thu Nov 18 06:26:48 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15422; Thu, 18 Nov 1993 06:26:48 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA07502; Thu, 18 Nov 1993 06:24:47 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA07499; Thu, 18 Nov 1993 06:12:33 +1100 Received: from daffy.ee.lbl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14775; Thu, 18 Nov 1993 06:12:29 +1100 (from vern@daffy.ee.lbl.gov) Received: by daffy.ee.lbl.gov for Big-Internet@munnari.oz.au (5.65/1.42) id AA20048; Wed, 17 Nov 93 11:09:16 -0800 Message-Id: <9311171909.AA20048@daffy.ee.lbl.gov> To: Big-Internet@munnari.OZ.AU Subject: revised paper on TCP growth trends available for ftp Date: Wed, 17 Nov 93 11:09:16 PST From: Vern Paxson This is to announce a revised version of a paper on growth trends in wide-area TCP connections, to appear in IEEE Network. The main differences between this version of the paper and the earlier version previously advertised on this list are the analysis of an additional dataset, the appearance of declining growth in many of the major protocols, and the very rapid growth of some information-retrieval protocols. You can get the paper via anonymous ftp to ftp.ee.lbl.gov; retrieve WAN-TCP-growth-trends.revised.ps.Z. I've appended the abstract. Vern Vern Paxson vern@ee.lbl.gov Systems Engineering ucbvax!ee.lbl.gov!vern Lawrence Berkeley Laboratory (510) 486-7504 ------------------------------------------------------------------------ We analyze the growth of a large research laboratory's wide-area TCP connections over a period of three years. Our data consisted of seven month-long traces of all TCP connections made between the site and the rest of the world. We find that many TCP protocols exhibited exponential growth in the number of connections made and bytes transferred, even though the number of hosts at the site only grew linearly. The exponential growth of most of the major TCP protocols began tapering off with the final datasets, while relatively new information-retrieval protocols such as Gopher and World-Wide Web exhibited explosive growth during the same time. Our study also found that individual users greatly affected the site's traffic profile by the inadvertent or casual initiation of multiple, periodic wide-area connections; that exponential growth is fed in part by more users ``discovering'' the Internet and in part by existing users increasingly incorporating use of the Internet into their work patterns; and that wide-area traffic geography is diverse and dynamic. From owner-Big-Internet@munnari.OZ.AU Thu Nov 18 09:48:20 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26765; Wed, 17 Nov 1993 23:27:03 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA07081; Wed, 17 Nov 1993 23:24:44 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA07078; Wed, 17 Nov 1993 23:15:10 +1100 Received: from sunic.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26260; Wed, 17 Nov 1993 23:15:04 +1100 (from Henrik.Johansson@nexus.comm.se) Received: from bond.nexus.comm.se by sunic.sunet.se (8.6.4/2.02) id NAA14151; Wed, 17 Nov 1993 13:13:18 +0100 Received: by bond.nexus.comm.se id AA14418 (5.65c8/IDA-1.4.4); Wed, 17 Nov 1993 13:12:46 +0100 Date: Wed, 17 Nov 1993 13:12:46 +0100 From: Henrik Johansson Message-Id: <199311171212.AA14418@bond.nexus.comm.se> To: VALDIS@VTVM1.CC.VT.EDU Cc: DWILSON@CRC.SD68.NANAIMO.BC.CA, library@axon.EEAP.CWRU.Edu, effnews@eff.org, socicom@auvm.american.edu, tk0jut2@mvs.cso.niu.edu, 21765EDT%MSU@CUNYVM.CUNY.EDU, libref-l@kentvm.kent.edu, NU021172@VM1.NoDak.EDU, big-internet@munnari.OZ.AU, isoc-interest@relay.sgi.com In-Reply-To: Valdis Kletnieks's message of Tue, 16 Nov 93 15:11:36 EST <931116.151136.EST.VALDIS@vtvm1.cc.vt.edu> Subject: Internet Encyclopedia (Interpedia) group project and mailing list X-Charset: ASCII X-Char-Esc: 29 ... >Please consult with a lawyer who is knowledgable about copyright law >before proceeding any further. I *strongly* suspect that you do *NOT* >want to place it in the public domain, but rather, that you retain the >copyright and make it freely redistributable. Note that there is a >*large* legal difference between the two - in particular, if you place >it in the public domain, (a) somebody can take it and market it and not >owe you *any* royalties, and (b) you cannot attach a 'hold harmless' >clause as a condition of copying. I must disagree on that! It's perfect to put it in the public domain or rather something similar and let whoever pleases distribute it for free or for a fee. There is one very good example of this in the development of Linux for the 80386 and 80486 PCs. It is _not_ in the public domain, but let's anyone distribute it and charge for it. It helps spreading the OS, gives support, and more. Unfortunately I don't have the notice at hand but I strongly suggest that this encyclopedia is _not_ copyrighted with too much restriction. /hj From owner-Big-Internet@munnari.OZ.AU Fri Nov 19 19:16:54 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28503; Fri, 19 Nov 1993 11:42:48 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA09100; Fri, 19 Nov 1993 11:40:10 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA09086; Fri, 19 Nov 1993 11:36:53 +1100 Received: from ics.uci.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17464; Fri, 19 Nov 1993 07:33:52 +1100 (from @localhost.ICS.UCI.EDU:stef@nma.com) Received: from nma.com by q2.ics.uci.edu id ad24610; 18 Nov 93 12:28 PST Received: from localhost by odin.nma.com id aa19917; 18 Nov 93 11:18 PST To: Valdis Kletnieks Cc: Henrik Johansson , DWILSON@crc.sd68.nanaimo.bc.ca, library@axon.eeap.cwru.edu, effnews@eff.org, socicom@auvm.american.edu, tk0jut2@mvs.cso.niu.edu, 21765EDT%MSU@cunyvm.cuny.edu, libref-l@kentvm.kent.edu, NU021172@vm1.nodak.edu, big-internet@munnari.OZ.AU, isoc-interest@relay.sgi.com Subject: Re: Internet Encyclopedia (Interpedia) group project and mailing list In-Reply-To: Your message of "Wed, 17 Nov 1993 13:22:31 EST." <931117.132231.EST.VALDIS@vtvm1.cc.vt.edu> Reply-To: Stef@nma.com From: Einar Stefferud Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 18 Nov 1993 11:18:52 -0800 Message-Id: <19915.753650332@odin.nma.com> Sender: stef@nma.com For a really good Free Redistribution License you should look at the ISODE Freely Available License. Not the new one from the ISODE Consortium. Or look at the MH license. Bot of these are much less restrivtive on what can be done with it. Both were developed with the intent to have commercial people/companies also make money off them if they can. GNU indeed makes it very difficult to use under too many conditions. Cheers...\Stef From your message Wed, 17 Nov 93 13:22:31 EST: } }If you are using Linux as a "good example", you are *NOT* disagreeing }with me, you are *agreeing* with me. What I said was that it should }*REMAIN* copyrighted - with explicit terms that *require* easy }redistribution. In fact, if you read the 'GNU Public License', you will }see a good example of a copyright that is *so* militantly }pro-redistribution that many companies refuse to use GNU tools because }they can't comply with the broad terms. } }Repeat after me: "Public Domain is *NOT* the same as Freely Redistributable". }And again: "Public Domain is *NOT* the same as Freely Redistributable". }And again: "Public Domain is *NOT* the same as Freely Redistributable". } } Valdis Kletnieks } Computer Systems Engineer } Virginia Polytechnic Institute } } } From owner-Big-Internet@munnari.OZ.AU Sat Nov 20 07:56:01 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16113; Sat, 20 Nov 1993 07:56:01 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA10164; Sat, 20 Nov 1993 07:55:17 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA10150; Sat, 20 Nov 1993 07:40:43 +1100 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14089; Thu, 18 Nov 1993 05:53:43 +1100 (from @VTVM1.CC.VT.EDU:VALDIS@VTVM1.CC.VT.EDU) Received: from VTVM1.CC.VT.EDU by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 5911; Wed, 17 Nov 93 13:53:08 EST Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 5151; Wed, 17 Nov 1993 13:53:06 -0500 Date: Wed, 17 Nov 93 13:22:31 EST From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Internet Encyclopedia (Interpedia) group project and mailing list To: Henrik Johansson Cc: DWILSON@CRC.SD68.NANAIMO.BC.CA, library@axon.EEAP.CWRU.Edu, effnews@eff.org, socicom@auvm.american.edu, tk0jut2@mvs.cso.niu.edu, 21765EDT%MSU@CUNYVM.CUNY.EDU, libref-l@kentvm.kent.edu, NU021172@VM1.NoDak.EDU, big-internet@munnari.OZ.AU, isoc-interest@relay.sgi.com In-Reply-To: <199311171212.AA14418@bond.nexus.comm.se> Message-Id: <931117.132231.EST.VALDIS@vtvm1.cc.vt.edu> On Wed, 17 Nov 1993 13:12:46 +0100 you said: >I must disagree on that! It's perfect to put it in the public domain >or rather something similar and let whoever pleases distribute it for >free or for a fee. There is one very good example of this in the >development of Linux for the 80386 and 80486 PCs. It is _not_ in the >public domain, but let's anyone distribute it and charge for it. It >helps spreading the OS, gives support, and more. Unfortunately I >don't have the notice at hand but I strongly suggest that this >encyclopedia is _not_ copyrighted with too much restriction. Ahem. If you are using Linux as a "good example", you are *NOT* disagreeing with me, you are *agreeing* with me. What I said was that it should *REMAIN* copyrighted - with explicit terms that *require* easy redistribution. In fact, if you read the 'GNU Public License', you will see a good example of a copyright that is *so* militantly pro-redistribution that many companies refuse to use GNU tools because they can't comply with the broad terms. Repeat after me: "Public Domain is *NOT* the same as Freely Redistributable". And again: "Public Domain is *NOT* the same as Freely Redistributable". And again: "Public Domain is *NOT* the same as Freely Redistributable". Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Sun Nov 21 06:41:18 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00749; Sun, 21 Nov 1993 06:41:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA11285; Sun, 21 Nov 1993 06:40:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA11271; Sun, 21 Nov 1993 06:37:06 +1100 Received: from [134.87.120.1] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13772; Sat, 20 Nov 1993 21:41:35 +1100 (from DWILSON@CRC.SD68.NANAIMO.BC.CA) Date: Sat, 20 Nov 1993 2:44:22 -0800 (PST) From: DWILSON@CRC.SD68.NANAIMO.BC.CA (Douglas P. Wilson) Message-Id: <931120024422.ad35@CRC.SD68.NANAIMO.BC.CA> Subject: Interpedia list oversubscription crisis now resolved and RFD out To: 21765EDT%MSU@CUNYVM.CUNY.EDU, INDEX-L%bingvmb@CUNYVM.CUNY.EDU, NU021172@VM1.NoDak.EDU, NewsCom@genesis.mcs.com, arielle@taronga.com, bi-l%bingvmb@CUNYVM.CUNY.EDU, big-internet@munnari.OZ.AU, cijs03@vaxa.strath.ac.uk, ctf-discuss@cis.upenn.edu, cussnet@stat.com, editors%brownvm@CUNYVM.CUNY.EDU, effnews@eff.org, etextctr%rutvm1@CUNYVM.CUNY.EDU, hyperbole@cs.brown.edu, interest-groups@nisc.sri.com, isoc-interest@relay.sgi.com, library@axon.EEAP.CWRU.Edu, libref-l@kentvm.kent.edu, mbu-l%ttuvm1@CUNYVM.CUNY.EDU, neci-discuss@pioneer.ci.net, nettrain@ubvm.cc.buffalo.edu, pacs-l%uhupvm1@CUNYVM.CUNY.EDU, socicom@auvm.american.edu, tk0jut2@mvs.cso.niu.edu, virtual%indycms@CUNYVM.CUNY.EDU, visions@library.sdsu.edu, wais-discussion@think.com, wais-talk@think.com X-Vmsmail-To: @LISTMOD.DIS This is a follow-up to a previous message about the Interpedia group project and mailing list. The previous posting was too successful, attracting over 1000 new subscribers to the mailing list, and causing something of a meltdown! Many new subscribers quickly fled the list in apparent panic as their mailboxes filled to overflowing. Others found it impossible to unsubscribe because of a bottleneck in request processing. All these problems are now solved, according to the list manager, Doug Luce, who will now act as a moderator, issuing a single message each day that will contain all substantial submitted messages for that day. All subscribers will now receive just the one low-noise message a day, called the Interpedia Digest. In other news: -- R L Samuell has established an archive of the Interpedia mailing list and related newsgroup messages. To reach it: gopher twinbrook.cis.uab.edu or telnet twinbrook.cis.uab.edu 70 -- the Request For Discussion for comp.infosystems.interpedia has gone out, and is being discussed on news.groups Please take part in this discussion. -- we have received an offer of a site to hold the first set of Interpedia articles, and soon will be able to accept submissions -- details to be announced soon on the Interpedia mailing list (see below for subscription information) -- other mailing lists for the Interpedia project are being set up, and will include an unmoderated list for quick turnaround of new developments Apologies to those who failed to get subscribed, were unable to unsubscribe, or got swamped with unwanted messages. The explosion of interest and rapid development of this project were beyond all expectations, and beyond our ability to cope. Find out what all this excitement is all about! New subscribers to the Interpedia mailing list are welcome. Please send requests to: interpedia-request@telerama.lm.com with the body of the text in this format: subscribe your.name@your.site.domain (To unsubscribe, please use the the same address and analogous format.) Subscribers will receive just one message a day, containing interesting discussions, which they may participate in by e-mail. Whether you subscribe or not, please participate in the discussion of comp.infosystems.interpedia on news.groups Doug Wilson dwilson@crc.sd68.nanaimo.bc.ca or dwilson@chaserv.almanac.bc.ca Subscription requests to: interpedia-request@telerama.lm.com From owner-Big-Internet@munnari.OZ.AU Mon Nov 29 04:11:49 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18757; Mon, 29 Nov 1993 04:11:49 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA20790; Mon, 29 Nov 1993 04:10:45 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA20776; Mon, 29 Nov 1993 04:04:18 +1100 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18549; Mon, 29 Nov 1993 04:04:40 +1100 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA01903; Sun, 28 Nov 93 12:04:36 EST Message-Id: <9311281704.AA01903@tipper.oit.unc.edu> To: big-internet@munnari.OZ.AU Subject: How hierachical is the Internet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Nov 93 12:04:36 -0500 From: Simon E Spero In a lot of the discussions on CIDR the internet seems to be portrayed as having a somewhat hiearchical topology (i.e. backbone feeds midlevel feeds regional feeds site). Has anybody got any order of magnitde figures on how well this model matches up to reality, particularly if each backbone is treated as a large cloud? Also, when the model doesn't fit, how many connections do the exceptions normally have? Thanks Simon From owner-Big-Internet@munnari.OZ.AU Mon Nov 29 08:26:33 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25512; Mon, 29 Nov 1993 08:26:33 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA21019; Mon, 29 Nov 1993 08:25:47 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA21005; Mon, 29 Nov 1993 08:20:53 +1100 Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22824; Mon, 29 Nov 1993 06:40:48 +1100 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA04309; Sun, 28 Nov 93 14:38:03 -0500 Date: Sun, 28 Nov 93 14:38:03 -0500 Message-Id: <9311281938.AA04309@worldlink.worldlink.com> From: David Piscitello To: iesg@cnri.reston.va.us, tuba@lanl.gov, atm@hpl.hp.com Cc: ietf-ppp@ucdavis.edu, iplpdn@cnri.reston.va.us, big-internet@munnari.OZ.AU Subject: confirming rumors... Hi, Some of you may have heard that I've resigned from Bellcore, to pursue a new career. I will continue to serve as an INT AD at least until my term is over. Stev Knowles has picked up a great deal of the load while I've sorted things out, and I want to publicly thank him. I expect to be up and operational by December 4, 1993. I'll also continue to participate in IPng activities, esp. TUBA. Thanks for your patience over the last month. I've allowed some things to fall into a black hole, and for this I apologize; I'm slowly crawling out of the hole, so if you can bear with me for one more week, I'd appreciate it. From owner-Big-Internet@munnari.OZ.AU Tue Nov 30 02:56:36 1993 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09590; Tue, 30 Nov 1993 02:56:36 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA22009; Tue, 30 Nov 1993 02:55:53 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA21995; Tue, 30 Nov 1993 02:44:13 +1100 Received: from corp.timeplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09241; Tue, 30 Nov 1993 02:44:35 +1100 (from malis@maelstrom.timeplex.com) Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF #2740 ) id <01H5VV8CNJ9C90MTLP@sys30.timeplex.com>; Mon, 29 Nov 1993 10:43:10 EDT Received: from localhost by maelstrom.timeplex.com (4.1/SMI-4.1) id AA14578; Mon, 29 Nov 93 08:12:08 EST Date: 29 Nov 1993 08:12:07 -0500 From: Andy Malis Subject: Re: confirming rumors... In-Reply-To: Your message of "Sun, 28 Nov 1993 14:38:03 EST." <9311281938.AA04309@worldlink.worldlink.com> To: David Piscitello Cc: ietf-ppp@ucdavis.edu, iplpdn@cnri.reston.va.us, big-internet@munnari.OZ.AU, malis@maelstrom.timeplex.com Message-Id: <9311291312.AA14578@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Dave, Congrats! Are you ready to publicly state what you're going to be doing? Cheers, Andy