From owner-Big-Internet@munnari.OZ.AU Wed Mar 9 08:03:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00255; Wed, 9 Mar 1994 07:18:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA00635; Wed, 9 Mar 1994 07:17:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA00632; Wed, 9 Mar 1994 08:15:21 +1100 Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25468; Wed, 9 Mar 1994 05:02:43 +1000 (from garces@watson.ibm.com) Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9823; Tue, 08 Mar 94 14:02:40 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 4717; Tue, 8 Mar 1994 14:02:39 EST Received: from dolphins.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Tue, 08 Mar 94 14:02:38 EST Received: by dolphins.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA48195; Tue, 8 Mar 1994 14:02:36 -0500 Date: Tue, 8 Mar 1994 14:02:36 -0500 From: garces@watson.ibm.com (Luis E. Garces) Message-Id: <9403081902.AA48195@dolphins.watson.ibm.com> To: big-internet@munnari.OZ.AU Subject: subscribe subscribe garces@watson.ibm.com From owner-Big-Internet@munnari.OZ.AU Thu Mar 17 07:31:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13980; Thu, 17 Mar 1994 07:31:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA10075; Thu, 17 Mar 1994 07:29:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA10061; Thu, 17 Mar 1994 08:16:31 +1100 Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08439; Thu, 17 Mar 1994 05:09:09 +1000 (from sob@hsdndev.harvard.edu) Date: Wed, 16 Mar 94 14:08:39 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403161908.AA25022@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU Subject: IPng mailing list information and update For those of you who might be interested in what the IPng directorate has been up to the archive of the directorate mailing list has been placed on hsdndev.harvard.edu in the directory pub/ipng/mailing.list for anonymous ftp and gopher access. There has been quite a bit of quite interesting discussion on the directorate list. You might want to pick up some of the discussion on the big-internet list. (pro, con or incredulous) The IPng area has received a number of white papers in response to RFC1550 (and there are a few more due to trickle in soon). These white papers have been reviewed for clarity by the IPng directorate and as soon as revisions are received or the author decides to let the paper go as-is the white papers will be placed in pub/ipng/wp on the same machine and submitted as internet-drafts. The main objective of the IPng effort during the Seattle IETF meeting will be to reach a consensus on the IPng requirements document. This document is based on the work that Frank and Craig have done and is in the process of being updated with the information that we have received during the white paper process. The final document will be the result of the discussions in Seattle and the comments from the external review panel. Allison & Scott From owner-Big-Internet@munnari.OZ.AU Thu Mar 17 08:30:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16265; Thu, 17 Mar 1994 08:30:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id IAA10146; Thu, 17 Mar 1994 08:29:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA10132; Thu, 17 Mar 1994 09:24:54 +1100 Received: from mail.swip.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16039; Thu, 17 Mar 1994 08:25:54 +1000 (from kpk-big-internet-owner@edvina.se) Received: from c3po.edvina.se by mail.swip.net (8.6.4/2.01) id XAA12360; Wed, 16 Mar 1994 23:25:00 +0100 Received: by c3po.edvina.se (4.1/SMI-4.1) id AA07636; Wed, 16 Mar 94 23:24:11 +0100 Received: from murtoa.cs.mu.OZ.AU by c3po.edvina.se (4.1/SMI-4.1) id AA05612; Wed, 16 Mar 94 23:15:59 +0100 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA10087; Thu, 17 Mar 1994 07:38:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id IAA10061; Thu, 17 Mar 1994 08:16:31 +1100 Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08439; Thu, 17 Mar 1994 05:09:09 +1000 (from sob@hsdndev.harvard.edu) Date: Wed, 16 Mar 94 14:08:39 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9403161908.AA25022@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU Subject: IPng mailing list information and update For those of you who might be interested in what the IPng directorate has been up to the archive of the directorate mailing list has been placed on hsdndev.harvard.edu in the directory pub/ipng/mai From owner-Big-Internet@munnari.OZ.AU Mon Mar 21 02:32:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11649; Mon, 21 Mar 1994 02:32:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA14568; Mon, 21 Mar 1994 02:30:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA14547; Mon, 21 Mar 1994 02:17:32 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11285; Mon, 21 Mar 1994 02:18:41 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU From: Big-Internet-Request@munnari.OZ.AU Subject: B-I list archives index Date: Mon, 21 Mar 1994 02:18:44 +1000 Message-Id: <10092.764180324@munnari.OZ.AU> Sender: kre@munnari.OZ.AU I have created a group of index files for the B-I list archives to cover the period since the list started (July 1991) until the end of 1993. (No disrespects, but there has been nothing worth indexing so far in 94...) I have put 5 new files in the munnari.oz.au:big-internet/list-archive directory. They are ... INDEX.1991-1993.README which gives info similar to this. INDEX.1991-1993.Chronological a simple message/line list of every B-I message, in chronological order INDEX.1991-1993.Subjects a sorted list of Subject lines (with "re" and similar crud deleted) followed by a list of all messages sent on that Subject (ie: using that subject header, whatever the message was about), sorted by the author of the message. INDEX.1991-1993.Authors a sorted list of all authors of messages to B-I, then for each author, a list of the subjects on which they expressed an opinion, and the messages in which those opinions appeared. Authors in this are e-mail addresses, sort order is simple lexicographical on the (case-folded) e-mail addr, apart from being easiest, this also seems to give the best results, as while people move hosts, they tend to geep the same user name. This groups messages by the same person closer together. Message lists in the above comprise the archive file name (which by its nature gives the year and month of the message), and a "message index" into the archive file - a simple index of message in the file (message 1, message 2, ...) Because message counts may be difficult for some to deal with, the fifth index file ... INDEX.1991-1993.Line-Numbers is a simple translation of the message numbers used everywhere else into archive file name, and line number offset in the file. Should anyone want to do any further analysis on this, say to discover the most prolific writer, or something (don't bother, the answer is obvious, by a long way), by my guest. Also, if anyone has some good indexing software that could do something reasonable with the contents of the messages, rather than just the Subject lines, I may be interested in that as well (sometime after the IETF). kre From owner-Big-Internet@munnari.OZ.AU Mon Mar 21 04:12:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14732; Mon, 21 Mar 1994 04:12:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA14670; Mon, 21 Mar 1994 04:10:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA14656; Mon, 21 Mar 1994 04:08:02 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13268; Mon, 21 Mar 1994 03:25:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16105; Sun, 20 Mar 94 12:25:18 -0500 Date: Sun, 20 Mar 94 12:25:18 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403201725.AA16105@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: B-I list archives index Cc: jnc@ginger.lcs.mit.edu I have created a group of index files for the B-I list archives Thanks for watching over this stuff; it may seem to some like useless bits, but it's important history. At least one very important IETF WG's (the Open Routing WG) mail archives seem to have vanished, with the result that I was unable to correctly credit the sources of various ideas in Nimrod. Should anyone want to do any further analysis on this, say to discover the most prolific writer, or something (don't bother, the answer is obvious, by a long way), by my guest. Gee, I wonder who that would be? :-) Also, if anyone has some good indexing software that could do something reasonable with the contents of the messages, rather than just the Subject lines, I may be interested in that as well What would be *really* useful is to put the whole deal into something where you can browse either index, mouse on a item, and have it pop up, rather than manually have to go grovel through log files... Noel From owner-Big-Internet@munnari.OZ.AU Tue Mar 22 01:12:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06249; Tue, 22 Mar 1994 01:12:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA15743; Tue, 22 Mar 1994 01:11:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA15729; Tue, 22 Mar 1994 01:02:22 +1000 Received: from x400gate.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05293; Tue, 22 Mar 1994 00:43:08 +1000 (from tjj@bnr.ca) X400-Received: by mta bnr.ca in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 21 Mar 1994 09:41:06 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 21 Mar 1994 09:38:50 -0500 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Mon, 21 Mar 1994 04:32:00 -0500 Date: Mon, 21 Mar 1994 09:32:00 +0000 X400-Originator: /dd.id=1574365/g=tim/i=tj/s=jenkins/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.596:21.02.94.14.38.50] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: B-I list ... From: "tim (t.j.) jenkins" Sender: "tim (t.j.) jenkins" Message-Id: <"14600 Mon Mar 21 09:38:58 1994"@bnr.ca> To: jnc@ginger.lcs.mit.edu Cc: "robert (r.w.) eros" , "richard (r.j.) thomas" , "dwight (d.) jamieson" , "ross (r.m.) macgillivray" , "gary (g.p.) mussar" , big-internet@munnari.OZ.AU Subject: Re: B-I list archives index Hi! Sorry to broadcast this out, but my earlier attempt to 'unsubscribe' has obviously not worked. Please remove me from the mailing list, or, barring that, tell how I should do that myself. Thanks, Tim From owner-Big-Internet@munnari.OZ.AU Tue Mar 22 02:33:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08599; Tue, 22 Mar 1994 02:33:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA15895; Tue, 22 Mar 1994 02:31:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA15892; Tue, 22 Mar 1994 02:30:54 +1000 Received: from mentor.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08570; Tue, 22 Mar 1994 02:32:02 +1000 (from dls@mentor.cc.purdue.edu) Received: from localhost by mentor.cc.purdue.edu (5.61/Purdue_CC) id AA18967; Mon, 21 Mar 94 11:31:52 -0500 Message-Id: <9403211631.AA18967@mentor.cc.purdue.edu> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU Subject: Re: New old idea In-Reply-To: Your message of "Mon, 21 Mar 1994 14:48:34 +0100." <9403211348.AA22233@dxcoms.cern.ch> Date: Mon, 21 Mar 1994 11:31:37 -0500 From: David L Stevens Since it requires all routers to be upgraded and still does not allow full connectivity, why use IPv4? Seems like there is extra work in moving to the transition, when it would be just as easy to install IPNG (whatever that will be) and require routers to route both (about the same as requiring them to handle the option). But when you're done, you're done, where with an option scheme, you have another conversion to IPNG after that. I think the most straightforward way to do it is to simply change the version number, double the IP address sizes (and the length field, while you're at it), and then allocate the 32 bit per-site number and leave the second 32 bits for the site. Masks for each (independently, for a 2-tiered structure and smaller routing tables on the backbone, or just a 64-bit mask) to handle routing. IPv4 connectivity and routing is the same, IPNG routing is done independently. Any host wanting connectivity to new hosts needs IPNG. Any host wanting connectivity to both needs both. The algorithms and much of the code can be shared between IPv4 and IPNG. The real work in either scheme is fixing the sizes of things in all the rest of the protocol suite. I don't think we want to do that twice, though... +-DLS From owner-Big-Internet@munnari.OZ.AU Tue Mar 22 02:39:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05649; Tue, 22 Mar 1994 00:53:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA15702; Tue, 22 Mar 1994 00:51:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA15671; Tue, 22 Mar 1994 00:33:55 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02797; Mon, 21 Mar 1994 23:48:47 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03315; Mon, 21 Mar 1994 14:48:35 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA22233; Mon, 21 Mar 1994 14:48:34 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403211348.AA22233@dxcoms.cern.ch> Subject: New old idea To: big-internet@munnari.OZ.AU Date: Mon, 21 Mar 1994 14:48:34 +0100 (MET) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10141 After some prompting by a few people, I have just submitted the attached as an Internet Draft, and informally requested a last-minute BOF slot at Seattle. Unfortunately I will shortly be travelling, so flames may receive no reply until after Seattle. Brian --- Network Working Group B. Carpenter Internet Draft CERN 21 March 1994 Expires 26 September 1994 File name TBD Address Extension by IP Option Usage (AEIOU) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Distribution of this memo is unlimited. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Abstract This document proposes an addressing extension mechanism for IP as a possible life extender while awaiting IPng. AEIOU proposal It is possible that no IPng candidate will be considered mature enough in time to be widely deployed before the IPv4 address space is fully allocated. This document suggests a way to cope with this risk. Although it does not propose a new IPng candidate, the proposal does amount to a major change to IP, requiring new versions of host and router software. However, the impact on existing code is much less than that of any IPng proposal. By the same token, the only problem that it tackles is the address space problem. During the process of collecting requirements for IPng, a number of people have stated the need to fix the IPv4 address space problem by Carpenter [Page 1] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 flexible address extensions beyond 32 bits. However, if this means that IPv4 addresses should be replaced by bigger addresses, it breaks the current Internet routing and addressing architecture. AEIOU proposes to tackle the problem differently. Firstly, three conservative measures should be taken: 1. Do not extend the global Internet address space or modify the global routing architecture. 2. Do deploy CIDR and BGP4. Be very restrictive on allocations to new sites (i.e. give them the minimum CIDR space that will satisfy them for one or two years). 3. Do not allocate any new network numbers to sites that already have at least one network number of any class (A, B, C). Try to recover unused numbers and CIDRise sparse networks. Encourage use of RFC 1597. Secondly, provide a simple address extension mechanism as an IP option: 4. Add two new IPv4 options "Source Address Extension" (SAE) and "Destination Address Extension" (DAE). Type: [copied, class 0, option number TBD] Length: 6 Data: 4 octet address extension (AE) The AE options are carried transparently and survive fragmentation. Neither, either, or both may be present. 5. AEs are allocated by a site (not to a site) when it has run out of addresses in its share of the IPv4 32-bit address space. The AE space is structured like Class A, B and C space and all normal subnetting techniques apply. A host in AE space can be considered to have an address in the form of a 64-bit couplet (site address, AE). Each site has a globally unique 32-bit site address, which can be any IPv4 address from the site's IANA-allocated IPv4 address space. This site address then "hides" all the site's AEs. For example, the site currently allocated the Class B network 128.141 could use 128.141.141.141 as its site address, and this would be the wide-area address used for routing all packets to the site's 32-bit AE space. Wide-area routing does not change. Routing to non-AE hosts does not change. 6. Hosts now fall into three classes: Carpenter [Page 2] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 OLD hosts; still running 32-bit IP only. NEW hosts; AE options implemented, but no allocated AE (i.e. NEW hosts are still in the global 32-bit space.) By convention, AE=0.0.0.0 for NEW hosts. AE hosts; AE options implemented, and an AE allocated. AE hosts are in the new 64-bit space. The following table shows which combinations of hosts can talk to each other, using 32 or 64 bit addresses. OLD NEW AE ---------------------- OLD | 32 | 32 | no | (There might be some cases | | | | where OLD and AE hosts can NEW | 32 | 32 | 64 | talk, if they are on the | | | | same subnet.) AE | no | 64 | 64 | ---------------------- The outline of the deployment plan follows. Stage 1: A site address is allocated for every Internet site. On-site routers are upgraded to AE. All servers are upgraded from OLD to NEW. OLD clients can still access NEW servers. Stage 2: Ensure that all newly installed clients are AE hosts. New clients no longer consume 32-bit addresses. Stage 3: Progressively convert OLD clients to AE. This means upgrading software versions, and renumbering clients. At the same time, RFC 1597 addresses could be transformed into AEs if required. Stage 4: Sites will now have many unused 32-bit addresses recovered during Stage 3. A fraction of these can be recovered by further use of CIDR, and can be re-allocated as site addresses for new Internet sites. Stage 5: Theoretically, all servers can now be converted from NEW to AE. At this stage almost all 32-bit addresses can be recovered and re-used as in Stage 4. We now have a two-tier Internet address scheme (32-bit site address space managed by IANA, and 32-bit AE space managed by individual sites). Thirdly, some more details: 7. IP packets flow from source to the destination site exactly as Carpenter [Page 3] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 they do today. The SAE and DAE options are copied (even if fragmentation occurs). At the ingress router on the destination site, if the DAE option is present, it is used by local routing protocols to route the packet to the correct physical subnet. These routing protocols can be any of those in use today, except that they look at the DAE field instead of the normal IP destination address (DA). This is not optimal for router performance. However, the obvious solution of having the ingress router swap the DAE and the DA does not work, since this would disturb the TCP and UDP pseudo-header checksum calculation. 8. On a subnet such as Ethernet, a rather straightforward extension of ARP (EARP, extended ARP) is needed to obtain the physical address corresponding to the (site address,DAE) couplet. For further study, but clearly soluble. 9. DNS RR's will include the AE when it exists. The DNS reply will directly imply whether a host is OLD (no AE), NEW (AE = 0.0.0.0) or AE. 10. I haven't worked out how the AE is handled at the socket API yet. This is the biggest problem if software changes are to be minimised. It's no worse than for SIPP, of course. It can also be argued that forcing applications to use an API with multiple address formats (for example, AF_INET and AF_INETE in the case of BSD sockets) is good, because this will be needed for the real IPng when it comes. 11. FOOBAR (RFC 1545) can handle it for FTP. 12. etc. Lots more to be written, by analogy with the SIPP and TUBA transition documents. References TBD Disclaimer and acknowledgements. This is a personal view and does not necessarily represent that of my employer. AEIOU is not the same as EIP (RFC 1385) but it is in some sense a simple inversion of the EIP idea, which has been at the back of my mind for two years. It resembles the original (1992) IPAE draft too and has some similarities to TP/IX (RFC 1475). Other ideas came from the IPng transition discussions in general, and there is a clear Carpenter [Page 4] Draft Address Extension by IP Option Usage (AEIOU) 21 March 1994 resemblance to the DECnet Phase V deployment process. Various individuals have commented on the earlier versions of this document; a full list will be included in a future version. Author's Address Brian E. Carpenter Group Leader, Communications Systems Phone: +41 22 767-4967 Computing and Networks Division Fax: +41 22 767-7155 CERN Telex: 419000 cer ch European Laboratory for Particle Physics E-mail: brian@dxcoms.cern.ch 1211 Geneva 23, Switzerland Expires 26 September 1994 File name TBD Carpenter [Page 5] From owner-Big-Internet@munnari.OZ.AU Tue Mar 22 03:24:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09955; Tue, 22 Mar 1994 03:12:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA15950; Tue, 22 Mar 1994 03:11:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA15927; Tue, 22 Mar 1994 02:55:02 +1000 Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09548; Tue, 22 Mar 1994 02:56:10 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20660; Mon, 21 Mar 1994 17:56:02 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01349; Mon, 21 Mar 1994 17:56:01 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9403211656.AA01349@dxcoms.cern.ch> Subject: Re: New old idea To: big-internet@munnari.OZ.AU Date: Mon, 21 Mar 1994 17:56:01 +0100 (MET) In-Reply-To: <9403211631.AA18967@mentor.cc.purdue.edu> from "David L Stevens" at Mar 21, 94 11:31:37 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 314 David, The point is that it does NOT require all routers to be upgraded. Those on the backbones don't see the change (until they want to). Sites don't see the change until they need to. What you suggest is closer to TP/IX. But yes, this point can be debated, and certainly will be in Seattle. Thanks Brian From owner-Big-Internet@munnari.OZ.AU Tue Mar 22 11:11:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23569; Tue, 22 Mar 1994 09:53:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA16289; Tue, 22 Mar 1994 09:51:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA16275; Tue, 22 Mar 1994 09:34:57 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17907; Tue, 22 Mar 1994 07:08:35 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id NAA24763; Mon, 21 Mar 1994 13:08:21 -0800 Message-Id: <199403212108.NAA24763@Mordor.Stanford.EDU> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU Subject: Re: New old idea Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 21 Mar 94 14:48:34 +0100. <9403211348.AA22233@dxcoms.cern.ch> Date: Mon, 21 Mar 94 13:08:21 -0800 From: Dave Crocker X-Mts: smtp If a truly interim hack were desired, for the circumstances matching those in your proposal (inadequate maturity for any of the contenders) then I think that Bob Hinden's original idea of encapsulating IP inside IP would be preferable. It does not require a change to every node. It allows the fastpath to stay fast most of the time. And no one would EVER think that it's the longterm solution... d/ From owner-Big-Internet@munnari.OZ.AU Tue Mar 22 12:33:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00365; Tue, 22 Mar 1994 12:33:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA16440; Tue, 22 Mar 1994 12:31:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA16437; Tue, 22 Mar 1994 12:30:45 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00344; Tue, 22 Mar 1994 12:31:54 +1000 (from smart@mel.dit.csiro.au) Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA06273 (5.65c/IDA-1.4.4/DIT-1.3 for big-internet@munnari.oz.au); Tue, 22 Mar 1994 12:32:10 +1000 Message-Id: <199403220232.AA06273@shark.mel.dit.csiro.au> To: big-internet@munnari.OZ.AU Subject: Re: New old idea In-Reply-To: Your message of "Mon, 21 Mar 1994 13:08:21 PST." <199403212108.NAA24763@Mordor.Stanford.EDU> Date: Tue, 22 Mar 1994 12:31:52 +1000 From: Bob Smart The key aspect of Brian's proposal that is new, at least to me, is extending the address space on the right instead of on the left. You can do it with an option or you can do it with encapsulation: that is orthogonal to the main point of the proposal. But when I come to think about it it isn't operationally different to using source routing which was suggested long ago. I think some things have made source routing seem more attractive: 1. The PIP/SIPP discussions have shown the intrinsic value of source routing in a complex multi-supplier network. 2. The tendency of corporations to have only a small number of machines live on the Internet with other machines using a private numbering scheme behind a firewall. This internal-only IP number looks rather like address extension on the right. Maybe if the SIPP folks switched to 32 bit address chunks instead of 64 bits then they could make easier use of the existing IPv4 infrastructure. Bob Smart From owner-Big-Internet@munnari.OZ.AU Fri Mar 25 11:42:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06561; Fri, 25 Mar 1994 09:55:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id JAA19928; Fri, 25 Mar 1994 09:52:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA19925; Fri, 25 Mar 1994 09:41:40 +1000 Received: from uu7.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03054; Fri, 25 Mar 1994 08:07:53 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu7.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA03615 for big-internet@munnari.oz.au; Thu, 24 Mar 94 17:07:49 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id OAA02269; Thu, 24 Mar 1994 14:05:14 -0800 Message-Id: <199403242205.OAA02269@aland.bbn.com> To: int-serv@isi.edu Cc: big-internet@munnari.OZ.AU Subject: Agendas for INT SERV BOF/WG Meetings Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 24 Mar 94 14:05:13 -0800 Sender: craig@aland.bbn.com Hi: Apparently our approval as WG has not gone through all the hoops yet (I haven't had a chance to learn why -- hope to report on Monday), so we're a BOF. Here are the agendas for the two meetings. A small package of reading will follow in a separate note. Monday 1330-1530 Organizational Meeting (WG Charter, Tasks, Schedule, etc) The focus of this meeting is to discuss the proposed WG organization, its charter and the work we plan to do, how we propose to make sure the work gets done, and schedule the meetings between this IETF and the next one (we plan at least two). This meeting will largely take the form of an informal talk by Craig Partridge (proposed general chair of the WG), presumably mixed with lots of questions. Monday 1600-1800 IPng Issues At the request of the IPng Directorate, we're jumping ahead in the WG's process to take up the question of requirements that integrated services place upon IPng. The output of this meeting will be a set of resolutions that will be used to generate a White Paper. * Intro (list of known issues, how we propose to manage the discussion, how White Paper will be produced and reviewed) -- Craig Partridge * Datagram classification issues - John Wroclawski * Discussion of classification issues * Authentication issues - Dave Clark * Discussion of authentication issues * Other topics (if any) and discussion * Determining what goes in White Paper - Craig From owner-Big-Internet@munnari.OZ.AU Fri Mar 25 11:59:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08187; Fri, 25 Mar 1994 10:35:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA19981; Fri, 25 Mar 1994 10:32:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id KAA19967; Fri, 25 Mar 1994 10:23:16 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04267; Fri, 25 Mar 1994 08:45:03 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA02794 for big-internet@munnari.oz.au; Thu, 24 Mar 94 17:40:05 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id OAA02338; Thu, 24 Mar 1994 14:37:15 -0800 Message-Id: <199403242237.OAA02338@aland.bbn.com> To: int-serv@isi.edu, big-internet@munnari.OZ.AU Subject: reading for INT SERV meetings Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 24 Mar 94 14:37:13 -0800 Sender: craig@aland.bbn.com There are three items of recommended reading: 1. The Integrated Services overview document (from last IETF's BOF) ftp.isi.edu:pub/braden/isip/overview.{ps,txt} 2. The Integrated Services WG proposed charter and management plan (appended to this note) 3. Section 4 of the recent IAB workshop report ftp.isi.edu:pub/braden/IABworkshop.txt (just section 4) *************************************************************************** Integrated Services Working Group Management Plan The General Chair is Craig Partridge (BBN). The Co-Chairs are Dave Clark (MIT), Scott Shenker(XEROX), and John Wroclawski (MIT) The dual reasons for this management structure are: (1) The WG will have do considerably more outreach into the larger networking community than the typical IETF working group. For instance, one of the important tasks is to convince the larger public that IP is suitable for integrated services. So we need management manpower to do outreach. (2) The WG has a lot of work to do and swiftly. Even though we plan to spin off WGs as fast as we can, a lot of key architectural decisions will need to be made in one place (e.g., by this WG) if the final architecture is to be sound. So we need management manpower just to keep the WG moving. So Craig has primary responsibility for keeping the WG moving, and Dave, Scott, and John have primary responsibility for outreach to different communities (and titles sufficient to show they can speak for the WG). *************************************************************************** Integrated Services Working Group Charter Description of Working Group: Recent experiments demonstrate the capability of packet switching protocols to support Integrated Services - the transport of audio, video, real-time, and classical data traffic within a single network infrastructure. These experiments suggest that expanding the Internet service model would better meet the needs of these diverse applications. The purpose of this working group is to specify this enhanced service model and then to define and standardize certain interfaces and requirements necessary to implement the new service model. The working group will focus on defining a minimal set of global requirements which transition the Internet into a robust integrated-service communications infrastructure. Enhancements to individual protocols (e.g., adding additional routing information to routing protocols, or choosing IP queueing disciplines for routers) will be left to other working groups, except in those rare cases where detailed definitions of behavior are critical to the success of the enhanced architecture. Extending the Internet service model raises a series of questions. The working group will focus on the three problems listed below: (1) Clearly defining the services to be provided. The first task faced by this working group is to define and document the enhanced Internet service model. (2) Defining the application service, router scheduling and (general) subnet interfaces. The working group must define at least three high-level interfaces; that expressing the application's end-to-end requirements, that defining what information is made available to individual routers within the network, and the additional expectations (if any) the enhanced service model has for subnet technologies. The working group will define these abstract interfaces. (3) Developing router validation requirements which can ensure that the proper service is provided. We assume that the Internet will continue to contain a heterogeneous set of routers, running different routing protocols and using different forwarding algorithms. The working group will seek to define a minimal set of additional router requirements which ensure that the Internet can support the new service model. Rather than presenting specific scheduling and admission control algorithms which must be supported, these requirements will likely take the form of behavioral tests which measure the capabilities of routers in the integrated services environment. This approach is used because no single algorithm seems likely to be appropriate in all circumstances at this time. We expect to generate three RFCs as a products of performing these tasks. In addition, because many of the integrated services concepts are new, the WG may produce informational RFCs explaining specific algorithms that may be appropriate certain circumstances and may host some educational meetings to assist both IETF members and members of the larger Internet community to understand the proposed enhancements to IP. The WG proposes to hold regular meetings beyond those held at IETF. Goals and Milestones: [These milestones are conservative. We hope to finish much more quickly than this.] 4/94: Seattle IETF: First full meeting of working group. Discuss proposed service model. Discuss strategy for addressing other issues. 11/94: Submit informational RFC on service model. Discuss initial draft documents describing router requirements and strategies for behavioral testing. Hold coordination meeting with RSVP Working Group (and perhaps others as well) to discuss Application (end-to-end) PI. 3/95: Continue discussion of router requirements. Develop experimental verification of behavioural testing approach. Continue discussion of API and subnet models. 11/95: Submit router requirement RFC. Finalize API. 3/96: Submit API. Finalize subnet model. 6/96: Submit subnet RFC. The WG mailing list is int-serv@isi.edu From owner-Big-Internet@munnari.OZ.AU Fri Mar 25 12:49:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11008; Fri, 25 Mar 1994 11:55:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA20062; Fri, 25 Mar 1994 11:52:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA20059; Fri, 25 Mar 1994 11:41:24 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10502; Fri, 25 Mar 1994 11:42:28 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA00385; Thu, 24 Mar 94 20:34:38 EST Message-Id: <9403250134.AA00385@tipper.oit.unc.edu> To: Craig Partridge Cc: int-serv@isi.edu, big-internet@munnari.OZ.AU Subject: Re: reading for INT SERV meetings In-Reply-To: Your message of "Thu, 24 Mar 94 14:37:13 PST." <199403242237.OAA02338@aland.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Mar 94 20:34:37 -0500 From: Simon E Spero Convince the general public that IP is suitable for Integrated Services?> I think you have to convince half the IETF too! Mind you, judging from our experiences here with the North Carolina Information Porkway, ATM gives you disintegrated services too. Simon // NCIH - gigabits for biga-grits. From owner-Big-Internet@munnari.OZ.AU Fri Mar 25 15:51:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13162; Fri, 25 Mar 1994 12:54:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id MAA20129; Fri, 25 Mar 1994 12:52:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id MAA20115; Fri, 25 Mar 1994 12:33:38 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12392; Fri, 25 Mar 1994 12:34:16 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 25 Mar 94 11:20:38 +0900 From: Masataka Ohta Message-Id: <9403250220.AA10346@necom830.cc.titech.ac.jp> Subject: Re: reading for INT SERV meetings To: ses@tipper.oit.unc.edu (Simon E Spero) Date: Fri, 25 Mar 94 11:20:36 JST Cc: craig@aland.bbn.com, int-serv@isi.edu, big-internet@munnari.OZ.AU In-Reply-To: <9403250134.AA00385@tipper.oit.unc.edu>; from "Simon E Spero" at Mar 24, 94 8:34 pm X-Mailer: ELM [version 2.3 PL11] > Convince the general public that IP is suitable for Integrated Services?> > I think you have to convince half the IETF too! Mind you, judging from our > experiences here with the North Carolina Information Porkway, ATM gives > you disintegrated services too. > Simon // NCIH - gigabits for biga-grits. Could you read the following Internet Draft too see that ATM can give us Integrated Services with IP. Masataka Ohta ------------------------------------------------------------------------ INTERNET DRAFT M. Ohta draft-ohta-ip-over-atm-00.txt Tokyo Institute of Technology March 1994 Conventional IP over ATM Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The possibility to construct a conventional model to transfer IP over ATM is studied. The model contains concepts of subnet, bridges, routers, broadcast and so on, all of which are familiar with the model of IP over Ethernet. Still, the model allows QoS assured seamless network level (not datalink level) ATM connection which can be directly supported by existing ATM hardware. That is, new communication model with resource reservation such as RSVP or STII can be supported efficiently. Introduction This memo describes a framework of transmitting IP packets over existing ATM hardware without assuming any change to the existing model of transmitting IP over other media. ATM is a good candidate of the platform for very high speed QoS (Quality of Services [RSVP, STII]) assured datalink. But, unlike enthusiastic ATM lovers, the Author does not think ATM will rule the world. On the other hand, the Author believes IP will rule the M. Ohta Expires on Sept. 5, 1994 [Page 1] INTERNET DRAFT Conventional IP over ATM March 1994 world, at which time ATM based equipments must cooperate with other media such as Ethernet or something like Ethernet. To make the cooperation smooth, it is better if the model of IP over ATM is no different from the model of IP over Ethernet. Thus, unlike the model of "Classical IP and ARP over ATM" [CLIP], which is modified, non-classical IP technology over PDN-like, classical, ATM, the conventional model tryies to keep IP as classical and conventional as possible. The conventional model is designed so that existing ATM hardware can be used as is. Overview of the WAN/LAN model of the Conventional IP While other models of IP over ATM [CLIP, IPATM] assumes PDN like ATM WAN, which somewhat affects ATM LAN model and is a lot different from Ethernet LAN, the conventional model assumes no fundamental difference between Ethernet LAN, ATM LAN and ATM WAN. It seems to the Author that there is common misunderstanding of many ATM experts that cell-by-cell relaying can only be performed at datalink layer, which make thier model unnatural. The last section shows how network layer cell-by-cell relaying is possible. Just as the current IP LAN over Ethernet and IP WAN are fundamentally same, ATM LAN and ATM WAN of the model are fundamentally same. That is, just as the current T3 backbone, the WAN model of this memo is constructed by leased lines directly connecting IP routers, which directly support IP protocols including routing. Routing packets will be propagated by WAN operators as maintenance packets. When IP rules the world and WAN is IP, there is no cloud. So, ROLC (Routing over Large Cloud) [ROLC] technology is not necessary. With the conventional model, just as Ethernet equipments, ATM switches are classified into routers or bridges (or brouters, maybe). whose roles are no different from those of Ethernet equipments. Bridges are datalink layer entity which connect several physical layers. Bridges copy the incoming packets to all of the output ports without trying to optimize the path. If a bridge is a learning bridge and knows to which interface the destination is attached, unnecessary copying can be suppressed. If a link level topology contains a loop, bridges should support spanning tree algorithm to avoid packets copied infinitely along the loop. M. Ohta Expires on Sept. 5, 1994 [Page 2] INTERNET DRAFT Conventional IP over ATM March 1994 Routers are network layer entity which connect several data link layers. Routers relay packets beyond (sub-)networks. Routers exchange routing information and maintains routing tables. Logically, each packet is relayed to the optimal interface by looking up the routing table. Actually, some cache or bypass is often used to minimize the routing delay of complex table looking up. It is not the business of bridges to choose the best path to the destination. Doing so will make the link level layer as complex as the conventional link and network level layers added together, which is the destruction of layering. So, to operate a network with a lot of hosts and some amount of redundant pathes, the network should be divided into several link layers connected by routers to make use of the bandwidth of redundant pathes. It is impractical to have a single datalink layer containing a lot of hosts. As PVC based network needs a lot of datalink level static configuration, it is difficult to manage and unrealistic for the network with more than hundreds of hosts. As exemplified with broadcast storm, wrong static setting at datalink level is often fatal. With ATM, if datalink configuration is wrong, cells may loop. It should be noted that on point-to-point links such as ATM, looping of cells is equally harmful as broadcasted looping on multiple access media for the consumed bandwidth of the link. That is, though looping on a single physical link does not affect other physical links, single datalink layer looping affect several physical link. To make the matter worse, as ATM has no link level hop count, looping will continue forever. So, PVC ATM is not considered in this memo. Communication over ATM in a Datalink Layer Unless a datalink layer is made of a single physical layer, it is beneficial for bridges to maintain some amount of connection information. With Ethernet, without learning bridges, all the packets are copied to all the physical layers. With learning bridges, as a packet is relayed by bridges, bridges learn from which interfaces the packet is received, which is equivalent to the path setup to the source of the packet. If two hosts exchange packets, a soft connection between the hosts are established as the state of learning bridges. With ATM, things can be no different, though additional support for more rigid connection may present. Such a rigid connection is necessary and useful to assure QoS. If QoS is not necessary, datalink communication may be just like that of Ethernet. To do so, an AAL containing the MAC addresses of the sender and the receiver in the first cell is necessary. ATM bridges then peek into the first M. Ohta Expires on Sept. 5, 1994 [Page 3] INTERNET DRAFT Conventional IP over ATM March 1994 cell and learn that the sender is located toward the incoming interface of the cell. Then, if the receiver's location is not learned, cells are broadcasted. Unfortunately, the scheme can not be supported efficiently by the current hardware. Alternative way is to use broadcasted ARP [EARP] followed by signaling to establish SVC between a pair of hosts. As for broadcast, at a physical layer, there is no such thing as NBMA (Non-Broadcast Multi-Access). Regardless of whether the layer is point-to-point or multiple-access, everything a sender sends is received by all the hosts connected to the layer. So, it is not surprising that a datalink layer attempt to throw way the physical layer property results in serious loss of information necessitating some static configuration [ROLC]. Thus, the conventional wisdom of the conventional IP is to support broadcast at the link layer. It should be noted that, with conventional IP, the size of a well-managed datalink layer is not so large. So, excessive amount of copying of a broadcast packet does not occur. Ethernet bridges copies broadcast packets to all the interfaces (on the spanning tree). ATM bridges can also do so. Most of existing ATM switches have efficient hardware mechanism of such copying to support point-to-multipoint connections. Moreover, broadcast is the only way to communicate with neighbors without prior knowledge of neighbor's addresses. For example, one of the goals of DHCP (Dynamic Host Configuration Protocol) to make hand configuration completely unnecessary, can not be achieved without broadcast. So, there seems to be no reason not to have broadcast with ATM. This memo does not further address the detail on broadcast with ATM. Assuming NBMA ARP within a datalink layer does not affect the rest of the memo. Conventional Communication over ATM in a Network Layer The conventional communication, that is communication that does not assume connectivity, is no different from that of the existing IP, of course. Communication within a datalink layer is performed as described in the previous section. Communication beyond datalink layers is performed by first communicating to a router. Routers exchange routing information and forward packets decrementing TTL by one or more toward the next hop routers. No further explanation is necessary nor given. M. Ohta Expires on Sept. 5, 1994 [Page 4] INTERNET DRAFT Conventional IP over ATM March 1994 Though it is possible to reduce hop count by having ATM connections between non-adjacent routers, it is beyond the scope of the conventional model and not discussed in this memo. Connection Oriented QoS Assured Communication over ATM The goal of connection oriented communication is to provide end-end IP connection. Such a connection is necessary to have QoS-assured communication. Unlike other models of IP over ATM, the model in this memo assumes QoS-assured communication over not only ATM but also other types of media. The model, in general, is not so different from that of the previous section, though seamless optimization is possible for communication between ATM datalinks. It is assumed that QoS assurance protocol within a datalink layer is present and is preformed by hosts (including routers) attached to the layer. How it will be is not addressed in this memo. Communication within a datalink layer can directly use the protocol and needs no special care. Communication beyond datalink layers is performed by first establishing QoS assured connection to a neighbor router. Routers then establishes the QoS connection using the datalink level reservation protocol to the next hop router until the destination is reached. Some processing power of routers should also be reserved. After the connection is established, packets are forwarded through the QoS assured datalink connection. As there can be multiple QoS assured connection between the source and the destination, some identifier other than source/destination addresses is necessary to uniquely identify a connection. A single identifier, called flow ID, could be used along the connection. The pair of the source address and the flow ID uniquely identifies the connection. In general, QoS assured communication can be routed to an appropriate next hop datalink connection by flow ID. That is: 1) a packet arrives at a router M. Ohta Expires on Sept. 5, 1994 [Page 5] INTERNET DRAFT Conventional IP over ATM March 1994 2) packet's flow ID and source address are checked and the next hop is determined 3) packet's TTL is decremented by 1 (or more) 4) unless the router is the destination, the packet is forwarded the above scheme assumes nothing ATM specific and applicable to all the QoS assured media such as a fixed speed dedicated link, FDDI II or switched Ethernet. With ATM, packets are reassembled at step 1) and re-celled at step 4), which means certain amount of delay and certain amount of processing overhead and is not so desirable. Optimization is possible by making use of the fact that flow ID is not necessary at step 2). That is, if some information to identify flow locally at each interface is provideed, it is enough to determine the next datalink connection. With ATM, VCI/VPI is such locally unique identifier. Moreover, ATM equipments have efficient hardware mechanism to forward cells based on VCI/VPI of incoming cells. So, if both the incoming and outgoing interface are ATM, the following cell-by-cell scheme works: 1) a cell arrives at a router 2) cell's VCI/VPI/incoming_interface is checked and the next hop VCI/VPI/outgoing_interface is determined by hardware 3) unless the router is the destination, the cell is forwarded It is assumed that information used at the step 2) is provided during the connection establishment. Thus, if ATM hosts communicate purely over ATM routers, a seamless single ATM link is established between them. It should be noted that, though many think ATM connection is considered to be at the datalink layer, the above seamless connection on ATM routers is at the network layer. So, all the network layer property such as the selection of the best path is naturally available. Seamlessness, here, should considered to be something like lower level caching. Whether some ATM equipment forward information cell by cell or packet by packet is merely an internal implementation detail, which does not affect the classification on whether the equipment is considered to be a bridge or a router. M. Ohta Expires on Sept. 5, 1994 [Page 6] INTERNET DRAFT Conventional IP over ATM March 1994 The problem of the scheme above is that TTL of the packet is not decremented at all. If ATM routers recognize AAL and can decrement TTL by hardware, it's OK. But, currently, they can't. As the number of routers along the seamless path is known in advance, packets with insufficient TTL may be dropped at the starting point of the seamless link. The TTL issue never be an issue in practice, unless the path itself is setup to form a loop, in which case no models of IP over ATM with seamless connection can function, anyway. Resource reservation protocols should be designed to make the formation of the loop completely unlikely. The lack of datalink level TTL makes the looping serious issue. It might be necessary in the future to design a new AAL that supports cell-wise or packet-wise TTL supported by hardware. References [CLIP] M. Laubach, "Classical IP and ARP over ATM", RFC1577, January 1994. [EARP] D. Plummer, "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD37, RFC826, November 1982. [IPATM] An Internet Draft may be available (J. Heinanen, R. Govindan, "IP over ATM: A Framework Document", ). [ROLC] An Internet Draft may be available (J. Heinanen, R. Govindan, "NBMA Next Hop Resolution Protocol (NHRP)", ). [RSVP] An Internet Draft may be available (L. Zhang, R. Braden, D. Estrin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", ). [STII] C. Topolcic, "Experimental Internet Stream Protocol, Version 2 (ST-II)", RFC1190, October 1990. Acknowledgements This memo is a result of discussion in TNG (The Next Generation) working group of JAIN consortium. Many ATM experts in Japan including Hiroshi Esaki of Toshiba, Masayuki Murata of Osaka University, Kenji Fujisawa of SONY, Yuichiroh Nozue of Sumitomo M. Ohta Expires on Sept. 5, 1994 [Page 7] INTERNET DRAFT Conventional IP over ATM March 1994 Electric Industries and Akira Chugo of Fujitsu have contributed to the discussion. Interested parties are encouraged to read the original discussion (available as ftp.jain.ad.jp:pub/archive/tng-wg in Japanese with ISO-2022-JP encoding). Among all the contributers, the only reason that Hiroshi Esaki is not the co-author of this memo is to avoid complex formalities to get publication permission from his company. Security Considerations Security issues are not discussed in this memo. Authors' Address Masataka Ohta Tokyo Institute of Technology 2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN Phone: +81-3-5499-7084 Fax: +81-3-3729-1940 EMail: mohta@cc.titech.ac.jp Comments may also be directed to: TNG Working Group JAIN Consortium EMail: tng-wg@jain.ad.jp M. Ohta Expires on Sept. 5, 1994 [Page 8] From owner-Big-Internet@munnari.OZ.AU Fri Mar 25 16:13:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19990; Fri, 25 Mar 1994 16:13:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA20313; Fri, 25 Mar 1994 16:12:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA20299; Fri, 25 Mar 1994 16:01:44 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18312; Fri, 25 Mar 1994 15:21:56 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA00812 for big-internet@munnari.oz.au; Fri, 25 Mar 94 00:13:36 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id VAA02971; Thu, 24 Mar 1994 21:12:16 -0800 Message-Id: <199403250512.VAA02971@aland.bbn.com> To: Simon E Spero Cc: int-serv@isi.edu, big-internet@munnari.OZ.AU Subject: Re: reading for INT SERV meetings In-Reply-To: Your message of Thu, 24 Mar 94 20:34:37 -0500. <9403250134.AA00385@tipper.oit.unc.edu> From: Craig Partridge Date: Thu, 24 Mar 94 21:12:12 -0800 Sender: craig@aland.bbn.com Convince the general public that IP is suitable for Integrated Services?> I think you have to convince half the IETF too! Mind you, judging from our experiences here with the North Carolina Information Porkway, ATM gives you disintegrated services too. Simon: Yes we have to convince some folks in IETF. However I think it is less than half the IETF. Anyone who believes that ATM can support integrated services must axiomatically believe IP can support integrated services, since (but for some low-order terms) the theoretical work saying ATM works for integrated services applies to IP too. This means that the only folks we have to convince are those folks who believe ATM is a bad idea, and based on the frequency which which ATM is mentioned favorably on IETF lists, I suspect the folks who think ATM is a bad thing constitute less than half the IETF.... :-) Craig From owner-Big-Internet@munnari.OZ.AU Fri Mar 25 19:35:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27387; Fri, 25 Mar 1994 19:35:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA20489; Fri, 25 Mar 1994 19:32:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA20475; Fri, 25 Mar 1994 19:15:18 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26857; Fri, 25 Mar 1994 19:16:23 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA02071; Fri, 25 Mar 1994 10:20:03 +0100 Message-Id: <199403250920.AA02071@mitsou.inria.fr> To: Craig Partridge Cc: Simon E Spero , int-serv@isi.edu, big-internet@munnari.OZ.AU Subject: Re: reading for INT SERV meetings In-Reply-To: Your message of "Thu, 24 Mar 1994 21:12:12 PST." <199403250512.VAA02971@aland.bbn.com> Date: Fri, 25 Mar 1994 10:20:03 +0100 From: Christian Huitema => Yes we have to convince some folks in IETF. However I think it is => less than half the IETF. Anyone who believes that ATM can support integrated => services must axiomatically believe IP can support integrated services, since => (but for some low-order terms) the theoretical work saying ATM works for => integrated services applies to IP too. This means that the only folks we => have to convince are those folks who believe ATM is a bad idea, and based => on the frequency which which ATM is mentioned favorably on IETF lists, I => suspect the folks who think ATM is a bad thing constitute less than half => the IETF.... :-) .. not to mention a number of folks who believe that ATM is a bad idea because it is based on a circuit-switching paradigm, which is not needed for integrated services. In fact, I believe that a lot of what ATM is claimed to provide, e.g. phone circuits or video circuits, can easily be achieved with conventional datagram IP. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 01:54:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09715; Sat, 26 Mar 1994 01:54:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA20917; Sat, 26 Mar 1994 01:52:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA20851; Sat, 26 Mar 1994 01:35:45 +1000 Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08989; Sat, 26 Mar 1994 01:36:46 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14436(2)>; Fri, 25 Mar 1994 07:36:14 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 25 Mar 1994 07:36:25 -0800 To: Andy Malis Cc: int-serv@isi.edu, big-internet@munnari.OZ.AU Cc: deering@parc.xerox.com Subject: Re: reading for INT SERV meetings In-Reply-To: malis's message of Fri, 25 Mar 94 06:28:38 -0800. <9403251428.AA28394@maelstrom.timeplex.com> Date: Fri, 25 Mar 1994 07:36:12 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Mar25.073625pst.12171@skylark.parc.xerox.com> > > In fact, I believe that a lot of what ATM is claimed to provide, > > e.g. phone circuits or video circuits, can easily be achieved with > > conventional datagram IP. > > Well, what makes this "interesting" to discuss, and less than obvious > to implement, are the mechanisms used to provide the appications' > required quality of service under other than very lightly loaded > conditions (and without adding an inordinate amount of overhead, > resource overreservation, or other wastage). A possible answer is: (1) receiver buffering to make applications jitter-tolerant, (2) layered, VBR media encodings to provide elasticity of demand, (3) statistical fair queueing to share bandwidth equally among all active, competing sources, (4) priority dropping within a single source's packets, so that when they don't all fit in the source's current share of a link, its less important layers get dropped before its more important layers, (5) low rate feedback from receivers on reception success for specific layers, so that packets in insufficiently well received layers can be suppressed before reaching the congestion point (in the case of multicast, this feedback takes the form of joining/leaving different multicast groups for different layers), and (6) no less link bandwidth than the alternative ATM infrastructure. More would be nice -- whether or not any such "wastage" is a good engineering choice will depend on the price of bandwidth, which is related more to policy/regulatory/monopoly issues than anything else. Steve From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 03:09:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07048; Sat, 26 Mar 1994 00:34:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA20748; Sat, 26 Mar 1994 00:32:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA20745; Sat, 26 Mar 1994 00:28:17 +1000 Received: from corp.timeplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06872; Sat, 26 Mar 1994 00:29:13 +1000 (from malis@maelstrom.timeplex.com) Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.2-11 #2740) id <01HADUHOGR808WX9SA@sys30.timeplex.com>; Fri, 25 Mar 1994 09:30:08 EDT Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA28394; Fri, 25 Mar 94 09:28:43 EST Date: Fri, 25 Mar 1994 09:28:38 -0500 From: Andy Malis Subject: Re: reading for INT SERV meetings In-Reply-To: Your message of "Fri, 25 Mar 1994 10:20:03 +0100." <199403250920.AA02071@mitsou.inria.fr> To: Christian Huitema Cc: Craig Partridge , Simon E Spero , int-serv@isi.edu, big-internet@munnari.OZ.AU, malis@maelstrom.timeplex.com Message-Id: <9403251428.AA28394@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Christian, > In fact, I believe that a lot of what ATM is claimed to provide, > e.g. phone circuits or video circuits, can easily be achieved with > conventional datagram IP. Well, what makes this "interesting" to discuss, and less than obvious to implement, are the mechanisms used to provide the appications' required quality of service under other than very lightly loaded conditions (and without adding an inordinate amount of overhead, resource overreservation, or other wastage). But then I'm not telling THIS crowd anything! I'm looking forward to the BOF. Cheers, Andy __________________________________________________________________________ Andrew G. Malis malis@maelstrom.timeplex.com +1 508 266-4522 Ascom Timeplex 289 Great Rd., Acton MA 01720 USA FAX: +1 508 264-4999 From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 03:13:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07762; Sat, 26 Mar 1994 00:54:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA20778; Sat, 26 Mar 1994 00:52:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA20775; Sat, 26 Mar 1994 00:43:37 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07409; Sat, 26 Mar 1994 00:44:42 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA02913; Fri, 25 Mar 1994 15:48:19 +0100 Message-Id: <199403251448.AA02913@mitsou.inria.fr> To: Andy Malis Cc: Craig Partridge , Simon E Spero , int-serv@isi.edu, big-internet@munnari.OZ.AU Subject: Re: reading for INT SERV meetings In-Reply-To: Your message of "Fri, 25 Mar 1994 09:28:38 EST." <9403251428.AA28394@maelstrom.timeplex.com> Date: Fri, 25 Mar 1994 15:48:17 +0100 From: Christian Huitema => Christian, => => > In fact, I believe that a lot of what ATM is claimed to provide, => > e.g. phone circuits or video circuits, can easily be achieved with => > conventional datagram IP. => => Well, what makes this "interesting" to discuss, and less than obvious => to implement, are the mechanisms used to provide the appications' => required quality of service under other than very lightly loaded => conditions (and without adding an inordinate amount of overhead, => resource overreservation, or other wastage). But then I'm not telling => THIS crowd anything! => Hey, I am not that ignorant. I know pretty well that a datagram network does not guaranty a quality of service! What I mean is that for classic audio or video application, in a point to point or small group environment, it is possible to design applications that adapt dynamically to the network's quality of service. Much in the same way that the average TCP adapts its windows to the variable networking conditions. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 03:14:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12435; Sat, 26 Mar 1994 03:14:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA21037; Sat, 26 Mar 1994 03:12:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA21020; Sat, 26 Mar 1994 03:05:47 +1000 Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12150; Sat, 26 Mar 1994 03:05:47 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA22995 for big-internet@munnari.oz.au; Fri, 25 Mar 94 11:55:26 -0500 Received: from localhost by aland.bbn.com (8.6.4/3.1.090690-BBN) id IAA03355; Fri, 25 Mar 1994 08:54:09 -0800 Message-Id: <199403251654.IAA03355@aland.bbn.com> To: postel@ISI.EDU (Jon Postel) Cc: int-serv@ISI.EDU, big-internet@munnari.OZ.AU Subject: Re: Question: When wil TelCo Voice actually go over ATM ? In-Reply-To: Your message of Fri, 25 Mar 94 08:18:23 -0800. <199403251618.AA17726@zephyr.isi.edu> From: Craig Partridge Date: Fri, 25 Mar 94 08:54:06 -0800 Sender: craig@aland.bbn.com We've all heard how ATM is great for voice and video circuits. Does anybody know when the TelCo's will start sending normal voice calls over ATM? Jon: There was actually a piece in Communications Week (last week?) arguing the answer to this was no time soon. As I recall, the conclusion was that ATM was looking more expensive than current techniques for carrying voice. However, my recollection is that the conclusion wasn't well justified (i.e., it didn't do something like show that ATM's 10% overhead was higher than that currently used on links), so I'm not sure how much credence to give the article. Craig From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 03:15:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08310; Sat, 26 Mar 1994 01:13:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA20821; Sat, 26 Mar 1994 01:12:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA20786; Sat, 26 Mar 1994 00:53:22 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05166; Fri, 25 Mar 1994 23:56:22 +1000 (from kasten@mailserv-D.ftp.com) Received: from mailserv-D.ftp.com by ftp.com ; Fri, 25 Mar 1994 08:54:55 -0500 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA21888; Fri, 25 Mar 94 08:54:10 EST Date: Fri, 25 Mar 94 08:54:10 EST Message-Id: <9403251354.AA21888@mailserv-D.ftp.com> To: ses@tipper.oit.unc.edu Subject: Re: reading for INT SERV meetings From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: craig@aland.bbn.com, int-serv@isi.edu, big-internet@munnari.OZ.AU Content-Length: 451 > Convince the general public that IP is suitable for Integrated Services?> > I think you have to convince half the IETF too! I would imagine that development and fielding of the necessary protocols, even on an experimental basis, would present an existance proof that IP is suitable, and therefore, be a credible and powerful argument for the pro. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 03:32:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10391; Sat, 26 Mar 1994 02:14:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA20960; Sat, 26 Mar 1994 02:12:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA20946; Sat, 26 Mar 1994 01:56:55 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09848; Sat, 26 Mar 1994 01:58:05 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA16878; Fri, 25 Mar 1994 07:51:23 -0800 Date: Fri, 25 Mar 1994 07:51:23 -0800 Message-Id: <199403251551.HAA16878@Mordor.Stanford.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Christian Huitema , Andy Malis From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: reading for INT SERV meetings Cc: Craig Partridge , Simon E Spero , int-serv@ISI.EDU, big-internet@munnari.OZ.AU At 3:48 PM 3/25/94 +0100, Christian Huitema wrote: > What I mean is that for classic audio or >video application, in a point to point or small group environment, it is >possible to design applications that adapt dynamically to the network's >quality of service. Much in the same way that the average TCP adapts its >windows to the variable networking conditions. ATM appears extremely well-suited for constant bit-rate work, along the lines of classic telephony. What seems to be missing from much of the ATM discussion and work is a systems-level ability to deal with highly variable (i.e., stochastic) behavior. Hence, the right way to use ATM, now, is as pure TDMA, with the very convenient ability to change the size of the FIXED slices quickly and easily. (An example of the difficulties for ATM is that any tendency to deal with congestion by throwing cells away is going to kill performance if the client protocol is fragmented to fit into cells.) The data world, on the other hand, just LOVES stochastic behavior. What waits to be seen is whether we can add serious delivery timing guarantees. (We also have to learn not to throw those packets away.) Dave P.S. A small item that frequently is missed when talking about real-time video or audio is that compression algorithms being used often produce a VARIABLE bandwith stream. I.e., the stuff ceases to be constant bit-rate. I.e., the systems demand becomes variable. Dave From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 03:39:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12539; Sat, 26 Mar 1994 03:16:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA21052; Sat, 26 Mar 1994 03:15:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA21023; Sat, 26 Mar 1994 03:09:05 +1000 Received: from corp.timeplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07889; Sat, 26 Mar 1994 00:56:30 +1000 (from malis@maelstrom.timeplex.com) Received: from maelstrom.timeplex.com by sys30.timeplex.com (PMDF V4.2-11 #2740) id <01HADVFD1I288WX31Z@sys30.timeplex.com>; Fri, 25 Mar 1994 09:57:14 EDT Received: from maelstrom by maelstrom.timeplex.com (4.1/SMI-4.1) id AA29392; Fri, 25 Mar 94 09:55:49 EST Date: Fri, 25 Mar 1994 09:55:48 -0500 From: Andy Malis Subject: Re: reading for INT SERV meetings In-Reply-To: Your message of "Fri, 25 Mar 1994 15:48:17 +0100." <199403251448.AA02913@mitsou.inria.fr> To: Christian Huitema Cc: Andy Malis , Craig Partridge , Simon E Spero , int-serv@ISI.EDU, big-internet@munnari.OZ.AU Message-Id: <9403251455.AA29392@maelstrom.timeplex.com> Content-Transfer-Encoding: 7BIT Christian, > Hey, I am not that ignorant. I know pretty well that a datagram network does > not guaranty a quality of service! Peace ... sorry about that - I certainly didn't intend to imply anything of the sort! > What I mean is that for classic audio or > video application, in a point to point or small group environment, it is > possible to design applications that adapt dynamically to the network's > quality of service. Much in the same way that the average TCP adapts its > windows to the variable networking conditions. Absolutely - however, is the BOF (and WG that follows) going to confine itself to the Internet layer and service model to meet the requirements of existing applications, or is it also going to work on application design as well? Specifying application service requirements is already on the charter, but do we need to go beyond that? It's an important question of scope that we'll have to discuss in the meeting. Cheers, Andy From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 05:03:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13136; Sat, 26 Mar 1994 03:34:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA21097; Sat, 26 Mar 1994 03:32:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA21083; Sat, 26 Mar 1994 03:22:56 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10562; Sat, 26 Mar 1994 02:23:16 +1000 (from postel@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Fri, 25 Mar 1994 08:18:23 -0800 Date: Fri, 25 Mar 1994 08:18:23 -0800 From: postel@ISI.EDU (Jon Postel) Message-Id: <199403251618.AA17726@zephyr.isi.edu> To: int-serv@ISI.EDU, big-internet@munnari.OZ.AU Subject: Question: When wil TelCo Voice actually go over ATM ? Cc: postel@ISI.EDU Hi. We've all heard how ATM is great for voice and video circuits. Does anybody know when the TelCo's will start sending normal voice calls over ATM? --jon. From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 06:19:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12566; Sat, 26 Mar 1994 03:17:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA21067; Sat, 26 Mar 1994 03:16:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA21017; Sat, 26 Mar 1994 03:05:12 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12159; Sat, 26 Mar 1994 03:06:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01193; Fri, 25 Mar 94 12:06:17 -0500 Date: Fri, 25 Mar 94 12:06:17 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403251706.AA01193@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, int-serv@ISI.EDU Subject: ATM, state in the network, etc... Cc: jnc@ginger.lcs.mit.edu From: Christian Huitema > the only folks we have to convince are those folks who believe ATM is a > bad idea, and based on the frequency which which ATM is mentioned > favorably on IETF lists, I suspect the folks who think ATM is a bad > thing constitute less than half the IETF.... :-) not to mention a number of folks who believe that ATM is a bad idea Be careful here. There are a number of people who want to introduce more awareness of traffic streams into the network (by increasing the amount of non-critical state inside the network) such as Dave Clark, me, etc, but still think the particular instantiation of ATM is a Broken Idea (for various complex reasons I'll pass over now). because it is based on a circuit-switching paradigm, which is not needed for integrated services. I'm not sure exactly what your definition of "circuit-switching" is (I don't consider even X.25 to be "circuit-switched"), but I think it's important to point out that there are pretty substantial fundamental differences (e.g. in where critical state is stored, and how resources are allocated) between the classical examples of circuit-switched networks, and new designs such as both ATM and flows. In fact, I believe that a lot of what ATM is claimed to provide, e.g. phone circuits or video circuits, can easily be achieved with conventional datagram IP. Sure, in a lightly loaded network, with no special user policy requirements, conventional datagrams can do a lot. However, our current widely deployed applications (telnet, mail, FTP, etc) respond reasonably well (thanks to Van) to sudden drops in the available resource level caused by traffic fluctuations: so your file transfer slows down, big deal. Real-time applications may not respond as well. I'm sure I don't need to remind you of the long history of packet voice and video work on the Internet, ranging back to packet voice work done on the ARPANet. We're not working purely from theory here. What seems to have been the universal experience is that a lot of variance in delay or bandwidth makes these applications basically not work, and that while unloaded datagram networks don't display those variances, loaded ones do. Then there are all the other reasons to put more non-critical state in the network, as packet processing becomes more complex as we add on security, policy, authentication, etc, etc. We're *already* seeing soft state in routers, it's just state that they infer by watching the packet stream. My thinking is, why force the router to jump through hoops trying to reconstruct the soft state it needs from poring over packets; why not just do it explicitly? In the long run it'll be simpler; my system design experience has been that doing anything by a round-about way eventually comes back to bite you. for classic audio or video application, in a point to point or small group environment, it is possible to design applications that adapt dynamically to the network's quality of service. Sure, within a range. However, there's usually a rate floor below which you just can't go. That's not true of, say, FTP. Noel From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 06:39:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16249; Sat, 26 Mar 1994 05:14:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA21225; Sat, 26 Mar 1994 05:12:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA21211; Sat, 26 Mar 1994 05:05:54 +1000 Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14163; Sat, 26 Mar 1994 04:01:50 +1000 (from curtis@ans.net) Received: by interlock.ans.net id AA07154 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Fri, 25 Mar 1994 13:01:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 25 Mar 1994 13:01:12 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 25 Mar 1994 13:01:12 -0500 From: Curtis Villamizar Message-Id: <199403251758.AA34118@foo.ans.net> To: Simon E Spero Cc: Craig Partridge , int-serv@ISI.EDU, big-internet@munnari.OZ.AU, curtis@ans.net Subject: Re: reading for INT SERV meetings In-Reply-To: (Your message of Thu, 24 Mar 94 20:34:37 EST.) <9403250134.AA00385@tipper.oit.unc.edu> Date: Fri, 25 Mar 94 12:58:16 -0500 > Convince the general public that IP is suitable for Integrated > Services?> I think you have to convince half the IETF too! Mind you, > judging from our experiences here with the North Carolina Information > Porkway, ATM gives you disintegrated services too. > Simon // NCIH - gigabits for biga-grits. Simon, If you can convince the people who are will be responsible for the vBNS level 3 service, that's a big win. If you can convince them now, they will try to convince router vendors to move quickly in this area. Of course, if they are already convinced, then you just have to produce standards that they can ask router vendors to implement. In fact, they may have already spoken to router vendors about requirements like best-effort real time, RSVP using IPv4, and link sharing and would like something that can be implemented with the blessing of an IETF standardization effort and the benefits of smart people like the chair and co-chairs of this group. [HINT!!!] No one has quite won the vBNS bid yet, but there is certainly a short list of parties that might have to be convinced. Nothing quite like a major existance proof to win people over. Curtis From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 09:27:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18930; Sat, 26 Mar 1994 06:34:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA21304; Sat, 26 Mar 1994 06:32:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA21290; Sat, 26 Mar 1994 06:17:47 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13034; Sat, 26 Mar 1994 03:30:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01409; Fri, 25 Mar 94 12:29:32 -0500 Date: Fri, 25 Mar 94 12:29:32 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403251729.AA01409@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, int-serv@isi.edu Subject: Can pure datagrams really service real-time applications? Cc: jnc@ginger.lcs.mit.edu > Well, what makes this "interesting" to discuss, and less than obvious > to implement, are the mechanisms used to provide the appications' > required quality of service under other than very lightly loaded > conditions (and without adding an inordinate amount of overhead, > resource overreservation, or other wastage). A possible answer is: Steve, I have two reactions to your long list of mechanisms. First, it doesn't really handle the congestion problem. There is a resource floor that most of these applications need, and beyond that you just have to shut things down, if you have the bandwidth to run N of the things, and N+1 show up. (Otherwise, back in the old days of undersea wires, they'd have just let more and more calls on, degrading the quality of all...) Your suggestions 1-5 just move the point at which N is reached, without getting rid of N. I'm not sure exactly what will happen when a new application tries to start up in a loaded channel; in the worst case, after fair-sharing is imposed, they might *all* shut down. Second, you've got a fair amount of mechanism there, and it only addresss the resource issue. I wonder if this isn't an example of the kind of thing I alluded to, where in an attempt to avoid soft-state setup, we wind up with some pretty complicated stuff, perhaps more complex than a simple biting of the bullet. Such bullet-biting would also give us more efficient support for policy, security, authentication, etc, which I'm not sure you list really helps with. (6) no less link bandwidth than the alternative ATM infrastructure. More would be nice -- whether or not any such "wastage" is a good engineering choice will depend on the price of bandwidth, which is related more to policy/regulatory/monopoly issues than anything else. This is an interesting point. Historically, it's often been the case that it's been less expensive to provide more resources, enough more to allow use of a really simple-minded allocation scheme, than do something complex which didn't work well anyway. The example I always use is optimal paging algorithms; they never worked really well, and we finally just went out and made memory cheap. It is a fair point that maybe this is the way to go; just provide enough bandwidth that simple mechanisms work well statistically, and you don't need stuff to handle a congested system. The thing that worries me about this path is that I'm not at all sure we can predict the future well enough to be able to trust this solution. At the same time, I'l cheerfully admit that my knowledge of resource allocation issues is pretty sketchy, and maybe there are fundamental reasons why, even in a system which is resource-rich, we still need mechanisms to guarantee service. Can a resource-allocation wizard tell us more? Noel From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 15:14:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04215; Sat, 26 Mar 1994 14:15:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id OAA21689; Sat, 26 Mar 1994 14:12:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id OAA21675; Sat, 26 Mar 1994 14:05:17 +1000 Received: from relay.fore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03755; Sat, 26 Mar 1994 13:59:12 +1000 (from ddp@fore.com) Received: from dolphin.fore.com by relay.fore.com (4.1/1.34) id AA05135; Fri, 25 Mar 94 22:56:52 EST Received: from humpback by dolphin.fore.com (4.1/SMI-4.1) id AA19857; Fri, 25 Mar 94 22:56:48 EST Received: by humpback (4.1/SMI-4.1) id AA00280; Fri, 25 Mar 94 22:56:47 EST Date: Fri, 25 Mar 94 22:56:47 EST From: ddp@fore.com (Drew Perkins) Message-Id: <9403260356.AA00280@humpback> To: Christian.Huitema@sophia.inria.fr, malis@maelstrom.timeplex.com, dcrocker@mordor.stanford.edu Subject: Re: reading for INT SERV meetings Cc: craig@aland.bbn.com, ses@tipper.oit.unc.edu, int-serv@isi.edu, big-internet@munnari.OZ.AU > At 3:48 PM 3/25/94 +0100, Christian Huitema wrote: > > What I mean is that for classic audio or > >video application, in a point to point or small group environment, it is > >possible to design applications that adapt dynamically to the network's > >quality of service. Much in the same way that the average TCP adapts its > >windows to the variable networking conditions. > > ATM appears extremely well-suited for constant bit-rate work, along the > lines of classic telephony. What seems to be missing from much of the ATM > discussion and work is a systems-level ability to deal with highly variable > (i.e., stochastic) behavior. Hence, the right way to use ATM, now, is as > pure TDMA, with the very convenient ability to change the size of the FIXED > slices quickly and easily. (An example of the difficulties for ATM is that > any tendency to deal with congestion by throwing cells away is going to > kill performance if the client protocol is fragmented to fit into cells.) > > The data world, on the other hand, just LOVES stochastic behavior. What > waits to be seen is whether we can add serious delivery timing guarantees. > (We also have to learn not to throw those packets away.) Dave, You may have not been following the work going on in the ATM Forum for more than the last year. ATM is being enhanced with an Available Bit-Rate (ABR) capability to be used for data. There are currently two schemes being thoroughly investigated and discussed; one is rate-based and the other is credit-based. Once these are in place, ATM will simultaneously provide very good support for Constant Bit-Rate (CBR) and Variable Bit-Rate (VBR) traffic like voice and video, but will also include very good support for data traffic as well. Drew ----------------------------------------------------------------- FORE Systems, Inc. Tel: (412) 772-6527 174 Thorn Hill Road Fax: (412) 772-6500 Warrendale, PA 15086-7535 Email: ddp@fore.com From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 21:06:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12010; Sat, 26 Mar 1994 18:35:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA21911; Sat, 26 Mar 1994 18:32:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA21897; Sat, 26 Mar 1994 18:23:31 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11684; Sat, 26 Mar 1994 18:24:14 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 26 Mar 94 17:15:32 +0900 From: Masataka Ohta Message-Id: <9403260815.AA00682@necom830.cc.titech.ac.jp> Subject: Re: Can pure datagrams really service real-time applications? To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sat, 26 Mar 94 17:15:30 JST Cc: big-internet@munnari.OZ.AU, int-serv@isi.edu, jnc@ginger.lcs.mit.edu In-Reply-To: <9403251729.AA01409@ginger.lcs.mit.edu>; from "Noel Chiappa" at Mar 25, 94 12:29 pm X-Mailer: ELM [version 2.3 PL11] > At the same time, I'l cheerfully admit that my knowledge of resource > allocation issues is pretty sketchy, and maybe there are fundamental reasons > why, even in a system which is resource-rich, we still need mechanisms to > guarantee service. Can a resource-allocation wizard tell us more? As no link is 100% reliable, QoS guarantee does not mean that the specified QoS is provided 100% of the time. So they are not so different qualitatively, while quantitative difference could be a lot. The possible difference is that if we pay for each QoS guarantee, we can be paid back if the guarantee fails. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Mar 26 21:14:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16767; Sat, 26 Mar 1994 21:14:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA22060; Sat, 26 Mar 1994 21:12:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA22046; Sat, 26 Mar 1994 21:03:46 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11528; Sat, 26 Mar 1994 18:18:31 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 26 Mar 94 17:04:03 +0900 From: Masataka Ohta Message-Id: <9403260804.AA00442@necom830.cc.titech.ac.jp> Subject: Re: reading for INT SERV meetings To: deering@parc.xerox.com (Steve Deering) Date: Sat, 26 Mar 94 17:04:01 JST Cc: malis@maelstrom.timeplex.com, int-serv@isi.edu, big-internet@munnari.OZ.AU, deering@parc.xerox.com In-Reply-To: <94Mar25.073625pst.12171@skylark.parc.xerox.com>; from "Steve Deering" at Mar 25, 94 7:36 am X-Mailer: ELM [version 2.3 PL11] > > > In fact, I believe that a lot of what ATM is claimed to provide, > > > e.g. phone circuits or video circuits, can easily be achieved with > > > conventional datagram IP. > > > > Well, what makes this "interesting" to discuss, and less than obvious > > to implement, are the mechanisms used to provide the appications' > > required quality of service under other than very lightly loaded > > conditions (and without adding an inordinate amount of overhead, > > resource overreservation, or other wastage). > A possible answer is: Use STII, RSVP or any other resource reservation protocol at internetwork layer. If QoS requirement is strict, we should also use datalinks which support connectionless communication AND QoS assured connection oriented communication. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun Mar 27 03:23:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26090; Sun, 27 Mar 1994 02:15:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA22321; Sun, 27 Mar 1994 02:13:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA22307; Sun, 27 Mar 1994 02:06:36 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23525; Sun, 27 Mar 1994 00:54:46 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9403261454.23525@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 26 Mar 1994 14:54:25 +0000 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, int-serv@isi.edu Subject: Re: Can pure datagrams really service real-time applications? In-Reply-To: Your message of "Fri, 25 Mar 94 12:29:32 EST." <9403251729.AA01409@ginger.lcs.mit.edu> Date: Sat, 26 Mar 94 14:54:21 +0000 From: Jon Crowcroft >1-5 just move the point at which N is reached, without getting rid of N. I'm >not sure exactly what will happen when a new application tries to start up in >a loaded channel; in the worst case, after fair-sharing is imposed, they might >*all* shut down. no - fair sharing is for established flows the solution is to know that the new flow is new. (not hard, but done implicitly ratehr than througfh call setup) same as call blocking in the phone net - note that most the phone net is now engineered to practically never call block - this is not through clever queueing - its through adequate bandwidth! oh, if someone thinks their packets are more important, they use the appropriate _different_ flow type, and get through anyhow (or we could just admit it, that this is priority, and get into charging...) >Second, you've got a fair amount of mechanism there, and it only addresss the >resource issue. I wonder if this isn't an example of the kind of thing I >alluded to, where in an attempt to avoid soft-state setup, we wind up with >some pretty complicated stuff, the code we have that does this is only a few hundred lines of C what do you get extra with a call setup? well, you get an O(n**2) headache with multicast, and you get the user to give you some fictitious number they _think_ is the QoS they want...i.e. not a lot cheers jon From owner-Big-Internet@munnari.OZ.AU Sun Mar 27 06:25:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01565; Sun, 27 Mar 1994 04:55:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA22468; Sun, 27 Mar 1994 04:53:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA22454; Sun, 27 Mar 1994 04:37:59 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00777; Sun, 27 Mar 1994 04:39:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11657; Sat, 26 Mar 94 13:39:01 -0500 Date: Sat, 26 Mar 94 13:39:01 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403261839.AA11657@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, int-serv@isi.edu Subject: Re: Can pure datagrams really service real-time applications? Cc: jnc@ginger.lcs.mit.edu > 1-5 just move the point at which N is reached, without getting rid of N. > I'm not sure exactly what will happen when a new application tries to > start up in a loaded channel; in the worst case, after fair-sharing is > imposed, they might *all* shut down. no - fair sharing is for established flows. the solution is to know that the new flow is new. (not hard, but done implicitly ratehr than througfh call setup) same as call blocking in the phone net - This sounds plausible, but I don't think I believe it. First, how can the router know when two communicating hosts start up a new instance of the application? For instance, without looking down into the header quite some ways, it might not be able to tell. I'm also confused as to exactly how they are going to "block" the new one; do they drop all packets that they think belong to it? Suppose a packet gets through in a momentary traffic lull, and then the application is going? Second, how can the routers differentiate between the cases where i) there are N flows going, but have more than their minimum required bandwidth, so it can add one and drop everyone a little, and ii) there are N flows going, but each is at the limit, and will shut down if cut back? Again, without knowing a fair amount about the application, it seems difficult to do that. Anyway, it seems to me that you have exactly the same amount of state, enforcement mechanism, etc, with this as with flow setup. It's just that the state is inferred from watching the packet stream (a more complex and less likely correct process than explicit setup), and you have to figure out which state block a packet belongs to, again, a perhaps slower and less likely correct operation than explicit assignment via a header field. note that most the phone net is now engineeretheyd to practically never call block - this is not through clever queueing - its through adequate bandwidth! Yup; that's what I was alluding to when I said that maybe adding resources are the way to go. On the other hand, note that the phone network does try hard to guarantee resources to connections which are already set up. However, they don't provide enough bandwidth to *never* run out. When the net *does* get congested (and it does happen sometimes), this probably makes it more robust in that operating regime. > Second, you've got a fair amount of mechanism there, and it only > addresss the resource issue. I wonder if this isn't an example of the > kind of thing I alluded to, where in an attempt to avoid soft-state > setup, we wind up with some pretty complicated stuff, the code we have that does this is only a few hundred lines of C Does it really provide all the items Steve mentioned (1-5)? How general are the resource semantics it supports? Even so, if it's being done on every packet, it could be considered substantial, especially since, as I noted, all it does it the resource stuff. what do you get extra with a call setup? Well, you can get one-time authorization overhead, a more robust and extensible routing architecture (with all the policy routing hooks anyone could ever want), etc, etc, eytc. What extra do you get with your stuff? (Also, I don't like the term "call setup" because in many minds it probably invokes a somewhat different image than the one I'm thinking of. I prefer "flow setup".) well, you get an O(n**2) headache with multicast, I keep hearing people toss around "O(N^2)" like it's some kind of last word in any debate about mechanisms, but in at least one case it was, on closer inspection, provably wrong. Exactly what is growing at O(N^2), and what's N? Do you mean that if you have multicast groups where each source has a separate distribution tree, that results in O(N^2) growth in state in each individual router through which that tree passes, where N is the number of of participants in the group? and you get the user to give you some fictitious number they _think_ is the QoS they want... Well, if the user can't quantify their application because they're a twit, that's not my department. Now, if you could show me that the kinds of applications we want to run are *inherently* non-quantifiable, then I'd be more worried. i.e. not a lot You seem to be looking at the pros and cons of flows entirely from the resource allocation standpoint. This is wrong. The nicest thing about flows is that they help a *whole bunch* of seemingly unrelated things (routing, security, etc) all work better. Noel From owner-Big-Internet@munnari.OZ.AU Tue Mar 29 03:15:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05831; Tue, 29 Mar 1994 03:15:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA24814; Tue, 29 Mar 1994 03:13:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA24800; Tue, 29 Mar 1994 02:56:52 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05206; Tue, 29 Mar 1994 02:57:59 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA10432; Mon, 28 Mar 94 11:57:21 EST Message-Id: <9403281657.AA10432@tipper.oit.unc.edu> To: Jon Crowcroft Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, int-serv@isi.edu Subject: Re: Can pure datagrams really service real-time applications? In-Reply-To: Your message of "Mon, 28 Mar 94 16:23:06 +0100." <9403281524.1397@munnari.oz.au> Date: Mon, 28 Mar 94 11:57:21 -0500 From: Simon E Spero >>>>> "Jon" == Jon Crowcroft writes: Jon> a video compression scheme is scene dependneent - should a Jon> user look at the shirt they are wearing before bookingthe Jon> network call. *ANY* sheme which penalises obnoxious shirts has got to be worthwhile From owner-Big-Internet@munnari.OZ.AU Tue Mar 29 03:19:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02042; Tue, 29 Mar 1994 01:37:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA24700; Tue, 29 Mar 1994 01:33:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA24646; Tue, 29 Mar 1994 01:23:36 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01397; Tue, 29 Mar 1994 01:24:33 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9403281524.1397@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Mar 1994 16:23:10 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, int-serv@isi.edu Subject: Re: Can pure datagrams really service real-time applications? In-Reply-To: Your message of "Sat, 26 Mar 94 13:39:01 EST." <9403261839.AA11657@ginger.lcs.mit.edu> Date: Mon, 28 Mar 94 16:23:06 +0100 From: Jon Crowcroft >Well, if the user can't quantify their application because they're a twit, >that's not my department. Now, if you could show me that the kinds of >applications we want to run are *inherently* non-quantifiable, then I'd be >more worried. an FTP could use infinite bandwidth - it has no time requirement excep the social urgerncy of the file being retrieved. however, the cost of this is dependend on _the other traffic_ so how can the user quantify this a video compression scheme is scene dependneent - should a user look at the shirt they are wearing before bookingthe network call. sorry, asking the user to state their QoS requirement in advance is a nono., even though, as frank kelly says, it does lead to very neat simplifications in the queueing systems, its a shangri la. cheers >You seem to be looking at the pros and cons of flows entirely from the >resource allocation standpoint. This is wrong. The nicest thing about flows is >that they help a *whole bunch* of seemingly unrelated things (routing, >security, etc) all work better. yes, i definitely agree flows re a good thing...specially when typing from seattle :-) jon From owner-Big-Internet@munnari.OZ.AU Tue Mar 29 06:44:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10688; Tue, 29 Mar 1994 05:38:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA24945; Tue, 29 Mar 1994 05:33:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA24942; Tue, 29 Mar 1994 05:27:27 +1000 Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08183; Tue, 29 Mar 1994 04:27:53 +1000 (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 6565; Mon, 28 Mar 94 13:05:07 EST Received: from vtvm1.cc.vt.edu (NJE origin VALDIS@VTVM1) by VTVM1.CC.VT.EDU (LMail V1.1d/1.7f) with BSMTP id 7555; Mon, 28 Mar 1994 13:03:36 -0500 Date: Mon, 28 Mar 94 12:54:19 EST From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Can pure datagrams really service real-time applications? To: Simon E Spero , Jon Crowcroft Cc: Noel Chiappa , big-internet@munnari.OZ.AU, int-serv@isi.edu In-Reply-To: <9403281657.AA10432@tipper.oit.unc.edu> Message-Id: <940328.125419.EST.VALDIS@vtvm1.cc.vt.edu> On Mon, 28 Mar 94 11:57:21 -0500 you said: >>>>>> "Jon" == Jon Crowcroft writes: > > Jon> a video compression scheme is scene dependneent - should a > Jon> user look at the shirt they are wearing before bookingthe > Jon> network call. > >*ANY* sheme which penalises obnoxious shirts has got to be worthwhile Today, I'm wearing a sedate Levi's Docker shirt, which is a dark blue and light blue plaid. Most definitely NOT obnoxious. However, the plaid is going to play hell with most attemts at compression. Unless the algorithm is smart enough to compress the fact that there are 16 vertical stripes of alternating widths and colors every 2 inches - even when the shirt is looking somewhat rumpled due to lack of ironing. On the other hand, the violently orange tshirt I was wearing Saturday while playing lumberjack in my backyard would compress very well: repeat 2 zillion times *BRIGHT ORANGE*. There is also the issue of artifacts created by the television scanning technology - as anybody who has seen a news anchorperson's shirt suddenly explode into a Moire pattern when he moves 3 millimeters left can testify. Suddenly, the shirt goes from being one color all over to a patchwork of different colors (at least as seen by the camera). Do current compression schemes know how to deal with these Moire's and filter them back out? There is of course another reason for the user to look at his shirt - as the AT&T commercial says: "Fred just closed the deal of his life wearing duckie pajamas..." ;) Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.OZ.AU Tue Mar 29 11:46:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19381; Tue, 29 Mar 1994 10:15:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id KAA25228; Tue, 29 Mar 1994 10:13:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id JAA25204; Tue, 29 Mar 1994 09:55:01 +1000 Received: from ksuvm.ksu.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15281; Tue, 29 Mar 1994 08:03:50 +1000 (from SLWARD@KSUVM.KSU.EDU) Message-Id: <9403282203.15281@munnari.oz.au> Received: from KSUVM.KSU.EDU by KSUVM.KSU.EDU (IBM VM SMTP V2R1) with BSMTP id 5294; Mon, 28 Mar 94 16:02:53 CST Received: from KSUVM.KSU.EDU (NJE origin SLWARD@KSUVM) by KSUVM.KSU.EDU (LMail V1.1d/1.7f) with RFC822 id 0215; Mon, 28 Mar 1994 16:02:53 -0600 Date: Mon, 28 Mar 94 16:02 CST From: Stan Ward To: I would appreciate it if someone would e-mail me info on how to unsubscribe fro m this list. Thanks. From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 00:24:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15236; Tue, 29 Mar 1994 23:37:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA25879; Tue, 29 Mar 1994 23:34:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA25865; Tue, 29 Mar 1994 23:23:35 +1000 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14822; Tue, 29 Mar 1994 23:24:32 +1000 (from kre) Date: Tue, 29 Mar 1994 23:24:32 +1000 From: Robert Elz Message-Id: <9403291324.14822@munnari.oz.au> To: Big-Internet@munnari.OZ.AU Subject: Minimal Changes & IPng For the benefit of those not at IETF, in the aeiou bof yesterday here there was some discussion of that proposal which appeared to involve minimal changes to get IPng to work - not few changes, just minimal. Not so (though I'm not sure that was what Brian actually ever claimed, but it has to be the substance of the claim to have any weight), what it may have done was propose a way to get bigger addresses with minimal changes. At first sight it appears that that is what IPng is all about, IPng -> bigger addresses, so minimal changes to bigger addresses is a prereq to minimal changes for IPng. Not true. It has been reported that Van Jacobsen has said this in the past, unfortunately I haven't heard Van say this, thus haven't heard one of Van's brilliant explanations that makes the whole thing obvious to any mere cretin like me, so while I kind of believed this before, I had never really thought it through. Van, there's certainly nothing in the B-I archives from you on this (one advangtage of an index by authors...) if you'd like to contribute a few paragraphs I'm sure we'd all appreciate it. Anyway, with a combination of the aeiou BOF (and the words "minimal changes", which seems like a good idea to me), and then the immediately following ALE wg meeting, in which Fank and Tony managed to make quite clear that the immediate problem is router routing table space (runs out maybe in 1996, depending on "magic"), not IP address space (runs out 2005, absolute worst estimate), I started pondering all this again. Going back a few years to when B-I started, if I remember correctly Noel was holding forth on "router table explosion" and along with that came "IP address (class B) exhaustion". At that point, everyone seemed to be able to see the effects of address space exhaustion, depending on just who you were it went either "Oh, if there are no more addresses, then I won't be able to conect any more customers to my net, and I'll lose bad", or "Oh, if there are no more addresses, then this net connectivity I've been pushing as the main feature of my product will no longer apply, and people will go back to buying mainframes", or "We need bigger addresses, what an ideal time to design a new packet format, and clean up all these warts in IPv4, what fun", or "Oh bliss, I have this protocol suite I've been pushing for years, and no-one has taken any notice all this time, it has much much bigger addresses, now is my chance to get my foot in their door". Anyway, for whatever reason, lots of bright people set off to design IP replacements, they have all concentrated on bigger addresses, and kind of (except in one case that seems no longer very relevant) basically ignored the routing problem - the assumption seems to be that we can always just make use of however IPv4 survives in the meantime, even if that means simply buying bigger and faster routers. Unfortunately Tony's presentation kind of wiped that out as a solution, the routing problem needs to be solved. Now that is precisely not what I'm going to do in this message. Instead, lets revisit the 64 bits or bigger address problem, and see just how urgent it is that we need to solve this one any time soon. First, its obvious (assuming we believe the numbers) that we have till 2005, which is good, as it would take at least that long to deploy any solution invented now anyway. But recall that's an (approx) worst case estimate, and basically tells us when class C addresses will run out. This completely ignores the huge pool of class C style addresses we have in the class A address space, my totally off the wall estimate suggests sometime around 2050 before we could exhaust that space assuming that we started allocating CIDR blocks of class C addresses from the current class A space (right now I'm not going to attempt to justify that). If you're willing to assume that's true, then it seems to me that we have a very long time to think about, plan, test, and deploy, solutions with bigger addresses, and there's no urgent need to do anything about this right now. Now lets see what the impact is of starting to assign class C type addresses from the class A address space. First lets look at the impact on hosts - well, hosts get a 32 bit address to use (no API change, no FTP changes, no ARP changes, no ICMP changes, ... sounds good so far). To a host, a class C segment of a class A number looks exactly like a subnet of a class A number, and I'm pretty sure that systems from all major (or even minor) vendors probably support this right now. Those few that still don't support subnetting I'm willing to let die out. Looks like hosts can be adapted to support use of the class A space with zero changes to me. Next routers - we have just been told that classless routing is here, running right now, there are no more class A B or C addresses in routers, or not in the routers that really matter, there are just addresses and masks. Looks like those routers can handle CIDR segments carved out of class A numbers already, no upgrades even needed. We still have the local routers, perhaps running RIP only, or something like that - those still see a class A as a class A, which is a different thing from a class C. What's the effect of that? None is my submission. Recall that the point of CIDR allocation is that all regional addresses will be from the same block, these routers route only regional traffic, they will see themselves as simply routing some subnets of a class A net, that the wires over which those subets run actually link organisations, rather than some departments of an organisation is pretty much irrelevant to your router. Hmm, looking good so far. Humans - well, not much effect there, IP addresses will still be IP addresses, net management will not be different, MIBs will all look just the same, traceroute, tcpdump, ... will all work just the same way, we may need a few changes in the BSD getnetbynumber() (or whatever its called), but the latest versions of the BIND resolver have that already, so that's not too bad, and its no disaster anyway if that's not perfect. Class A address holders - do we need to have them all renumber next week, so their class A addresses come back? That would be a slight disadvantage to those priveleged few. But no, we still have at least 50 totally unallocated class A addresses, without too much pain I'm sure we can make that into 64, that's already twice the total class C address space (which is already lasting till 2005 or beyond - the actual estimate was 2008) we have without reclaiming any actually used class A addresses. That means that we can, I think quite reasonably, say to the class A owners, "We need your number back. As of Jan 1 2005 your class A number will no longer be router over the XXXnet, (whatever its to be called then). You have 10 years, and a bit, to obtain new addresses and renumber to avoid using your old number any more". That sounds fair and reasonable to me. It also means that by 2005 when the class C's might run out, we should have the rest of the class A space (excluding probably nets 0, 1, 10, and 127, and I suppose some exception might be made for 26) back to leave lie fallow for a while while we're actually allocating the other half of the class A space. To me this means that bigger address research should continue, as there's no doubt that it will eventually be needed, but that it should move way outside the current focus of activity, and that we, as a community, should be concentrating almost exclusively upon solving the routing table explosion problem. I know its been suggested that the IPng solutions will achieve this by some magic ("the chance to start over" was one expression of this), frankly I'm not at all convinced, this all seems to be hand waving. For now lets forget packet header format bit twiddling, and solve the real problem (which I believe is as Noel predicted it years ago now). Note that even if this does require new protocols, different routig policies, differet almost anything, as its all routing, it can probably all be done with either no host changes at all, changes only in the routers, which have a much shorter lead time (maybe 2 or 3 years instead of 10 for hosts), or which can be done probably mostly exclusively by changes in application level host processes (gated, routed, whatever). Even if an occasional kernel change is required, its still not to the API and so has limited impact, and is much much easier to get done. Since I half hope that people at the IETF will read this message, and its already long enough, I will stop here, if based on any discussion, either on this list, or at the IETF, makes it appear that this is a sensible path to follow, then I will consider making this into an I-D, or an IPng white paper, or something, next week, or thereabouts. kre ps: No, Noel did not pay me to send this message... From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 00:55:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18643; Wed, 30 Mar 1994 00:55:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA25978; Wed, 30 Mar 1994 00:54:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA25975; Wed, 30 Mar 1994 00:49:15 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18477; Wed, 30 Mar 1994 00:50:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02729; Tue, 29 Mar 94 09:50:18 -0500 Date: Tue, 29 Mar 94 09:50:18 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403291450.AA02729@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: Minimal Changes & IPng Cc: jnc@ginger.lcs.mit.edu the immediately following ALE wg meeting, in which Fank and Tony managed to make quite clear that the immediate problem is router routing table space (runs out maybe in 1996, depending on "magic"), not IP address space I'm not positive I quite understood this. I assume that what Tony was saying was that without more rational allocation of addresses (i.e. not flat), the resulting routing table growth will exceed the capability of vendors to build routers which can hold bigger routing databases (not to mention the ability of humans to configure all the knobs correctly :-)? In other words, we're going to have to assign addresses in ways that allows considerable aggregation of routing table entries, right? Note that even if this does require new protocols, different routig policies, differet almost anything, as its all routing, it can probably all be done with either no host changes at all, changes only in the routers ... or which can be done probably mostly exclusively by changes in application level host processes (gated, routed, whatever). I don't actually believe it requires any protocol changes at all. The tools we need (routing protocols, both IGP's and EGP', which support CIDR) are already here. The "hard" part is assigning the addresses in ways which allow the aggregation which is *absolutely* the *only* way to build a big network. IPv4, Nimrod, SDRP, it doesn't matter; without rational and topologically based assignment of locators none of them will scale. The only piece of software/protocol we could usefully add is something to make reassignment of addresses/locators easier; stuff like DHCP. Past that, it's simply a matter of waiting for it to penetrate everyone's head that without rational address/locator assignment, *no* routing scheme will work. That's the real gating factor.... Noel From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 01:40:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17869; Wed, 30 Mar 1994 00:35:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id AAA25948; Wed, 30 Mar 1994 00:34:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id AAA25934; Wed, 30 Mar 1994 00:24:18 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17109; Wed, 30 Mar 1994 00:14:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02566; Tue, 29 Mar 94 09:13:40 -0500 Date: Tue, 29 Mar 94 09:13:40 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403291413.AA02566@ginger.lcs.mit.edu> To: int-serv@isi.edu, nimrod-wg@bbn.com Subject: A taxonomy of state and tags in datagram networks Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu As a result of discussions in the Int-Serv WG sessions yesterday, I'd like to suggest a framework for thinking about, and set of terms for describing, the state in datagram network systems. I think this framework will both help us understand more clearly what's going on, and the common terminology will allow us to have discussions without getting confused. I want to emphasize that I'm not pushing one design or another, just trying to give us a common framework which we can use to understand, discuss, and evaluate different designs in. I don't distinguish between "state" (which one normally thinks of as data which records something transitory about a given process), and information (which might be seen as a little more permanent), since it's merely a matter of time-scale; there's very transient state (such as the hop-count), intermediate lifetime (such as information about a flow), and long-lived (such as routing table entries). However, it's all just state in the end. I start by observing that even "classic" IPv4 has state in both the routers, and the packets. In the packet, I distinguish between what I call "forwarding state", which records something about the progress of this individual packet through the network (such as the hop count, or the pointer into a source route), and what I call "tags", which are fields which are used, in the routers through which the packet passes, to look up various state stored in the routers. An example of tags in the current IPv4 architecture is the "address", which is used to look up routing table state; a "flow-id" might be a future tag. I further subdivide tags into two sub-classes; "keys" and "hints". A key is a field without which, or without the state in the router to which it refers, one cannot forward the packet; the "address" is such a field in IPv4. A hint is a field which is not necessary for the forwarding of the packet, but which makes the forwarding more efficient if the hint is correct, and the state in the router to which it refers is present. In the routers, there is a similar distinction between state which must be present for the forwarding process to be sucessful, which we might call "necessary" state (although I don't like this term, and welcome a better one), such as routing table entries; and cached state which is not necessary for the correct forwarding of packets. The term "soft state" is, I believe, sometimes used to refer to the latter kind of state. Note that neither of these states is what we refer to as "critical" state, i.e. state which is critical to a given end-end communication, and which, once lost, means the loss of the connection. An example of this is the state of a TCP connection, as stored co-located (i.e. sharing fate) with the application. Having defined this way of looking at state, I'll put some thoughts on how we ought to create and maintain this state in a separate message. Noel From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 03:15:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23336; Wed, 30 Mar 1994 03:15:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA26117; Wed, 30 Mar 1994 03:14:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA26103; Wed, 30 Mar 1994 03:09:30 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23232; Wed, 30 Mar 1994 03:10:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03726; Tue, 29 Mar 94 12:10:36 -0500 Date: Tue, 29 Mar 94 12:10:36 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403291710.AA03726@ginger.lcs.mit.edu> To: int-serv@isi.edu, nimrod-wg@bbn.com Subject: Re: How to create and maintain state in a packet network Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu It seems to me that to have one internetwork layer subsystem (e.g. resource allocation) carry user state in all the packets, and use a hint in the packets to find it, and have a second (e.g. routing) use a direct installation, and use a key in the packets to find it, makes little sense. We should do one or the other... It has been pointed out to me that there are three ways in which to interpret this statement, and it makes sense to take note of the different way, because the utility of doing this makes different degrees of sense in the different ways. First, there is the meaning I had in mind, where one single flow uses different mechanisms for different subsystems. Second, one flow might use a given technique for all its subsystems, and another flow might use a different technique of its; there is potentially some use to this, although I'm not sure the cost in complexity of supporting both mechanisms is worth the benefits. Third, one flow might use on mechanism with one router along its path, and another for a different router. A number of different reasons exist as to why one might do this, including the fact that not all routers may support the same mechanisms simultaneously. Noel From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 03:55:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24750; Wed, 30 Mar 1994 03:55:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA26161; Wed, 30 Mar 1994 03:54:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA26158; Wed, 30 Mar 1994 03:53:01 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20640; Wed, 30 Mar 1994 01:55:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03070; Tue, 29 Mar 94 10:54:59 -0500 Date: Tue, 29 Mar 94 10:54:59 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403291554.AA03070@ginger.lcs.mit.edu> To: int-serv@isi.edu, nimrod-wg@bbn.com Subject: How to create and maintain state in a packet network Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu It seems to be an item of rough consensus that in the future internetwork, the routers will need to contain more state about the traffic flowing through them if we want to provide fair sharing of resources etc. A smaller, but influential, group feels that in order to provide certain services we will need to be able to provide service guarantees, and do so in a way which requires explicit reservation of resources. All of this means more state in the routers. The interesting question is how this state gets into the routers; is it inferred from watching the datagrams which flow through the router, or is in installed in some more explicit way? In all of this discussion, I'm passing over the need to retain support for real datagrams, i.e. transactions which require only a single packet. (In fact, I'm going to use the term "datagram" from here on out to refer to such applications, and use the term "packet" to describe the unit of transmission through the network.) There's clearly no point in storing any state about that datagram in the routers; it's come and gone in the same packet, and this discussion is all about state retention, so that's why I don't talk about them. However, don't assume from this discussion of how to handle the packets generated by non-datagram applications that I'm advocating system which support *only* such packet sequences (which we call "flows"). As another aside, I still think that the unreliable packet ought to be the fundamental building block of the internetwork layer. I really like the design principle that says that we can take any packet and throw it away with no warning or other action, or take any router and turn it off with no warning, and have the system still work. The component design simplicity (since routers don't have to stand on their heads to retain a packet which they have the only copy of), and overall system robustness, resulting from these two assumptions is absolutely unloseable. Anyway, back to the question is how the state gets into the routers. There is an interesting potential synergy here, because there is thought being given to routing architectures which, for reasons of engineering efficiency, store more state in the routers for long-lived flows. (There may be similar thoughts in the security and billing areas, but I'm not aware of them.) It's important to realize that there is no *fundamental* reason why this state has to be stored in the routers, and looked up via a key in the packets. It could easily be repeated in every packet (as a source route), but we don't plan on doing so for reasons of efficiency in header size (both in terms of bandwidth, and in processing to create and forward the packets). This observation is of some use when thinking about the router state which is used for doing resource allocation. Some of that state might be information about the user's service needs; information which could be sent in each packet, or which can be saved in the router, depending on which makes the most engineering sense. I call such state, which reflects the desires of the user, "user state", even when a copy is cached in the routers. However, other state is needed for this cannot be stored in each packet; it's state about the longer-term (i.e. spanning multiple packets) situation. I call this state "server state". There are two schools of thought as to how to proceed. The first says that for reasons of robustness and simplicity, all "user state" (resource class info, source route, etc) ought to be repeated in each packet. For efficiency reasons, the routers may cache such "user state", probably along with precomputed data derived from the user state. (It makes sense to store such cached user state along with any applicable server state, of course.) This school may be subdivided into two subschools, depending on what hint they use in the packet to find this cached state. (It's a hint, not a key, since the state in the router can be discarded at any time without making it impossible to forward the packet.) In one school, there's a field (the flow-id) whose sole purpose in life is to be a hint. In the other school, a number of other fields (source as source and destination address, port, etc) combine to be the hint. The second school says that it's simply going to be too inefficient to carry all the user state around all the time, and we should just bite the bullet, install it in the routers directly, and include in the packets a key (also called a flow-id, just to be confusing) to find that state. I call this this "installation" school. I'm not sure how much use there is to any intermediate position. It seems to me that to have one internetwork layer subsystem (e.g. resource allocation) carry user state in all the packets, and use a hint in the packets to find it, and have a second (e.g. routing) use a direct installaion, and use a key in the packets to find it, makes little sense. We should do one or the other, based on a consideration of the efficiency/robustness tradeoff. It's a little difficult to make this choice without more information of exactly how much user state the network is likely to have in the future (i.e. we might wind up with 500 byte headers if we include the full source route, resource reservation, etc, etc in every header). It's also difficult without consideration of the actual mechanisms involved. As a general principle, we wish to make recovery from a loss of state as local as possible, to limit the number of entities which have to become involved. For instance, when a router crashes, traffic is rerouted around it without needing to open a new TCP connection. In a similar way, the option of the "installation" looks a lot more attractive if it's plausible, and relatively cheap, to reinstall the user state when a router crashed, without otherwise causing a lot of hassle. My intuition tells me that in the long run we're better off with just biting the bullet on user state, and going to an installation paradigm with keys, not replicated user state in each packet with hints, but until we see more details it may prove difficult to know for sure which way is the best way. Noel From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 05:15:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27309; Wed, 30 Mar 1994 05:15:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA26277; Wed, 30 Mar 1994 05:14:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA26260; Wed, 30 Mar 1994 05:05:18 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26224; Wed, 30 Mar 1994 04:39:29 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-16) id ; Tue, 29 Mar 1994 10:35:03 -0800 Date: Tue, 29 Mar 1994 10:35:03 -0800 From: braden@ISI.EDU (Bob Braden) Message-Id: <199403291835.AA23930@zephyr.isi.edu> To: int-serv@ISI.EDU, nimrod-wg@bbn.com, jnc@ginger.lcs.mit.edu Subject: Re: A taxonomy of state and tags in datagram networks Cc: big-internet@munnari.OZ.AU *> one), such as routing table entries; and cached state which is not necessary *> for the correct forwarding of packets. The term "soft state" is, I believe, *> sometimes used to refer to the latter kind of state. Noel, I would say that cached state is simply an example of soft state. The essential feature of soft state is that the router is allowed to delete it without an explicit deletion request. RSVP state is another example of soft state; if it is deleted, packets cannot be forwaarded "correctly" (although they may or may not be forwarded as best-effort datagrams). Yet a router is allowed to time it out and delete the RSVP state that is not refreshed. *> Note that neither of these states is what we refer to as "critical" *> state, i.e. state which is critical to a given end-end communication, and *> which, once lost, means the loss of the connection. An example of this is *> the state of a TCP connection, as stored co-located (i.e. sharing fate) with *> the application. YOu have to get over this exclusively connectiontist view of applications, Noel! Most realtime applications don't have state in that sense. Bob Braden From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 05:16:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27330; Wed, 30 Mar 1994 05:16:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA26292; Wed, 30 Mar 1994 05:15:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA26263; Wed, 30 Mar 1994 05:06:09 +1000 Received: from pooh.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26614; Wed, 30 Mar 1994 04:49:32 +1000 (from john@iastate.edu) Received: by iastate.edu with sendmail-5.57/4.7 id ; Tue, 29 Mar 94 12:44:39 -0600 Message-Id: <9403291844.AA18886@iastate.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) To: int-serv@ISI.EDU, nimrod-wg@bbn.com To: big-internet@munnari.OZ.AU Subject: Re: How to create and maintain state in a packet network In-Reply-To: Your message of Tue, 29 Mar 94 10:54:59 -0500. <9403291554.AA03070@ginger.lcs.mit.edu> Date: Tue, 29 Mar 94 12:44:39 CST From: John Hascall [...] > Anyway, back to the question is how the state gets into the routers. [...] > There are two schools of thought as to how to proceed. [...school 1) all state in every packet...] [....subschool 1a) dedicated field in packet as hint to state cache...] [....subschool 1b) combine existing fields as hint...] [...school 2) install state in routers, key in packet to find state...] > I'm not sure how much use there is to any intermediate position. It seems to me that there is an intermediate position worth exploring. Have a hint in the packet (preferably a dedicated one in my eyes), and have the initial packet contain the state as an option (a la TCP MSS). Since it is a hint the router could discard it based on whatever criteria (LRU, timeout, lack of space, crash, etc.). It seems to me you would want a way for a router to request the hint again (if it was discarded or if the routing changed and new router wanted the hint). ICMP or its successor would seem the most obvious methodology to request it occur in the next convenient packet. John ----------------------------------------------------------------------------- John Hascall An ill-chosen word is the fool's messenger. Systems Software Engineer Project Vincent Iowa State University Computation Center + Ames, IA 50011 + 515/294-9551 From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 06:19:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26060; Wed, 30 Mar 1994 04:36:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id EAA26221; Wed, 30 Mar 1994 04:34:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id EAA26205; Wed, 30 Mar 1994 04:21:15 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24402; Wed, 30 Mar 1994 03:46:18 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa15061; 29 Mar 94 12:46 EST To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of Tue, 29 Mar 1994 23:24:32 +1000. <9403291324.14822@munnari.oz.au> Date: Tue, 29 Mar 1994 12:45:36 -0500 From: John Curran Message-Id: <9403291246.aa15061@nic.near.net> -------- ] From: Robert Elz ] Subject: Minimal Changes & IPng ] Date: Tue, 29 Mar 1994 23:24:32 +1000 ] ... ] Anyway, with a combination of the aeiou BOF (and the words "minimal changes", ] which seems like a good idea to me), and then the immediately following ALE ] wg meeting, in which Fank and Tony managed to make quite clear that the ] immediate problem is router routing table space (runs out maybe in 1996, ] depending on "magic"), not IP address space (runs out 2005, absolute worst ] estimate), I started pondering all this again. ] ... ] Anyway, ] for whatever reason, lots of bright people set off to design IP replacements, ] they have all concentrated on bigger addresses, and kind of (except in one ] case that seems no longer very relevant) basically ignored the routing ] problem - the assumption seems to be that we can always just make use of ] however IPv4 survives in the meantime, even if that means simply buying ] bigger and faster routers. ] ] Unfortunately Tony's presentation kind of wiped that out as a solution, ] the routing problem needs to be solved. Robert, I'm not sure that it's valid to say folks "basically ignored the routing problem"... There's an initiative known as CIDR, right? Providers have been upgrading to BGP4 but there has not been sufficient deployment to safely announce CIDR aggregates without corresponding individual routes. There is still a major exchange point on the Internet which is not using BGP4 among all peers, but this is scheduled for resolution later this week. Before declaring that the routing problem needs to be solved, it might be worth seeing the result of individual route withdrawal over the next 30 days. /John From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 07:13:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00742; Wed, 30 Mar 1994 06:55:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA26388; Wed, 30 Mar 1994 06:54:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA26385; Wed, 30 Mar 1994 06:46:00 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27921; Wed, 30 Mar 1994 05:37:04 +1000 (from dcrocker@mordor.stanford.edu) Received: from [192.220.248.132] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA28721; Tue, 29 Mar 1994 11:36:52 -0800 Date: Tue, 29 Mar 1994 11:36:52 -0800 X-Sender: dcrocker@mordor.stanford.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Elz From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Robert, et al, At 1:24 PM, Robert Elz wrote: ... >, not IP address space (runs out 2005, absolute worst >estimate), The great and continuing danger of the ALE work, and the like, is that it consistently and exclusively projects the future based on the past. It makes no effort to factor in new-market uses for the Internet. As I and others have repeatedly observed, there is a true and extensive mass-market set of opportunities, ranging from PDAs to telephone and utility poles, over the next few years. This makes the "absolute worst estimate" far, far, far sooner than 2005. It is time that we stop deluding ourselves that we have a clue how soon (or late) we are going to hit the wall. We need to plan on requiring larger and better structured address as soon as we can. Our current tendency is to make ourselves comfortable with viewing the wall as far away. This is certain to make us unresponsive to the new uses. We are already suffering a public perception problem from the lingering failure to resolve this issue. Dave From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 07:35:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01955; Wed, 30 Mar 1994 07:35:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA26443; Wed, 30 Mar 1994 07:34:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA26438; Wed, 30 Mar 1994 07:29:42 +1000 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01806; Wed, 30 Mar 1994 07:30:51 +1000 (from kre) Date: Wed, 30 Mar 1994 07:30:51 +1000 From: Robert Elz Message-Id: <9403292130.1806@munnari.oz.au> To: jcurran@nic.near.net Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Date: Tue, 29 Mar 1994 12:45:36 -0500 From: John Curran Message-Id: <9403291246.aa15061@nic.near.net> I'm not sure that it's valid to say folks "basically ignored the routing problem"... There's an initiative known as CIDR, right? OK, Sorry, that's not what I intended to mean ... I know of the IETF work to conserve IPv4 routing table space, and help the world survive, and its all great and all that, and I certainly wasn't meaning to ignore it in any way. What I meant to say was that none of the IPng proposals (with the one now irrelevant exception) have any new startling routing architecture that makes all this irrelevant, that is, if IPv4 routing works, the IPng's will work too, if IPv4 fails, so will IPng (again, except for the "we get to start again" comment). That means to me that as far as solving routing problems go, none of the IPng proposals are worth anything. Before declaring that the routing problem needs to be solved, it might be worth seeing the result of individual route withdrawal over the next 30 days. Great, as it happens it will be fantastic, I think all I did here was repeat Tony's pessimism from the ALE wg meeting. I think most people there (including Tony) were expecting/hoping/praying that CIDR is going to do as expected, and that the net managers will actually do the work to withdraw routes, and this potential problem will fade into the distance. If that happens, its great, it means we no longer have any pressing need to do anything at all (and I will come to Dave's response in a bit, but its time for the next session, so sorry Dave, you have to wait...) kre From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 07:55:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02862; Wed, 30 Mar 1994 07:55:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA26473; Wed, 30 Mar 1994 07:54:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA26470; Wed, 30 Mar 1994 07:53:04 +1000 Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02793; Wed, 30 Mar 1994 07:54:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07846; Tue, 29 Mar 94 16:54:06 -0500 Date: Tue, 29 Mar 94 16:54:06 -0500 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9403292154.AA07846@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, kre@munnari.OZ.AU Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu > it consistently and exclusively projects the future based on the past. > It makes no effort to factor in new-market uses for the Internet. > ... there is a true and extensive mass-market set of opportunities, > ranging from PDAs to telephone and utility poles, over the next few > years. This is certainly true, but I don't think KRE would disagree. His point, and one you've not really touched on, is that we don't *seem* to be able to *effectively route* in an address space of the size we've *already* got. Unless we have a path to which will make this work, we're wasting our time with larger addresses. As an aside, I will mention that there are plausible solutions based on recognition of the fact that I'm unlikely to want to be able to telnet to my phone pole. It would not be implausible to use TCP/IP technology, off the shelf, to support that, with the addresses for the phone poles coming from a separate address space. It is time that we stop deluding ourselves that we have a clue how soon (or late) we are going to hit the wall. We need to plan on requiring larger and better structured address as soon as we can. "More haste, less speed." I'd like to make sure we know where we're going, before we decide we just have to run (because the perception is we have to run somewhere, anywhere, as long as we run), and run straight off a cliff. It's true our projections aren't likely to be perfect, but they are better than nothing, and it's just as unreasonable to cry "the sky is falling" without a quantified case as to why, as to say "no worries" with no case as to why. This is certain to make us unresponsive to the new uses. I'm not sure I concur with this... I'm personally excited by potential new uses, *provided we can make an Internet of that size work*, e.g. in the routing. We are already suffering a public perception problem from the lingering failure to resolve this issue. This is a good point. However, to what degree is this because it's an accurate perception of reality, and to what degree is it caused by our inordinate rush to select a new packet format? Not that I'm in favour of trying to control public concerns about this with "spin"; I'm not sure what exactly the answer is to this, but it's something we need to be very aware of. However, I personally think that "public" would be as worried with a system which couldn't route in a system of the size they want, or a system which couldn't provide the services they need (such as resource guarantees) as with one which simply lacked address space. Noel From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 17:02:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21646; Wed, 30 Mar 1994 16:36:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA26921; Wed, 30 Mar 1994 16:34:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA26904; Wed, 30 Mar 1994 16:20:48 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09071; Wed, 30 Mar 1994 10:59:54 +1000 (from dcrocker@mordor.stanford.edu) Received: from [192.220.248.124] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA04822; Tue, 29 Mar 1994 16:59:41 -0800 Date: Tue, 29 Mar 1994 16:59:41 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 9:54 PM, Noel Chiappa wrote: >This is certainly true, but I don't think KRE would disagree. His point, and >one you've not really touched on, I was carefully trying not to comment on the routing table problem. I have to believe that people running routers know when their tables are full. >As an aside, I will mention that there are plausible solutions based on >recognition of the fact that I'm unlikely to want to be able to telnet to >my phone pole. It would not be implausible to use TCP/IP technology, off >the shelf, to support that, with the addresses for the phone poles coming >from a separate address space. As an aside, I will mention that I think it would be irresponsible of the Internet technical community to modify the Internet addressing and operations architecture so that we start REQUIRING people to operate in isolated address spaces. If you want to start talking about risks, then start talking about IMPOSING that requirement where it didn't previously exist. I.e., "plausible" in theory in this case is potentially very dangerous in fact. >"More haste, less speed." I'd like to make sure we know where we're going, This stuff has been getting intense effort for quite awhile, Noel. For each of the various technical lines of effort, either the work has been competent or it hasn't. It ain't gonna get better by waiting. There ALWAYS are reasons to delay. >before we decide we just have to run (because the perception is we have to >run somewhere, anywhere, as long as we run), and run straight off a cliff. Noel, the ground is moving out from under us. We don't need to run to the cliff. It's coming to us. (I live in earthquake country; the image is real.) >It's true our projections aren't likely to be perfect, but they are better >than nothing, You are wrong. They are much worse than nothing. That is why I sent my note. The projections are tending to delude folks into thinking we have a long time. For example, some members of the IPng Directorate seem to believe that they can take meaningful guidance from the ALE effort. They can't. Dave From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 18:24:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24742; Wed, 30 Mar 1994 17:58:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id RAA27001; Wed, 30 Mar 1994 17:54:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id RAA26985; Wed, 30 Mar 1994 17:38:12 +1000 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23811; Wed, 30 Mar 1994 17:38:36 +1000 (from kre) Date: Wed, 30 Mar 1994 17:38:36 +1000 From: Robert Elz Message-Id: <9403300738.23811@munnari.oz.au> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Date: Tue, 29 Mar 1994 16:59:41 -0800 Message-Id: From: dcrocker@mordor.stanford.edu (Dave Crocker) Noel said much of what I would have said in response to your earlier message, so I won't rehash that again. As an aside, I will mention that I think it would be irresponsible of the Internet technical community to modify the Internet addressing and operations architecture so that we start REQUIRING people to operate in isolated address spaces. I believe that too, however I have no objection to rfc1597, nor to allowing that as an option for people who want to connect devices that have no rational reason to communicate with almost anyone, in their judgement. I also see that many of the community that want huge address spaces want them for applications that fit precisely into this category - they're very unlikely to ever realistically connect to the internet (especially not in its current insecure state), and consequently, using a non-unique address is not likely to be a problem. I wouldn't require this however, and I don't think we have to, if we are presented with an internet compatible application that needs lots of addresses, then we still have lots of class A space available, right? This is exactly what class A should be used for. The effect may be that we may need to actually start recycling the currently used class A addresses sooner than I would have liked (at say about 2020 or 2030, after reclaiming them in about 2005, this may need to move to 2010, or something) in order to meet the demains, if there is one. That I don't see as a big problem. >"More haste, less speed." I'd like to make sure we know where we're going, This stuff has been getting intense effort for quite awhile, Noel. It has, however I suspect that much of that effort has been based upon false assumptions. For each of the various technical lines of effort, either the work has been competent or it hasn't. Competent it may be, but very competantly solving the wrong problem. It ain't gonna get better by waiting. Here I disagree completely. If we can put effort into solving a bigger problem, and solve that instead, it will indeed be better. The major problem with all current proposals, is that they currently have no sane transition plan - that is, transition plan out of IPng and into IPds9 (or whatever). The next transition will be as painful as this one is, which would be an unpardonable sin. However, this can be made better. Once we can see that having adopted IPng, we can then switch to even later IP's with comparative ease, then it will be time to make this one huge modification, before then anything is premature. There ALWAYS are reasons to delay. Yes, sometimes they're just based on fear, however sometimes they're based on prudent caution. I admit that its not always easy to see the difference, but we must avoid the fear of the fear. You are wrong. They are much worse than nothing. This is very unfair to the ALE people (of whom I am not one). They appreciate the point you are making, as do we all I believe. Information is never worse than none, unless you're selling superstition. Don't hide from it, demonstrate its fallacy, if you can do that, then the initial work has benefitted us all by prompting the rebuttal. If not, then your theories are certainly no better than the ones you oppose. Whether the theory that we have a long time or not is a delusion is something that we won't know for certain without hindsight, simply labelling it that way is not helping anyone. Jumping into a new IP layer from which we have little hope of escape is just as big, or bigger, risk, than doing nothing. The worst we can really achieve by doing nothing is in stagnating - not being able to connect new applications. They will then go elsewhere, and perhaps create a bigger better net. Fine, if they do, we can all go and join them. We will no longer be in control, but so what? The aim is surely not power to the IETF is it? Further, there are plenty of other plausible scenarios that leat to breakaway alternate nets, such as pricing policies, etc, that could lead to this even if we have given outselves a few extra address bits so we can admit the universe - they may still not want to play in our yard, and we would have suffered the pain for no gain. I certainly agree the big address efforts should continue, and be supported, I don't agree that at the minute we need, or even want, to pick one in a rush. The impression that we're moving slowly has been based on the "we ran out last week" hype that's been pushed so hard, we must not allow the hype to sway our decisions, that would not be the IETF way of making decisions on technical grounds - and even the decision to make a decision is a decision of itself. kre From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 21:16:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00792; Wed, 30 Mar 1994 21:16:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA27223; Wed, 30 Mar 1994 21:14:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA27209; Wed, 30 Mar 1994 21:08:42 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00621; Wed, 30 Mar 1994 21:09:53 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id DAA02883; Wed, 30 Mar 1994 03:09:38 -0800 Date: Wed, 30 Mar 1994 03:09:38 -0800 From: Tony Li Message-Id: <199403301109.DAA02883@lager.cisco.com> To: kre@munnari.OZ.AU (Robert Elz) Cc: Big-Internet@munnari.OZ.AU Subject: Minimal Changes & IPng Anyway, with a combination of the aeiou BOF (and the words "minimal changes", which seems like a good idea to me), and then the immediately following ALE wg meeting, in which Fank and Tony managed to make quite clear that the immediate problem is router routing table space (runs out maybe in 1996, depending on "magic"), not IP address space (runs out 2005, absolute worst estimate), I started pondering all this again. Before you get your knickers in a twist, please understand that we do think that CIDR will fix the routing table explosion problem. We just have to motivate people to make use of it. The 1996 figure is quite reasonable IF people are uncooperative. While I'm trying to scare folks with this figure, I DO expect that we will get very good cooperation eventually. I'm _EXTREMELY_ concerned about the transient that we'll undergo in the meantime. First, its obvious (assuming we believe the numbers) that we have till 2005, which is good, as it would take at least that long to deploy any solution invented now anyway. But recall that's an (approx) worst case estimate, and basically tells us when class C addresses will run out. This completely ignores the huge pool of class C style addresses we have in the class A address space, Uhh.... no, sorry. My figures include ALL address space. That includes the A, B, and C space. It's 2008 +/- 3 or bust. BTW, dividing up a class A network into constituent prefixes and distributing them around IS described (in painful detail) in the CIDR architecture document. While I have vaguely contemplated asking folks holding class A networks for them back, I have not been able to must enough of my own political energy to start doing this. If someone would like to run with this.... Tony From owner-Big-Internet@munnari.OZ.AU Wed Mar 30 21:35:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01245; Wed, 30 Mar 1994 21:35:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA27253; Wed, 30 Mar 1994 21:34:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA27250; Wed, 30 Mar 1994 21:34:17 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01235; Wed, 30 Mar 1994 21:35:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id DAA03286; Wed, 30 Mar 1994 03:35:23 -0800 Date: Wed, 30 Mar 1994 03:35:23 -0800 From: Tony Li Message-Id: <199403301135.DAA03286@lager.cisco.com> To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng Dave, The great and continuing danger of the ALE work, and the like, is that it consistently and exclusively projects the future based on the past. It makes no effort to factor in new-market uses for the Internet. As I and others have repeatedly observed, there is a true and extensive mass-market set of opportunities, ranging from PDAs to telephone and utility poles, over the next few years. This makes the "absolute worst estimate" far, far, far sooner than 2005. And as I and others have repeatedly observed, there is a simple and reasonable mechanism for greatly reducing the number of globally unique addresses in the world. The effects of this are complete speculation, as are the effects that you describe. I fully acknowledge that both _CAN_ happen. However, my charter in ALE is to engage in reasonable science and extrapolation from existing figures, not to engage in baseless speculation. [That's reserved for the bar. ;-)] In fact, if you want to speculate, one "high likelihood" scenario is that the two effects of future paradigm shifts and future address savings measures negate each other to a first order. For example, if we decide to number telephone poles, we might decide to put all of them behind a NAT. Net address consumption: 1 class C. It is time that we stop deluding ourselves that we have a clue how soon (or late) we are going to hit the wall. We need to plan on requiring larger and better structured address as soon as we can. Our current tendency is to make ourselves comfortable with viewing the wall as far away. This is certain to make us unresponsive to the new uses. We are already suffering a public perception problem from the lingering failure to resolve this issue. It's also time to stop needless panic. IPng needs to proceed in a calm and rational fashion and do good engineering. Selecting an under-developed contender in a blind panic may help that contender's efforts in the short run, but in giving us an immature result will foist immeasureable harm on the Internet in the long run. I believe that we have enough time to do it right (assuming we do move forward). That said, your point is well taken -- we do not have time to lounge either. Tony From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 01:02:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05282; Wed, 30 Mar 1994 23:36:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id XAA27370; Wed, 30 Mar 1994 23:34:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id XAA27355; Wed, 30 Mar 1994 23:18:38 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00824; Wed, 30 Mar 1994 21:17:35 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id DAA03042; Wed, 30 Mar 1994 03:17:30 -0800 Date: Wed, 30 Mar 1994 03:17:30 -0800 From: Tony Li Message-Id: <199403301117.DAA03042@lager.cisco.com> To: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: Minimal Changes & IPng I'm not positive I quite understood this. I assume that what Tony was saying was that without more rational allocation of addresses (i.e. not flat), the resulting routing table growth will exceed the capability of vendors to build routers which can hold bigger routing databases (not to mention the ability of humans to configure all the knobs correctly :-)? In other words, we're going to have to assign addresses in ways that allows considerable aggregation of routing table entries, right? Not exactly. What I was saying was that we have to be prompt about deployment and configuration of aggregation now that we have almost all of the basic CIDR infrastructure in place. The alternative is to suffer and die. "Correct" address assignment has been ongoing for quite a while. The only piece of software/protocol we could usefully add is something to make reassignment of addresses/locators easier; stuff like DHCP. Past that, it's simply a matter of waiting for it to penetrate everyone's head that without rational address/locator assignment, *no* routing scheme will work. That's the real gating factor.... As mentioned in the working group, we could also use software to ease the management of arbitrary prefix routing. This would greatly reduce the requests on the number of Ph.D.'s used as network managers. Tony From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 01:59:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10970; Thu, 31 Mar 1994 01:55:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id BAA27556; Thu, 31 Mar 1994 01:54:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id BAA27542; Thu, 31 Mar 1994 01:38:49 +1000 From: hinden@eng.sun.com Received: from [192.9.5.5] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10374; Thu, 31 Mar 1994 01:38:40 +1000 (from hinden@eng.sun.com) Received: from applejack5.ietf29.nwnet.net by playground. (5.0/SMI-SVR4) id AD05730; Wed, 30 Mar 1994 07:39:02 +0800 Message-Id: <9403301539.AD05730@playground.> X-Sender: hinden@playground.sun.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Mar 1994 07:38:45 -0800 To: Robert Elz Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Content-Length: 2151 Robert, >OK, Sorry, that's not what I intended to mean ... I know of the IETF work >to conserve IPv4 routing table space, and help the world survive, and >its all great and all that, and I certainly wasn't meaning to ignore >it in any way. What I meant to say was that none of the IPng proposals This is not true. SIPP (w/ IPAE) includes a mechanism (sometimes called the mapping function) which can be used to greatly extend IPv4 routing. It provides a function to map 32bit IPv4 addresses to 64bit SIPP addresses (32bit prefix + 32bit IPv4 address). The additional information in the prefix increases the scalability of the routing. Note that we have received considerable feedback saying this capability is not needed because CIDR will extend IP routing for long enough to deploy IPng. I was not aware of any data which shows that CIDR will not do this. I beleve that the mapping function may be a useful tool to have available. >(with the one now irrelevant exception) have any new startling routing >architecture that makes all this irrelevant, that is, if IPv4 routing >works, the IPng's will work too, if IPv4 fails, so will IPng (again, >except for the "we get to start again" comment). All of the IPng proposals include larger addresses. They do this for two reasons: The first to to support more nodes. The second is to improve the scaling of the routing. The problem with IPv4 routing is that there is not enough bits to support enough layers of hierarchy to scale the routing. The larger addresses in the IPng proposals all deal with internet routing scaling. >That means to me that as far as solving routing problems go, none of the >IPng proposals are worth anything. In addition to SIPP/IPAE, note there have been other proposals which were focused on improving IPv4 routing. My original proposal called "IP Encapsulation" did just that with out any changes to hosts and only had to be deployed in backbone routers. The original IPAE proposal put forward by Dave Crocker also had a large element of improving the scaling of IPv4 routing. I would be happy to send you copies of these if you are interested. Bob From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 02:22:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11715; Thu, 31 Mar 1994 02:15:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA27630; Thu, 31 Mar 1994 02:14:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA27627; Thu, 31 Mar 1994 02:14:17 +1000 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11671; Thu, 31 Mar 1994 02:15:21 +1000 (from kre) Date: Thu, 31 Mar 1994 02:15:21 +1000 From: Robert Elz Message-Id: <9403301615.11671@munnari.oz.au> To: tli@cisco.com Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Date: Wed, 30 Mar 1994 03:09:38 -0800 From: Tony Li Message-Id: <199403301109.DAA02883@lager.cisco.com> Uhh.... no, sorry. My figures include ALL address space. That includes the A, B, and C space. It's 2008 +/- 3 or bust. Ah, finally a good counter argument, that wasn't clear, thanks. I still assume from what you said later that you're not including the 1/2 of the A space that is currently allocated, ie: 25% of the total available space. If we can last till 2005 without that, and perhaps reasonably reclaim that space by 2005, how much longer could we expect to last with that extra space, another 10 years, or a bit less? Another 5? kre From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 02:35:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12686; Thu, 31 Mar 1994 02:35:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id CAA27673; Thu, 31 Mar 1994 02:34:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id CAA27650; Thu, 31 Mar 1994 02:20:36 +1000 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12083; Thu, 31 Mar 1994 02:21:48 +1000 (from kre) Date: Thu, 31 Mar 1994 02:21:48 +1000 From: Robert Elz Message-Id: <9403301621.12083@munnari.oz.au> To: hinden@eng.sun.com Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Message-Id: <9403301539.AD05730@playground.> Date: Wed, 30 Mar 1994 07:38:45 -0800 From: hinden@eng.sun.com This is not true. SIPP (w/ IPAE) includes a mechanism (sometimes called the mapping function) which can be used to greatly extend IPv4 routing. It provides a function to map 32bit IPv4 addresses to 64bit SIPP addresses (32bit prefix + 32bit IPv4 address). The additional information in the prefix increases the scalability of the routing. Sure, but unless I'm missing something, which is entirely possible, there is nothing that is different in nature between this and IPv4 routing. More bits mean more levels, but when we get to the expected O(10^12) hosts or whatever, we're still going to (have to be) operating with giant routing tables spread all through the net, and all basically consistent. I'd very much like to see a revolution in routing technology, perhaps something from one of the other WG's working on routing now. If we don't absolutely have to delpoy IPng before such a thing appears, then I would prefer not to, that way a new routing technology can feel free, if it desires, to require new forwarding technology, perhaps requiring currently unimagined packet formats. Once IPng is deployed, that freedom will effectively be removed. This is why getting the best (reasonable) estimate of just how long we have seems important to me. kre From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 03:55:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15921; Thu, 31 Mar 1994 03:55:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA27768; Thu, 31 Mar 1994 03:54:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA27760; Thu, 31 Mar 1994 03:44:38 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13167; Thu, 31 Mar 1994 02:46:38 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id IAA17593; Wed, 30 Mar 1994 08:46:28 -0800 Date: Wed, 30 Mar 1994 08:46:28 -0800 From: Tony Li Message-Id: <199403301646.IAA17593@lager.cisco.com> To: kre@munnari.OZ.AU Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Thu, 31 Mar 1994 02:15:21 +1000 <9403301615.11671@munnari.oz.au> Subject: Minimal Changes & IPng If we can last till 2005 without that, and perhaps reasonably reclaim that space by 2005, how much longer could we expect to last with that extra space, another 10 years, or a bit less? Another 5? Let me put it this way: we use approximately a full A's worth of address space every month. Certainly reclaiming any address is extremely useful to us. How long we get depends again on psychology. Tony From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:11:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15969; Thu, 31 Mar 1994 03:58:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA27794; Thu, 31 Mar 1994 03:57:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA27763; Thu, 31 Mar 1994 03:48:06 +1000 Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12879; Thu, 31 Mar 1994 02:41:57 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA10700; Wed, 30 Mar 1994 18:46:13 +0200 Message-Id: <199403301646.AA10700@mitsou.inria.fr> To: Robert Elz Cc: tli@cisco.com, Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of "Thu, 31 Mar 1994 02:15:21 +1000." <9403301615.11671@munnari.oz.au> Date: Wed, 30 Mar 1994 18:46:13 +0200 From: Christian Huitema Thewre are two points which should be made clearer in this discusion: 1) Stability of the prediction 2) Precision of the asymptots I don't quite buy the argument that the predictions based on past history are entirely useless. The process of growth has a lot of built in histeresis: to get a new IP connection, there must be a provider, with a sale force, maintenance units, contracts, etc. All this takes time to establish. It is not unreasonable to think that this type of growth can be accurately predicted from past statistics. Clearly, this does not capture "revolutionary growth" - it is an OK model as long as we stay in the same market (computers) but would be blown apart if we move to the appliances and device market. There is one part in these predictions which I do not believe too much though - the usage of logistic curves and the deduction from the past history of a mythical asymptotis onto which we would converge. hey, this is base on extrapolations of the second derivative, an entirely unstable prediction. Even if we keep the previous model, we cannot account for "growth in the derivative", e.g. more vendors entering the market, more companies being launched, etc. This require capital investment and time but may very well happen. Thus, extrapolating teh current curves way after the 21st century is not entirely realistic! What we can get from our better knowledge of teh current pace of growth is a simple message - much like what Tony say. Don't panic: we may debate whether doom is coming in 2000, 2005 or 2010, but we can be pretty sure we have at leats 3 of 4 years of breathing pace. In the mean time, we should work on IPng and deploy it! And in the short time, we should certainly insist on doing CIDR! Christian Huitema From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:12:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16070; Thu, 31 Mar 1994 03:59:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id DAA27809; Thu, 31 Mar 1994 03:58:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id DAA27757; Thu, 31 Mar 1994 03:42:40 +1000 Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10503; Thu, 31 Mar 1994 01:42:50 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA04573; Wed, 30 Mar 94 07:44:20 -0800 Date: Wed, 30 Mar 94 07:44:20 -0800 From: Eric Fleischman Message-Id: <9403301544.AA04573@atc.boeing.com> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU Dear Dave and Noel, I appreciated your dialog and now want to add my two cents into it. I do ask for charitableness in reading this posting of mine because I seem to be incoherent due to lack of sleep (a normal IETF condition for me). Anyway, concerning Dave's comment: > You are wrong. They [the ALE projections] are much worse than nothing. > That is why I sent my note. The projections are tending to delude folks > into thinking we have a long time. > > For example, some members of the IPng Directorate seem to believe that they > can take meaningful guidance from the ALE effort. They can't. I greatly value the ALE projections. I feel that they are very useful in giving us a time frame of when IPng must be in place to satisfy the needs of the Internet via the 80-20 rule. That is, the projections show us a probable (though simplistic) timeline if we assume that the industry continues on as it has in the past and that it continues to satisfy the same algorithm of usage as in the past. Hopefully, this may be 80% of us. [Note: the previous sentence is NOT defensible so please don't bother to attack it: it is simply unbridled optimism and "hopefulness" with no justification or support.] Of course, several things disturb me about these projections such as the assumption that behavior will not change as we approach saturation and the "gut feel" that we are solely addressing "rates" (first derivatives) versus "accelleration" (second derivative) measurements and thus have an imprecise knowledge of the implications of our curves. Having said this, I still must concur that Dave's statement is true. Some of us are under the delusion that we have a long time. However, I have formed a contrary opinion that we have already missed our window for deploying IPng: it should have been in place some time ago because "toasternet" is almost upon us NOW and we are NOT ready for it. That is, I am alarmed that EPRI (electrical industry) and CDPD (cellular data industry) have adopted OSI technologies despite the fact that it is my personal perception that OSI technologies are generally "immature" and thus "risky" for widespread deployment (with several notable exceptions, of course). When I talk to people from these industries the invariable reason for their selection of OSI rather than the "more logical choice" of TCP/IP is that they could not get enough IP addresses to deploy TCP/IP in their infrastructures. Ouch! This means, to me, that while the Internet can doubtlessly support all of the technologies which I perceive MY industry will need for quite a while yet to come (as per the ALE projections), the total community is effectively out of addresses as of a year or two ago. That is, as of that time we became unable to support many of the new, novel, and creative uses of the Internet. For this reason I concur with Dave that we must not let the ALE projections delude us from expeditiously trying to resolve the network layer scaling problems. I share his concern that we must "fix this hole" quickly if we are to fulfill my vision of the Internet: a common world data highway built upon TCP/IP. However, like Noel, I intuitively believe that an important component of our problem is that IP addresses are sparse and that making them become EIDs is one way to resolve this problem. Which brings me to my question: how desperate are we? Do we have the time to create the most outstanding solution possible or should we grab the most advanced IPng alternative available to us today (that works) and simply go with it? And, most importantly, if we do create anything new will it ever become a viable product/option (i.e., who will deploy it except the most novel and isolatable new technologies given the immense inertia of IPv4 and the correspondingly immense backward compatability requirements)? Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:13:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19390; Thu, 31 Mar 1994 05:36:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA27914; Thu, 31 Mar 1994 05:34:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA27898; Thu, 31 Mar 1994 05:22:00 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14045; Thu, 31 Mar 1994 03:05:28 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA13700; Wed, 30 Mar 94 12:04:29 EST Message-Id: <9403301704.AA13700@tipper.oit.unc.edu> To: Robert Elz Cc: tli@cisco.com, Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of "Thu, 31 Mar 94 02:15:21 +1000." <9403301615.11671@munnari.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Mar 94 12:04:28 -0500 From: Simon E Spero I'd like to change the discussion slightly, by redefining the term 'out of addresses'. When implementing a memory allocator, the allocator is out of addresses when a request is made that cannot be satisfied, not when the last allocatable block has been passed out. If we take the analogous definition, how long does IPV4 then have? Simon From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:13:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19486; Thu, 31 Mar 1994 05:40:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id FAA27929; Thu, 31 Mar 1994 05:38:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id FAA27895; Thu, 31 Mar 1994 05:15:24 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13759; Thu, 31 Mar 1994 02:57:18 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id IAA18019; Wed, 30 Mar 1994 08:57:00 -0800 Date: Wed, 30 Mar 1994 08:57:00 -0800 From: Tony Li Message-Id: <199403301657.IAA18019@lager.cisco.com> To: Christian.Huitema@sophia.inria.fr Cc: kre@munnari.OZ.AU, tli@cisco.com, Big-Internet@munnari.OZ.AU In-Reply-To: Christian Huitema's message of Wed, 30 Mar 1994 18:46:13 +0200 <199403301646.AA10700@mitsou.inria.fr> Subject: Minimal Changes & IPng Christian, There is one part in these predictions which I do not believe too much though - the usage of logistic curves and the deduction from the past history of a mythical asymptotis onto which we would converge. My predictions are based on a LINEAR approximation. Frank's numbers on the numbers of networks are based on logistic curves. Please don't confuse the numbers. Tony From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:56:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22281; Thu, 31 Mar 1994 06:56:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA28063; Thu, 31 Mar 1994 06:54:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA28032; Thu, 31 Mar 1994 06:36:32 +1000 From: hinden@eng.sun.com Received: from [192.9.5.5] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21331; Thu, 31 Mar 1994 06:32:34 +1000 (from hinden@eng.sun.com) Received: from applejack1.ietf29.nwnet.net by playground. (5.0/SMI-SVR4) id AB07082; Wed, 30 Mar 1994 12:33:08 +0800 Message-Id: <9403302033.AB07082@playground.> X-Sender: hinden@playground.sun.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Mar 1994 12:32:50 -0800 To: Robert Elz Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU Content-Length: 1162 Robert, >Here I disagree completely. If we can put effort into solving a >bigger problem, and solve that instead, it will indeed be better. >The major problem with all current proposals, is that they currently have >no sane transition plan - that is, transition plan out of IPng and into >IPds9 (or whatever). The next transition will be as painful as this one >is, which would be an unpardonable sin. However, this can be made better. >Once we can see that having adopted IPng, we can then switch to even >later IP's with comparative ease, then it will be time to make this one >huge modification, before then anything is premature. You are making a point which I think is important. It is one of the reasons why the SIPP/IPAE effort has put so much effort into transition mechanisms. I think that the transition mechanisms we develop for IPng will be useful if we should have to transition again. I am not so brave as to imagine that anything we develop today will last forever. I hope it will last for a long time, but not forever. I think that the transition technology the IETF develops for IPng is just as important as the IPng itself. Bob From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 06:59:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22339; Thu, 31 Mar 1994 06:58:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id GAA28089; Thu, 31 Mar 1994 06:56:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id GAA28035; Thu, 31 Mar 1994 06:37:12 +1000 From: hinden@eng.sun.com Received: from [192.9.5.5] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21338; Thu, 31 Mar 1994 06:32:43 +1000 (from hinden@eng.sun.com) Received: from applejack1.ietf29.nwnet.net by playground. (5.0/SMI-SVR4) id AD07082; Wed, 30 Mar 1994 12:33:18 +0800 Message-Id: <9403302033.AD07082@playground.> X-Sender: hinden@playground.sun.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Mar 1994 12:33:00 -0800 To: Robert Elz Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU, hinden@eng.sun.com Content-Length: 2420 Robert, > This is not true. SIPP (w/ IPAE) includes a mechanism (sometimes called > the mapping function) which can be used to greatly extend IPv4 routing. It > provides a function to map 32bit IPv4 addresses to 64bit SIPP addresses > (32bit prefix + 32bit IPv4 address). The additional information in the > prefix increases the scalability of the routing. > >Sure, but unless I'm missing something, which is entirely possible, there >is nothing that is different in nature between this and IPv4 routing. >More bits mean more levels, but when we get to the expected O(10^12) hosts >or whatever, we're still going to (have to be) operating with giant >routing tables spread all through the net, and all basically consistent. I think you are underestimating the power of adding additional layers of hiearchy. The numbers we have worked out for SIPP (without even using the extended addressing capability) show that the amout of routing information at each level of the hierarchy is very managable. I believe that the TUBA folks have shown the same thing. >I'd very much like to see a revolution in routing technology, perhaps >something from one of the other WG's working on routing now. If we A revolution in routing technology would be nice, but solutions to very hard problems do not come easily. I think it would a mistake to wait hoping that a new routing will appear just in time. It seems clear to me that we will need an IPng before a new routing paradyme will be ready to deploy on a large scale. Hierarchical routing is a well known technology which we can deploy today. >don't absolutely have to delpoy IPng before such a thing appears, then >I would prefer not to, that way a new routing technology can feel free, >if it desires, to require new forwarding technology, perhaps requiring >currently unimagined packet formats. Once IPng is deployed, that >freedom will effectively be removed. I disagree. I would think that the IPng's under consideration in the IETF would all work with a new routing paradime. For example NIMROD (as I understand it) would work quite well with SIPP using the SIPP source and destionation addresses as identifiers. I don't any conflict here. >This is why getting the best (reasonable) estimate of just how long we >have seems important to me. As Dave Crocker has said, our ability to predict the future based on the past is limited. Bob From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 11:05:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23900; Thu, 31 Mar 1994 07:37:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA28153; Thu, 31 Mar 1994 07:35:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA28117; Thu, 31 Mar 1994 07:24:47 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23460; Thu, 31 Mar 1994 07:25:56 +1000 (from dcrocker@mordor.stanford.edu) Received: from [192.220.248.133] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id NAA01318; Wed, 30 Mar 1994 13:25:50 -0800 Date: Wed, 30 Mar 1994 13:25:50 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tony Li From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Robert Elz , Big-Internet@munnari.OZ.AU At 11:35 AM, Tony Li wrote: However, my charter in ALE is to >engage in reasonable science and extrapolation from existing figures, >not to engage in baseless speculation. [That's reserved for the bar. >;-)] Well, the exact wording in the charter is "develop an estimate for the remaining lifetime of the IPv4 address space based on currently known and available technologies" which is close to your description, but a bit more constrained than strictly required. Your summary means that the title of the working group is a bit misleading and ought to be more like Historical Analysis for Statistical Address Projection, or somesuch. In fact, the added markets that are being cited are here or otherwise visible on the horizen. E.g., 50 million pcs, due to one vendor's actions. Why these market pressures are being ignored in the analysis is a point of question I have yet to find an answer to. I'm afraid that your statement does capture part of the general problem. You believe you are engaged in a scientific process. You are wrong. You are using formal numerical techniques to perform something called "market projection". Such exercises have quite a bit of history of being wrong, in the face of a volatile market. Simple traffic projection only works in a stable market. You need assistance by people who do market planning. They don't have a great track record, either, but they at least will be better than using the remarkably myopic model currently dominating the Internet traffic projection work. >It's also time to stop needless panic. IPng needs to proceed in a >calm and rational fashion and do good engineering. Selecting an Tony, you might not have noticed, but there has been quite a bit of calm, rational engineering going on. Dave From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 12:22:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23875; Thu, 31 Mar 1994 07:36:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id HAA28138; Thu, 31 Mar 1994 07:34:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id HAA28120; Thu, 31 Mar 1994 07:24:50 +1000 Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23459; Thu, 31 Mar 1994 07:25:55 +1000 (from dcrocker@mordor.stanford.edu) Received: from [192.220.248.133] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id NAA01314; Wed, 30 Mar 1994 13:25:47 -0800 Date: Wed, 30 Mar 1994 13:25:47 -0800 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Robert Elz From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU At 7:38 AM, Robert Elz wrote: >(me) You are wrong. They are much worse than nothing. >(you) >This is very unfair to the ALE people (of whom I am not one). They >appreciate the point you are making, as do we all I believe. Information >is never worse than none, unless you're selling superstition. Don't >hide from it, demonstrate its fallacy, if you can do that, then the >initial work has benefitted us all by prompting the rebuttal. If not, >then your theories are certainly no better than the ones you oppose. Robert, we have folks from the ALE line of effort making public statements that we have 5-7 more years. We have folks from the ALE line of effort stating that we will run out of addresses roughly in 2008, IN THE WORST CASE. We have folks from the ALE line of effort making presentations with summary statements like DON'T PANIC. There well may be ALE folks who are concerned about explosive growth from new sectors, but it is not represented in the ALE work. This is in spite of repeated efforts by random rabid folks like myself to point out the fallacy of a strictly historical analisys. Yet, there have been no visible efforts to perform what-if analysis by these folks. If they are going to assert conclusive results from their work, it needs to stand up against this concern. So far, it doesn't. Dave From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 14:02:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01943; Thu, 31 Mar 1994 11:37:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id LAA28365; Thu, 31 Mar 1994 11:34:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id LAA28362; Thu, 31 Mar 1994 11:25:24 +1000 Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01502; Thu, 31 Mar 1994 11:26:24 +1000 (from solensky@mailserv-D.ftp.com) Received: from mailserv-D.ftp.com by ftp.com ; Wed, 30 Mar 1994 20:26:14 -0500 Received: from solensky.fenway.ietf29.nwnet.net by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08734; Wed, 30 Mar 94 20:25:27 EST Date: Wed, 30 Mar 94 20:25:27 EST Message-Id: <9403310125.AA08734@mailserv-D.ftp.com> To: dcrocker@mordor.stanford.edu Subject: Re: Minimal Changes & IPng From: solensky@ftp.com (Frank T Solensky) Cc: tli@cisco.com, kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU, ipv4-ale@ftp.com Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 30 20:25:23 1994] Originating-Client: fenway.ietf29.nwnet.net Content-Length: 2500 > From: dcrocker@mordor.stanford.edu (Dave Crocker) > ..added markets that are being cited are here or otherwise visible on the > horizen. E.g., 50 million pcs, due to one vendor's actions. > > Why these market pressures are being ignored in the analysis is a point of > question I have yet to find an answer to. Dave -- I'm not quite sure which vendor or action you have in mind, but at the risk of grossly simplifying or missing your point, it's my feeling that it's not likely that all 50 million PCs are all going to connect simultaneously and that some portion might not connect at all. Even so, 50 million IP addresses is, what, 4 Class As? There is still a large proportion of the total IP numbers available. Even assuming an exponential model, that suggests that there's still some number of years before the numbering problem is The Big Thing.. The Short-term Big Thing, clearly, is the routing table problem. Tony's point isn't that numbers are unimportant -- it's just that the routing table problem is the one that's more pressing. We need to get CIDR deployed, and soon. Numbers are MEDIUM term, and can probably get pushed out a bit more once we get a better feel as to how much getting people to be more efficient with their number assignments will buy us. Which we are working on. > You need assistance by people who do market planning. They > don't have a great track record, either, but they at least will be better > than using the remarkably myopic model currently dominating the Internet > traffic projection work. How's this then: if you or anyone else can point us toward such people, I'd be more than happy to factor their input into the model, along with the appropriate caveats. > >It's also time to stop needless panic. IPng needs to proceed in a > >calm and rational fashion and do good engineering. > > Tony, you might not have noticed, but there has been quite a bit of calm, > rational engineering going on. I don't think that he's disagreeing with you there.. However, deploying something Right Now because there might be something out there just doesn't seem justified, especially when we don't know what its requirements are.. Though the ipv4-ale list has been distressingly quiet, again, we'd be happy to make the model better if you or anyone else can make a specific suggestion as to what improvements can be made.. Perhaps we should deflect the discussion over to the ale list? (subscribe address: ipv4-ale-request@ftp.com). -- Frank From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 15:28:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07354; Thu, 31 Mar 1994 13:36:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA28486; Thu, 31 Mar 1994 13:34:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA28469; Thu, 31 Mar 1994 13:18:43 +1000 From: jcjones@MIT.EDU Received: from ATHENA-AS-WELL.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28636; Thu, 31 Mar 1994 10:02:17 +1000 (from jcjones@MIT.EDU) Received: from M16-034-25.MIT.EDU by MIT.EDU with SMTP id AA00368; Wed, 30 Mar 94 18:47:47 EST Received: by m16-034-25.MIT.EDU (5.0/4.7) id AA13348; Wed, 30 Mar 94 18:47:45 EST Message-Id: <9403302347.AA13348@m16-034-25.MIT.EDU> To: big-internet@munnari.OZ.AU Subject: Solution is on the way... Date: Wed, 30 Mar 94 18:47:44 EST Content-Length: 1727 ********** I HAVE THE SOLUTION TO THE INTERNET PROBLEM ********** I am not going to bore you with the details here, but I will say that a paper is forthcoming. The sooner I get my proof-of-concept testing done, the sooner the paper will come. In the meantime, I desperately need support. If there is anyone out there who is willing to provide equipment for testing please contact me. I have been trying to do testing using two RS232 ports on my two IBM-PC/XT's, and things just aren't happening as fast as I would like them to. I need real machines, a real C compiler, a real assembler, and real network adapters. To all you people out there in Internet land, this is what you have coming: 1. 1,000,000,000,000,000,000 (ten-to-the-18) addressable nodes 2. Small routing tables: The biggest routing table on the Internet will never onsume more than 1 megabyte of memory. 4. Trivial network management: some of you network administrators will kick yourselves when you see how easy things could/should have been. 5. Mobility of hosts. *Security should be handled at the OSI Session and Transport Levels* For those of you who think that I am blowing smoke, let the flames rip. For those of you who realize the consequences of a universally acceptable solution that can be deployed before the end of this year, please give me a call or me send e-mail. (617) 494-1034 J.C. Jones 129 Franklin St. #100 Cambrige, MA 02139 U.S.A. P.S. - I don't know if this is the appropriate place to put a message like this. If it is not, I'm sure you'll let me know. I would also like to state for the record that the solution I that intend to provide was conceived by myself alone on October 14, 1987. From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 15:58:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07430; Thu, 31 Mar 1994 13:38:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id NAA28501; Thu, 31 Mar 1994 13:37:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id NAA28483; Thu, 31 Mar 1994 13:27:09 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28436; Thu, 31 Mar 1994 09:55:05 +1000 (from solensky@mailserv-D.ftp.com) Received: from [128.127.2.122] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23439 Thu, 31 Mar 1994 09:54:34 +1000 (from solensky@mailserv-D.ftp.com) Received: from mailserv-D.ftp.com by ftp.com ; Wed, 30 Mar 1994 18:51:58 -0500 Received: from solensky.fenway.ietf29.nwnet.net by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08183; Wed, 30 Mar 94 18:51:11 EST Date: Wed, 30 Mar 94 18:51:11 EST Message-Id: <9403302351.AA08183@mailserv-D.ftp.com> To: Christian.Huitema@sophia.inria.fr Subject: Re: Minimal Changes & IPng From: solensky@ftp.com (Frank T Solensky) Cc: kre@munnari.OZ.AU, tli@cisco.com, Big-Internet@munnari.OZ.AU Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Wed Mar 30 18:51:02 1994] Originating-Client: fenway.ietf29.nwnet.net Content-Length: 2858 > From: Christian Huitema > > There is one part in these predictions which I do not believe > too much though - the usage of logistic curves and the > deduction from the past history of a mythical asymptotis > onto which we would converge... Even if we keep the previous model, > we cannot account for "growth in the derivative", e.g. more vendors > entering the market, more companies being launched, etc... > Thus, extrapolating the current curves way after the 21st century > is not entirely realistic! To some degree, we can account for this.. There was a good article in Dec 1990 CACM that made the argument that new technologies, once they get past some critical mass, create their own demand. New people get connected because there's enough of a base out there to present the motivation to the unconnected. New busniesses are formed because there's enough market demand for it. Telephones followed a similar pattern in the early part of this century. Also keep in mind that the graphs I'm making use a log scale -- we're still _way_ short of the inflection point of the curve. An acknowledged problem with this whole exercise is that Tony and I are using history to predict the future. We're getting some rough estimate on how growth in communications between computers might go. We've said it often but it can't be repeated often enough: we can't pretend to have an idea as to what happens when New Things start to connect. One advantage that the 19th century mathematician who first used the logistic curve to make good predictions of the US population well into the 20th century and whose name escapes me right now was that he didn't need to consider new life forms in his model. (Another advantage he had, of course, was that by the time the "actual"s were running ahead of his "predicted"s in the early 1950s, he was long dead..) I'm delibrately NOT saying that "this is how big the Internet will become" with these curves: my focus has been on "this is when we're going to start seeing problems if we don't change anything"; same as when the Class B numbers were being handed out whenever someone said that their net would eventually have more than 254 nodes. > What we can get from our better knowledge of the current > pace of growth is a simple message - much like what Tony > say. Don't panic: we may debate whether doom is coming in > 2000, 2005 or 2010, but we can be pretty sure we have at > leats 3 of 4 years of breathing pace. In the mean time, we > should work on IPng and deploy it! This is, in essence, what I'm saying with the button: we should be _concerned_, consider ways around the very short-term issues like using CIDR for the routing tables -- this allows us to make a more reasoned choice for IPng. PANIC, however, is both unwarranted and unproductive. -- Frank From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 18:27:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14494; Thu, 31 Mar 1994 16:38:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id QAA28668; Thu, 31 Mar 1994 16:34:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id QAA28654; Thu, 31 Mar 1994 16:21:10 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12378; Thu, 31 Mar 1994 15:44:20 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id VAA02843; Wed, 30 Mar 1994 21:44:11 -0800 Date: Wed, 30 Mar 1994 21:44:11 -0800 From: Tony Li Message-Id: <199403310544.VAA02843@lager.cisco.com> To: ses@tipper.oit.unc.edu Cc: kre@munnari.OZ.AU, tli@cisco.com, Big-Internet@munnari.OZ.AU In-Reply-To: Simon E Spero's message of Wed, 30 Mar 94 12:04:28 -0500 <9403301704.AA13700@tipper.oit.unc.edu> Subject: Minimal Changes & IPng I'd like to change the discussion slightly, by redefining the term 'out of addresses'. When implementing a memory allocator, the allocator is out of addresses when a request is made that cannot be satisfied, not when the last allocatable block has been passed out. If we take the analogous definition, how long does IPV4 then have? If we take that definition, then it's all over already. We had a request from a power company at the last IETF for enough address space to number every power meter in NJ. This was some zillion addresses, which simply weren't tractable. They probably went elsewhere. Shall we just turn of the Internet and go home? Tony From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 19:56:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21538; Thu, 31 Mar 1994 19:56:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id TAA28883; Thu, 31 Mar 1994 19:54:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id TAA28869; Thu, 31 Mar 1994 19:38:23 +1000 Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13698; Thu, 31 Mar 1994 16:20:32 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8/8.6.5) id WAA03482; Wed, 30 Mar 1994 22:20:18 -0800 Date: Wed, 30 Mar 1994 22:20:18 -0800 From: Tony Li Message-Id: <199403310620.WAA03482@lager.cisco.com> To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng Yet, there have been no visible efforts to perform what-if analysis by these folks. I'd love to. What if no one ever asked for an IP address again? Ok, we're done. What if someone walks up tomorrow and asks for 2^32? Ok, we're also done. The problem is that reality is hopefully somewhere between the two extremes. I just have no serious clue as to what's reasonable. Now, we can go on arguing with each other for the rest of the week, or we can do something productive. Which will it be? If they are going to assert conclusive results from their work, it needs to stand up against this concern. No one is asserting conclusive results. There are caveats all over the place, Dave. Please grok them... Tony From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 20:29:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19015; Thu, 31 Mar 1994 18:36:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id SAA28785; Thu, 31 Mar 1994 18:34:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id SAA28768; Thu, 31 Mar 1994 18:22:28 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13930; Thu, 31 Mar 1994 16:25:17 +1000 (from ericf@atc.boeing.com) Received: from atc.boeing.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07964 Thu, 31 Mar 1994 16:09:38 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA26321; Wed, 30 Mar 94 22:08:38 -0800 Date: Wed, 30 Mar 94 22:08:38 -0800 From: Eric Fleischman Message-Id: <9403310608.AA26321@atc.boeing.com> To: kre@munnari.OZ.AU, ses@tipper.oit.unc.edu Subject: Re: Minimal Changes & IPng Cc: Big-Internet@munnari.OZ.AU, tli@cisco.com Dear Simon, According to your definition (see below), IP is already out of addresses. I conclude this in view of the actions of the Power Companies (EPRI) and by the Cellular Data companies (e.g., CDPD spec) which concluded that the remaining IP address space was inadequate for their needs and therefore they adopted another protocol other than TCP/IP to "meet their needs". Of course, there are doubters who say that they did not fully evaluate their IP options before making their decision. I, for one, am ignorant of how they made their decision and thus can not address this contention. Sincerely yours, --Eric Fleischman >From: Simon E Spero >I'd like to change the discussion slightly, by redefining the term >'out of addresses'. When implementing a memory allocator, the allocator >is out of addresses when a request is made that cannot be satisfied, not when >the last allocatable block has been passed out. If we take the analogous >definition, how long does IPV4 then have? From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 21:15:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23307; Thu, 31 Mar 1994 20:56:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA28972; Thu, 31 Mar 1994 20:54:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA28956; Thu, 31 Mar 1994 20:35:49 +1000 Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20598; Thu, 31 Mar 1994 19:26:35 +1000 (from whyman@mwassocs.demon.co.uk) Date: Thu, 31 Mar 1994 10:25:25 GMT Message-Id: <9403311025.aa587@mwassocs.demon.co.uk> Reply-To: whyman@mwassocs.demon.co.uk From: whyman@mwassocs.demon.co.uk (Tony Whyman) To: ericf@atc.boeing.com Cc: Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng X-Mailer: Cinetic Mail Manager V2.1 | |From: Eric Fleischman | |That is, I am alarmed that EPRI (electrical industry) and CDPD (cellular | |data industry) have adopted OSI technologies despite the fact that it | |is my personal perception that OSI technologies are generally "immature" | |and thus "risky" for widespread deployment (with several notable exceptions, | |of course). When I talk to people from these industries the invariable | |reason for their selection of OSI rather than the "more logical choice" of | |TCP/IP is that they could not get enough IP addresses to deploy TCP/IP | |in their infrastructures. Ouch! | | You are touching on an important point here, which I wish was taken more seriously by the Internet commununity. While IPv4 is a good buy this year, it is perceived as broken for anyone looking at a long term strategy. From conversations with colleagues who are working on building a network this year, there is considerable concern over what is the right strategy. On one hand, you have users who have cheap TCP/IP bundled in with workstations and want to use it. On the other hand, you are wanting to build a network infra-structure that isn't going to hit the buffers in the next five years. This is a real problem and is actually holding back investment decisions. Perhaps such Fear Uncertainty and Doubt is one way of putting of the day when the last IP address is allocated, but not exactly an ideal solution. The indecision needs to end now, then users will have a clear idea of what the future is and how they get there. You are also claiming that OSI technologies are immature. This is a sweeping statement. There are certainly some areas on which I would agree with you, but not if you are implying CLNP. -- 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 Mar 31 21:21:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22059; Thu, 31 Mar 1994 20:16:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id UAA28926; Thu, 31 Mar 1994 20:14:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id UAA28912; Thu, 31 Mar 1994 20:09:27 +1000 Received: from ccadfa.cc.adfa.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15417; Thu, 31 Mar 1994 17:01:21 +1000 (from cjsv@ccadfa.cc.adfa.oz.au) Received: (from cjsv@localhost) by ccadfa.cc.adfa.oz.au (8.6.8/8.6.6) id RAA01938; Thu, 31 Mar 1994 17:00:46 +1000 Message-Id: <199403310700.RAA01938@ccadfa.cc.adfa.oz.au> From: Christopher.Vance@adfa.oz.au (CJS Vance) Organization: Computer Science, University College, University of New South Wales, Canberra To: Tony Li Cc: ses@tipper.oit.unc.edu, kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of Wed, 30 Mar 1994 21:44:11 -0800. <199403310544.VAA02843@lager.cisco.com> Date: Thu, 31 Mar 1994 17:00:46 +1000 Sender: cjsv@ccadfa.cc.adfa.oz.au Tony Li wrote: | If we take that definition, then it's all over already. We had a | request from a power company at the last IETF for enough address space | to number every power meter in NJ. This was some zillion addresses, | which simply weren't tractable. They probably went elsewhere. Surely RFC1597 is relevant? Or did they also want to connect to power meters in CA? -- Christopher From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 21:36:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24740; Thu, 31 Mar 1994 21:36:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA29034; Thu, 31 Mar 1994 21:34:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA29013; Thu, 31 Mar 1994 21:19:29 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24134; Thu, 31 Mar 1994 21:20:40 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa07356; 31 Mar 94 6:20 EST To: Dave Crocker Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: Minimal Changes & IPng In-Reply-To: Your message of Wed, 30 Mar 1994 13:25:47 -0800. Date: Thu, 31 Mar 1994 06:20:32 -0500 From: John Curran Message-Id: <9403310620.aa07356@nic.near.net> -------- ] From: Dave Crocker ] Subject: Re: Minimal Changes & IPng ] Date: Wed, 30 Mar 1994 13:25:47 -0800 ] ... ] There well may be ALE folks who are concerned about explosive growth from ] new sectors, but it is not represented in the ALE work. This is in spite ] of repeated efforts by random rabid folks like myself to point out the ] fallacy of a strictly historical analisys. Yet, there have been no visible ] efforts to perform what-if analysis by these folks. As noted before, IPv4 is effectively out of address space if you're trying to obtain enough addresses for an immense service in a new market sector. Hence, the specification of CLNP by EPRI and CDPD. It's quite likely that the what-if's with the largest impact are actually smaller efforts for which the remaining IPv4 space may be viable. Given that we've seen some of the larger requests, it seems quite probable that there are "smaller" services being planned which would greatly accelerate address depletion if they indeed select IPv4. /John From owner-Big-Internet@munnari.OZ.AU Thu Mar 31 21:39:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24802; Thu, 31 Mar 1994 21:39:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.5/1.0) id VAA29049; Thu, 31 Mar 1994 21:38:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.5/1.0) with SMTP id VAA29029; Thu, 31 Mar 1994 21:31:47 +1000 Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24511; Thu, 31 Mar 1994 21:32:57 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa08578; 31 Mar 94 6:32 EST To: ipng@cmf.nrl.navy.mil Cc: Big-Internet@munnari.OZ.AU Subject: Market viability for IPng Date: Thu, 31 Mar 1994 06:32:31 -0500 From: John Curran Message-Id: <9403310632.aa08578@nic.near.net> This is already submitted as an ID earlier this week, but I figured some folks wouldn't want to wait... /John p.s. Please excuse the rather rough format. --- Network Working Group J. Curran Internet draft BBN 25 March 1994 Market Viability as a IPng Criteria Status of this Memo This document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the big-internet@munnari.oz.au mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Introduction In an open marketplace, adoption of new technology is driven by consumer demand. New technologies that wish to succeed in the marketplace must provide new capabilities or reduced costs to gain consumer confidence. Internetworking technologies can be particularly difficult to deploy and must provide a correspondingly high return on investment. In order to determine market viability of new internetworking technology, it's necessary to compare the required deployment effort against the potential benefits as seen by the customer. "Viability in the Marketplace" is an important requirement for any IPng candidate and this paper is an attempt to summarize some important factors in determing market viability of IPng proposals. Curran [Page 1] Internet draft IPng White Paper on Market Viability 25 March 1994 "Pushing" Internetworking Technology It has been asserted by some that the adoption of a single IPng protocol by the computing industry would generate general acceptance in the networking industry. There is ample evidence to support this view; for example, some of the today's more prevalent networking protocols gained initial market acceptance through bundling with computer operating systems (e.g. IP via UNIX, DECNET via VMS, etc.) It should be noted, however, that this approach to technology deployment is by no means assured, and some of today's most popular internetworking software (Novell, etc.) have thrived despite alternatives bundled by computing manufacturers. Given that IPng will have to compete against an well established and mature internetworking protocol (IP version 4), promotion of an IPng solution by computer system manufacturers should be recognized as highly desirable but not sufficient on its own to ensure IPng acceptance in the marketplace. Can IPng compete against IPv4? Given the large installed base of IPv4 systems, computer system manufacturers will need to continue to provide IPv4 capabilities for the foreseeable future. With both IPng and IPv4 support in their new systems, users will be facing a difficult choice between using IPv4 and IPng for internetworking. Existing IPv4 users will migrate to IPng for one of three possible reasons: New functionality not found in IPv4 IPng needs to provide functionality equivalent to that currently provided by IPv4. It remains to be seen whether additional functionality (such as resource reservation, mobility, autoconfiguration, autoregistration, or security) will be included in the base specification of any IPng candidate. In order to provide motivation to migrate to IPng, it will be necessary for IPng proposals to offer capabilities beyond those already provided IPv4. Reduced costs by using IPng It is quite unlikely that migration to IPng will result in cost savings in any organization. Migration to IPng will certainly result in an increased need for training and engineering, and hence increased costs. To gain connectivity to otherwise unreachable IPng hosts For existing sites with valid IPv4 network assignments, connectivity is not affected until address depletion occurs. Systems with globally-unique IPv4 addresses will have complete connectivity to any systems since backwards- compatible communication is required of new IPng hosts. Curran [Page 2] Internet draft IPng White Paper on Market Viability 25 March 1994 From the perspective of an existing IPv4 site, IPng provides little tangible benefit until IPv4 address depletion occurs and organizations reachable only via IPng appear. Given the absence of benefits from migration, it is uncertain whether a significant base of IPng sites will be occur prior to IPv4 address depletion. Sites which are not yet running IP have little motivation to deploy IPng for the immediate future. As long as IPv4 network assignments are available, new sites have an choice to use IPv4 which provides the sufficient internetworking capabilities (measured in functionality, cost, and connectivity) for many organizations today. Given the parity in IPng and IPv4 capabilities, IPv4 (as a more mature internetworking protocol) is the more probable choice for organizations just now selecting an internetworking protocol. Once IPv4 address assignments are no longer available, sites wishing to participate in the global Internet will have a very difficult decision in selection of an internetworking protocol. The current suite of IPng proposals cannot provide complete internetworking between IPng-only sites and IPv4-only sites since (by definition) there will be insufficient space to map all IPng addresses into the IPv4 address space. As none of the proposals currently call for dynamic network address translation (NAT), it is inevitable that IPng-only sites will have access to a partial set of IPv4 sites at any given moment. Internetworking services which do not allow complete access to the global Internet (IPv4 and IPng in the post-IPv4-address-depletion world) are clearly not as valuable as services which offer complete Internet access. Sites which are unable to obtain IPv4 network assignments will be seeking Internet services which can provide complete Internet service. Additionally, some sites will have "privately numbered" IPv4 networks and will desire similar Internet services which provide transparent access to the entire Internet. The development of network address translation devices and subsequent services is highly likely under these market conditions. Summary No internetworking vendor (whether host, router, or service vendor) can afford to deploy and support products and services which are not desired in the marketplace. Given the potential proliferation of network address translation devices, it is not clear that IPng will secure sufficient following to attain market viability. In the past, we have seen internetworking protocols fail in the marketplace despite vendor deployment and IPng cannot succeed if it is not deployed by organizations. As currently envisioned, IPng may not be ambitious enough in the delivery of new capabilities to compete against IPv4 and the inevitable arrival of network address translation devices. In order to meet the requirement for "viability in the marketplace', IPng needs to deliver clearly improved functionality over IPv4 while offering some form transparent access between the IPv4 and IPng communities once IPv4 address depletion has occurred. Curran [Page 3] Internet draft IPng White Paper on Market Viability 25 March 1994 Author's Address John Curran BBN Technology Services, Inc. 10 Moulton Street Cambridge MA 02138 jcurran@near.net