From scoya@CNRI.Reston.VA.US Mon Jan 24 17:43:46 1994 Return-Path: scoya@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA01156 for ; Mon, 24 Jan 1994 19:25:46 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17726; 24 Jan 94 17:43 EST To: ipng@cmf.nrl.navy.mil cc: lkeiper@CNRI.Reston.VA.US Subject: IPNG Telechat schedule Date: Mon, 24 Jan 94 17:43:46 -0500 From: Steve Coya Message-ID: <9401241743.aa17726@IETF.CNRI.Reston.VA.US> Greetings, Due to the IAB Retreat and the ISOC Board of Trustee meeting the second week of February, the IPNG telechat schedule for the next few weeks is as follows: Feb 14 Feb 28 Mar 14 If needed, I can accommodate a teleconference on March 21. This is the week just before the IETF meeting in Seattle, and we'll be very busy here. But, since it's for you all :-), we can set up something if needed. I imagine the final decision will be made at the March 14 telechat. Steve From ipng-request@nic.near.net Mon Jan 24 19:38:51 1994 Return-Path: ipng-request@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA02218 for ; Mon, 24 Jan 1994 22:42:47 -0500 Received: from nic.near.net by nic.near.net id aa20024; 24 Jan 94 22:43 EST Received: from netmail2.microsoft.com by nic.near.net id aa20018; 24 Jan 94 22:43 EST Received: by netmail2.microsoft.com (5.65/25-eef) id AA02233; Mon, 24 Jan 94 19:43:00 -0800 From: jallard@microsoft.com Message-Id: <9401250343.AA02233@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 24 Jan 94 19:43:00 PST To: ipng@nic.near.net, jcurran@nic.near.net Cc: bound@zk3.dec.com Subject: Re: Interoperation, Encapsulation, Translation, and Dual Stacks Date: Mon, 24 Jan 94 19:38:51 >>Now, of course, there's a big difference between supporting two different >>application suites over two different protocol stacks (e.g. TCP over IP >>and NetWare over IPX), and supporting a single API for applications which >>works over two distinctly different network layer protocols. I would guess >>that if you already have a tightly integrated processing stack, addng a new >>network protcol would represent changes to a majority of the existing code. >>Jim, do you feel that most other vendors handle multiple protocols in the >>same manner? > >>From what I learned here is how it works: > >TCP/IP : Sockets or derivative on Servers. For PCs WINsockets. > over Netbios RFC 1001/1002 needed, >OSI: XTI or TLI (these can do TCP/IP well too). > over Netbios you need MAP/TOP interface. >Others are usually proprietary or derivations of sockets or xti in >semantics only. in windows nt, and soon in chicago (next major version of windows), we support the "windows sockets" api over multiple transports as our primary transport interface. windows sockets is a subset of the bsd stuff with some windows-centric enhancements (e.g., sock_raw and some ioctls() not supported, async notification added). under nt, we've defined an extensible mechanism by which any xport provider can leverage our sockets code by adding in a "helper DLL" (DLL==share library in windows-speak) which takes care of addressing issues and some other xport-specific stuff. in nt we ship stacks and winsock support for tcp/ip, ipx/spx, and appletalk. decnet and osi have been developed by third parties and work with windows sockets in nt as well. in chicago we will deliver tcp/ip and ipx/spx support. in the next release of nt, we'll probably add support for any netbios compatible transport in addition to what i've covered above (pls don't quote me on this)... windows sockets ("winsock") is a collaboration of over 30 vendors in an open process to define a binary compatible interface so that any winsock app can run over any winsock stack. we'll be addressing some outstanding issues starting rsn on the mailing list, including a better mechanism to handle xport independence (ala sun's netdir routines perhaps). the current spec (v1.1) can be found on file://ftp.microsoft.com/advsys/ winsock in a number of formats. for those interested i can provide the helper dll spec as well as nt centric issues like socket inheritance, etc.. as necessary. i don't know how much we want to get into api's in the ipng proposals and so forth, but we (msft) would be happy to assist the various groups to "prove" that windows sockets could handle ipng with minor modifications to the existing windows transport interface standard if you like. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 From mankin Mon Jan 24 21:08:05 1994 Return-Path: mankin Received: from radegond.cmf.nrl.navy.mil (radegond.cmf.nrl.navy.mil [134.207.7.18]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id VAA01767; Mon, 24 Jan 1994 21:07:58 -0500 From: Allison J Mankin Received: by radegond.cmf.nrl.navy.mil (4.1/client-1.3) id AA06581; Mon, 24 Jan 94 21:08:05 EST Date: Mon, 24 Jan 94 21:08:05 EST Message-Id: <9401250208.AA06581@radegond.cmf.nrl.navy.mil> To: ipng@cmf.nrl.navy.mil Subject: re: MBONE logistics Cc: mankin I have answered Paul's private mail on this. We're going to up the ttl to overcome the high threshold on the NTT link. I don't know if the link will sustain the whiteboard load, so unless we get a chance to test that, I'm not going to up the wb ttl. Allison / mankin@cmf.nrl.navy.mil From bound@zk3.dec.com Mon Jan 24 22:28:37 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA02152 for ; Mon, 24 Jan 1994 22:28:15 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA01017; Mon, 24 Jan 94 19:28:45 -0800 Received: by xirtlu.zk3.dec.com; id AA16929; Mon, 24 Jan 1994 22:28:44 -0500 Message-Id: <9401250328.AA16929@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: CLNP is it good enough for the future Date: Mon, 24 Jan 94 22:28:37 -0500 X-Mts: smtp Just a question I have been asked a few times now we should probably ask ourselves. Is CLNP good enough for the future IPng regarding new technology requirements. It is very much just like IP. /jim From bound@zk3.dec.com Mon Jan 24 22:31:15 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id WAA02161 for ; Mon, 24 Jan 1994 22:33:12 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA01206; Mon, 24 Jan 94 19:31:23 -0800 Received: by xirtlu.zk3.dec.com; id AA16982; Mon, 24 Jan 1994 22:31:22 -0500 Message-Id: <9401250331.AA16982@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: PhV as a Transition Date: Mon, 24 Jan 94 22:31:15 -0500 X-Mts: smtp Can I now ask after about 40 man hours working with our transition gurus that any comments stating PhV transition did not work that we please say where and what were the technical problems in detail. Stating that it does not work or that someone stated it broke will not help me answer the questions. thanks /jim From Robert_Ullmann.LOTUS@CRD.lotus.com Mon Jan 24 23:13:16 1994 Return-Path: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from lotus.com (lotus.com [192.233.136.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA02306 for ; Mon, 24 Jan 1994 23:07:01 -0500 From: Robert_Ullmann.LOTUS@CRD.lotus.com Received: from Mail.Lotus.com (crd.lotus.com) by lotus.com (4.1/SMI-4.1) id AA02475; Mon, 24 Jan 94 23:10:38 EST Received: by Mail.Lotus.com (4.1/SMI-4.1-DNI) id AA09609; Mon, 24 Jan 94 23:13:16 EST Date: Mon, 24 Jan 94 23:13:16 EST Message-Id: <9401250413.AA09609@Mail.Lotus.com> Received: by DniMail (v1.0); Mon Jan 24 23:13:14 1994 EDT To: unixml::"ipng@cmf.nrl.navy.mil"@lotus.com Subject: Brian's paper/Translation Brian (et al :-) In section B you state that translation is impratical, and state two reasons, each of which sharply highlight differences between IPAE and CATNIP (or TUBA); while your objections and conclusions may be true of IPAE, both TUBA and CATNIP were designed not to raise these problems. (re B1) CATNIP for example defines IPv7 to be as near as possible to being the functional equivalent of IPv4, while TUBA observes that CLNP is also (which should not surprise *anyone* familiar with the origin of CLNP :-) Please distinguish address translation from packet format translation. The former is an unmitigated disaster, while the latter is very nearly trivial (except for all the details.) No proposal is going to magically invest IPv4 with a larger address space. It may hand wave and obfuscate, but it won't actually be able to do it. The IPv4 systems will only ever be able to operate with a subset of the global network that is approximately the same size and dimensionality as the IPv4 space itself. Anything else is snake oil. (re B2) the C bit reflects an implicit premise in SIPP/IPAE that a host must know what "flavor" the remote host is. This is bogus; not only does it not need to know; we in fact do not want it to know. The only thing a host need know (and that only at the interface to the attached subnetwork) is what packet format(s) its adjacent router knows, so that the datagrams will not be lost. IMHO, the objection in B2 applies only to IPAE; to its attempt to create a mechanism (C bit) to solve a problem that doesn't exist in the first place. TUBA (and CATNIP) invoke no such mechanism. ---- In short, please separate address translation from "packet translation". They are entirely different things. With my best regards, Robert From sob@hsdndev.harvard.edu Mon Jan 24 23:25:47 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA02394 for ; Mon, 24 Jan 1994 23:24:01 -0500 Date: Mon, 24 Jan 94 23:25:47 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9401250425.AA05736@hsdndev.harvard.edu> To: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future Well, it would sorta depend on the agreed requirements I'd guess. Scott From jcurran@nic.near.net Mon Jan 24 23:34:53 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA02728 for ; Tue, 25 Jan 1994 01:00:49 -0500 Message-Id: <199401250600.BAA02728@picard.cmf.nrl.navy.mil> Received: from foo.near.net by nic.near.net id aa23285; 24 Jan 94 23:36 EST To: Robert_Ullmann.LOTUS@crd.lotus.com, Greg_Minshall@novell.com, bound@zk3.dec.com, rcallon@wellfleet.com cc: ipng@cmf.nrl.navy.mil Subject: Directions to BBN Date: Mon, 24 Jan 1994 23:34:53 -0500 From: John Curran For those folks coming to BBN tomorrow, here's directions: Follow Route 128/95 to exit 46A (Route 2 East - Cambridge/Arlington). Take Route 2 East toward Cambridge about 6 miles. The expressway portion of Route 2 ends at the Fresh Pond Parkway (Routes 2, 3, and 16). You will see the Alewife MBTA station on your right. Turn right on Fresh Pond Parkway -- southbound. Proceed down route 2 & 3 over the bridge and into the Fresh Pond Rotary. Leave the rotary at your first right (Concord Ave.). Proceed to the first set of lights and turn right onto Moulton Street. BBN is on the corner of Moulton and Concord Streets. (10 Moulton St.) Turn right into the visitor parking area and enter the building. Tell the receptionist that you're attending the "IPng Meeting". The conference starts at 12:30 EST, although we'll be ready from 11:30 onward. There will be refreshments served. /John From dino@cisco.com Mon Jan 24 20:49:32 1994 Return-Path: dino@cisco.com Received: from regal.cisco.com (regal.cisco.com [131.108.13.57]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA02469 for ; Mon, 24 Jan 1994 23:52:05 -0500 Received: by regal.cisco.com id AA24477 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Mon, 24 Jan 1994 20:49:32 -0800 Date: Mon, 24 Jan 1994 20:49:32 -0800 From: Dino Farinacci Message-Id: <199401250449.AA24477@regal.cisco.com> To: bound@zk3.dec.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com In-Reply-To: bound@zk3.dec.com's message of Sun, 23 Jan 94 15:02:10 -0500 <9401232002.AA10061@xirtlu.zk3.dec.com> Subject: Interoperation, Encapsulation, Translation, and Dual Stacks >> A misnomer I THINK (not sure) is that vendors who have OSI stacks just >> move the network layer (CLNP) and below to the IPv4 code base and fix >> the transport and BIND DNS. WRONG it won't work this way, and thats all >> I will say for now. This is all we did (cisco) to support TCP and UDP over CLNP. And it seems to be working (for almost a year now) pretty well. In fact, it turns out to be a very good managment tool for OSI networks (that is using TELNET over a CLNP based infrastructure). Dino From bound@zk3.dec.com Mon Jan 24 23:51:11 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA02475 for ; Mon, 24 Jan 1994 23:54:16 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA05628; Mon, 24 Jan 94 20:51:18 -0800 Received: by xirtlu.zk3.dec.com; id AA18026; Mon, 24 Jan 1994 23:51:17 -0500 Message-Id: <9401250451.AA18026@xirtlu.zk3.dec.com> To: Robert_Ullmann.LOTUS@CRD.lotus.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Brian's paper/Translation In-Reply-To: Your message of "Mon, 24 Jan 94 23:13:16 EST." <9401250413.AA09609@Mail.Lotus.com> Date: Mon, 24 Jan 94 23:51:11 -0500 X-Mts: smtp Rob, It does no good to call things bogus. It takes away from the effect and is not professional. Some engineers spent a lot of time on IPAE and I think we need to be gracious and professional. I never heard anyone say TP-IX or CATNIP is bogus but only praise it from all camps as a comment, you should know. >From a Bill Cosby show. A guy came to dinner with Bills daughter and he was never known by the family and they were sneaking around and hiding out. The first time they met the family was at dinner and they find out that this guy and his daughter were seeing each other behind the scenes for 6 months and trust was broken. The guy sitting at the table asks Bill gee do you all not like me. And Bill replied. Its not that. He asks the guy if I presented you with a wonderful steak dinner, baked potatoe, veggies, and a glass of fine wine with my best dinnerware you'd love it right. But if I put all that food on top of my garbage can lid and your wine in an old milk carton you may reject this great meal because of the presentation. My friend its not that we don't like you its the way you have been presented to the family. /jim From bound@zk3.dec.com Tue Jan 25 00:17:55 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA02598 for ; Tue, 25 Jan 1994 00:18:35 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA07161; Mon, 24 Jan 94 21:18:03 -0800 Received: by xirtlu.zk3.dec.com; id AA18275; Tue, 25 Jan 1994 00:18:01 -0500 Message-Id: <9401250518.AA18275@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Interoperation, Encapsulation, Translation, and Dual Stacks In-Reply-To: Your message of "Mon, 24 Jan 94 20:49:32 PST." <199401250449.AA24477@regal.cisco.com> Date: Tue, 25 Jan 94 00:17:55 -0500 X-Mts: smtp >>> A misnomer I THINK (not sure) is that vendors who have OSI stacks just >>> move the network layer (CLNP) and below to the IPv4 code base and fix >>> the transport and BIND DNS. WRONG it won't work this way, and thats all >>> I will say for now. > This is all we did (cisco) to support TCP and UDP over CLNP. And it > seems to be working (for almost a year now) pretty well. In fact, > it turns out to be a very good managment tool for OSI networks (that > is using TELNET over a CLNP based infrastructure). In this case it appears you have a true dual stack. I was speaking of Hosts but thats OK. On a Host most OSI implementations are under the AF_ISO comm domain. The IP is under the AF_INET domain. I figure the best way right now is to implement IPng under AF_INET domain where the infrastructure will change the least. Which domain is this code running under AF_INET or AF_ISO or OSI, et al? /jim From bound@zk3.dec.com Tue Jan 25 00:28:31 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-1.pa.dec.com (inet-gw-1.pa.dec.com [16.1.0.22]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA02631 for ; Tue, 25 Jan 1994 00:29:49 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/13Jan94) id AA07807; Mon, 24 Jan 94 21:28:38 -0800 Received: by xirtlu.zk3.dec.com; id AA18361; Tue, 25 Jan 1994 00:28:37 -0500 Message-Id: <9401250528.AA18361@xirtlu.zk3.dec.com> To: sob@hsdndev.harvard.edu Cc: ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-Reply-To: Your message of "Mon, 24 Jan 94 22:28:37 EST." <9401250328.AA16929@xirtlu.zk3.dec.com> Date: Tue, 25 Jan 94 00:28:31 -0500 X-Mts: smtp Scott, Well there are a few of us who feel these are requirements: 1. PMTU discovery with backwards compatibility only for fragmenation. 2. Flow IDs. 3. Multicast. 4. Continued support for Host Gateway Servers for LANs. 5. Backwards compatibility with DHCP and BOOTP. The other point is if the IETF is going to change CLNP to support the above how will this also get changed in ISO and how quick. Or will CLNP be the same at all so why call it CLNP? I am sure Host vendors will not absorb the cost to support both ISO CLNP and the associated routing and discovery protocols and an IETF IPng version of those protocols, and an old IPv4 stack. The other question asked previously applies. Would the Host vendors stop charging for CLNP if it was now IPng. I doubt it. So in addition to transition IPng will cost more maybe too. Better do something pretty good for the customers to also pay for the carrot. And this may have to be more than vanilla CLNP. /jim From dino@cisco.com Mon Jan 24 22:07:02 1994 Return-Path: dino@cisco.com Received: from regal.cisco.com (regal.cisco.com [131.108.13.57]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA02761 for ; Tue, 25 Jan 1994 01:09:20 -0500 Received: by regal.cisco.com id AA05697 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Mon, 24 Jan 1994 22:07:02 -0800 Date: Mon, 24 Jan 1994 22:07:02 -0800 From: Dino Farinacci Message-Id: <199401250607.AA05697@regal.cisco.com> To: bound@zk3.dec.com Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil In-Reply-To: bound@zk3.dec.com's message of Tue, 25 Jan 94 00:17:55 -0500 <9401250518.AA18275@xirtlu.zk3.dec.com> Subject: Interoperation, Encapsulation, Translation, and Dual Stacks >> Which domain is this code running under AF_INET or AF_ISO or OSI, et al? If your asking me this question, there is no concept of AF_*. It is a dual stack and TCP and UDP can handle variable length addresses. Dino From jcurran@nic.near.net Tue Jan 25 02:24:55 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id QAA02882 for ; Fri, 28 Jan 1994 16:34:16 -0500 Message-Id: <199401282134.QAA02882@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa10595; 25 Jan 94 2:24 EST To: bound@zk3.dec.com cc: sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-reply-to: Your message of Tue, 25 Jan 1994 00:28:31 -0500. <9401250528.AA18361@xirtlu.zk3.dec.com> Date: Tue, 25 Jan 1994 02:24:55 -0500 From: John Curran -------- CLNP addresses the immediate problem faced by IPv4 (address depletion). SIPP also addresses this immediate problem. As it turns out, we are driven to consider an IPng because of this pressing need, but the chance to deploy a new network-layer Internet protocol will only come once, so we should seriously consider exactly what additional capabilities should be included. Note that IPng is not simply about the _network_ layer, but it is about the architecture of the entire Internet service suite. This will be the only chance we have to adopt new TCP, service location, authentication, or other capabilities into the _base_ set of IPng requirements. Capabilities such as multicasting or authentication do not succeed unless the support becomes an inherent aspect of IPng. Some of these "future requirements" you've already mentioned: Flows, PMTU, multicasting, etc. There are other capabilities that you have not mentioned, which I will add: security, autoconfiguration and autoregistration, transport-layer adaptability to new network protocols, a formal service registration and location system, and more. If, when we get done, applications are still directly selecting their own port numbers and finding each other via hacks (such as "ftp.foo.com"), we will have actually failed, and the deployment of many production services on the Internet will be greatly delayed or prevented altogether. The need for common "client-server" functionality is great, and the result of not standardizing what we've learned from multiple DNS and SMTP servers is that each new application protocol (from telnet to gopher to WWW) is developing independent approaches to load leveling and redundancy. The same retracing is being done in each application protocol with respect to user authentication because of a lack of common application architecture. If we're going to tell the entire Internet applications community to "just migrate to this new address format", it would be in our best interest to provide them new interfaces to the network which result in needed capabilities being deployed. Sorry to rave, /John From jcurran@nic.near.net Tue Jan 25 02:57:14 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id GAA03560 for ; Tue, 25 Jan 1994 06:52:14 -0500 Message-Id: <199401251152.GAA03560@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa15081; 25 Jan 94 2:57 EST To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: PhV as a Transition In-reply-to: Your message of Mon, 24 Jan 1994 22:31:15 -0500. <9401250331.AA16982@xirtlu.zk3.dec.com> Date: Tue, 25 Jan 1994 02:57:14 -0500 From: John Curran -------- ] From: bound@zk3.dec.com ] Subject: PhV as a Transition ] Date: Mon, 24 Jan 94 22:31:15 -0500 ] ] Can I now ask after about 40 man hours working with our transition gurus ] that any comments stating PhV transition did not work that we please say ] where and what were the technical problems in detail. Stating that it ] does not work or that someone stated it broke will not help me answer ] the questions. The major deployment hurdle for PhaseV was the requirement to bring up _new_ software (in this case, Phase V routing) in an existing production environment (Phase IV) where both PhaseV and PhaseIV directly interacted with one another. The result of PhaseIV/PhaseV interaction was an extremely high level of coordination required for successful deployment, and elimination of the ability to safely experiment with the new protocol. My basis for this statement is discussion with the existing NEARNET base which would rather undergo a controlled transition to a totally independent protocol (IPv4) than have to debug interactions between interrelated network protocols. The fact that IPv4 does not interfere or even try to "help them" by interoperating with their PhaseIV base is a big plus in this scenario. Sorry, but this has to be said... anyone who causes two different systems to interact increases the level of knowledge required to perform problem analysis by a factor of two. Having two two _distinct_ systems allows problems to be handle by people with non-overlapping skill bases. Personally, in an age where the complexity of systems is going up dramatically, I cannot conceive of intentionally causing additional complexities and failure modes by having network protocols directly interact with one another. /John From brian@dxcoms.cern.ch Tue Jan 25 09:01:46 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA03042 for ; Tue, 25 Jan 1994 03:00:17 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA27887; Tue, 25 Jan 1994 09:01:47 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA04644; Tue, 25 Jan 1994 09:01:47 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401250801.AA04644@dxcoms.cern.ch> Subject: Yesterday's discussion in Amsterdam To: ipng@cmf.nrl.navy.mil Date: Tue, 25 Jan 1994 09:01:46 +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: 841 Just a few words on the IPng session in the RIPE meeting in Amsterdam yesterday. The audience (~50 people I guess) were essentially all from European IP operators in many countries. I gave a short intro and opened the floor, with able assistance from Daniel. It was very difficult to get people to talk about technical issues rather than process. The messages I noted were- On process: We don't believe the July 1994 date for a recommendation. Set a cutoff date for "final" proposals It is urgent to decide You can't guess the future, decide now on today's evidence On issues: A flat address space is bad. Need for extensible addresses (operators seem to feel this strongly). Allow for many local providers in one area Policy routing is key Go for simplicity Slim pickings I am afraid. Brian From francis@cactus.ntt.jp Tue Jan 25 10:04:15 1994 Return-Path: francis@cactus.ntt.jp Received: from ntt-sh.ntt.jp (nttta.NTT.JP [129.60.57.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id UAA01441 for ; Mon, 24 Jan 1994 20:00:55 -0500 Received: by ntt-sh.ntt.jp (5.59/ntt-sh-04h) with TCP; Tue, 25 Jan 94 10:01:45 JST Received: from cactus.ntt.jp by ntt-twins.ntt.jp (8.5/NTTcs02b) id KAA00487; Tue, 25 Jan 1994 10:01:43 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Tue, 25 Jan 94 10:04:15 JST Date: Tue, 25 Jan 94 10:04:15 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9401250104.AA29281@cactus.ntt.jp> To: ipng@cmf.nrl.navy.mil Subject: MBONE conference logistics Sorry to bother the whole list with this, but I wasn't sure who to talk to about it. I'm wondering if whoever is going to manage the mbone conference could set the TTL to something greater than 127. If it is 127, then every video thing will come over NTT's small (56kbps) link, and I won't be able to receive the IPng conference..... Thanks, PF From bound@zk3.dec.com Tue Jan 25 08:27:23 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA04926 for ; Tue, 25 Jan 1994 10:00:41 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA19846; Tue, 25 Jan 94 05:27:39 -0800 Received: by xirtlu.zk3.dec.com; id AA02145; Tue, 25 Jan 1994 08:27:29 -0500 Message-Id: <9401251327.AA02145@xirtlu.zk3.dec.com> To: Dino Farinacci Cc: bound@zk3.dec.com, ipng@cmf.nrl.navy.mil Subject: Re: Interoperation, Encapsulation, Translation, and Dual Stacks In-Reply-To: Your message of "Mon, 24 Jan 94 22:07:02 PST." <199401250607.AA05697@regal.cisco.com> Date: Tue, 25 Jan 94 08:27:23 -0500 X-Mts: smtp Dino, Sorry yes I was asking you. Well on a UNIX Host when you configure the network kernel (and in other OSs too) you select a commuications domain to support that infrastructure within the contextsof the operating system The BSD 4.X derivative does this by specifying a communications domain which relates directly back to the creation of a socket has the handle for the application. One of the parameters is the communications doma (e.g. AF_PUP, AF_XNS, AF_ISO,F_INET). For the Internet protocol family the comm domain is AF_INET. For products that also support an OSI stack on the Host they open the socket with AF_ISO (or the ISO family of protocols). What I am pointing to here (and this is just the beginning) is that I believe that IPng should run under the AF_INET comm domain on a Host implementation. Hence, its not a dual stack but an integrated network layer. The network layer will provide services to the transport layer (or the transport layer to the network layer) depending on whether IPng or IPv4 is being used. Its not two separate comm domains in my mind. I would not build two separate code paths to perform fragmentation and reassembly, as an example. I would have a module that checks the protocol state and make the decision in that manner (most likely based on the header of IPng or IPv4 version number). Is this clear? thanks /jim From bound@zk3.dec.com Tue Jan 25 08:47:56 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA05123 for ; Tue, 25 Jan 1994 10:23:21 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA20611; Tue, 25 Jan 94 05:48:04 -0800 Received: by xirtlu.zk3.dec.com; id AA02819; Tue, 25 Jan 1994 08:48:02 -0500 Message-Id: <9401251348.AA02819@xirtlu.zk3.dec.com> To: John Curran Cc: bound@zk3.dec.com, sob@hsdndev.harvard.edu, ipng@cmf.nrl.navy.mil Subject: Re: CLNP is it good enough for the future In-Reply-To: Your message of "Tue, 25 Jan 94 02:24:55 EST." <9401251236.AA07509@decvax.dec.com> Date: Tue, 25 Jan 94 08:47:56 -0500 X-Mts: smtp John, Just want to reinforce your comments on ports. >If, when we get done, applications are still directly selecting their >own port numbers and finding each other via hacks (such as "ftp.foo.com"), >we will have actually failed, and the deployment of many production services >on the Internet will be greatly delayed or prevented altogether. The need >for common "client-server" functionality is great, and the result of not >standardizing what we've learned from multiple DNS and SMTP servers is that >each new application protocol (from telnet to gopher to WWW) is developing >independent approaches to load leveling and redundancy. The same retracing >is being done in each application protocol with respect to user authentication >because of a lack of common application architecture. I have wracked my brain on avoiding ports and even looked at TP4 but its the model. Each time I come up with a solution it won't work. But I would like this to be dynamic. Another reason is a busines capitalistic reason (being a die hard anti-socialist) in that if I build a great client/server application on the street as a small business person. I don't like the idea of having to ask for a port assignment from some authority. On all your points I want to say I completely agree with all the statements at my end. Lets get ready for the future. /jim From brian@dxcoms.cern.ch Tue Jan 25 16:14:00 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA05016 for ; Tue, 25 Jan 1994 10:12:30 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA20863; Tue, 25 Jan 1994 16:14:00 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA28413; Tue, 25 Jan 1994 16:14:00 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401251514.AA28413@dxcoms.cern.ch> Subject: Re: what do you all think? To: ipng@cmf.nrl.navy.mil Date: Tue, 25 Jan 1994 16:14:00 +0100 (MET) In-Reply-To: <9401242106.AA16247@cabernet.wellfleet> from "Ross Callon" at Jan 24, 94 04:06:58 pm 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: 761 >--------- Text sent by Ross Callon follows: > > > > > Is everybody aware that somebody just submitted a paper to the ATM > Forum saying that a new bulk transport protocol is needed for ATM, > since TCP and XTP are known to be no good? I didn't read the paper > in detail, but I diagreed strongly with what I did read. I can't > cc it because ATM Forum papers are limited to Forum members. > > I noticed that it had been submitted, but was too busy last week to > look at it. Do you have the contribution number? (I have a complete > stack of the contributions to last week's ATM forum in hardcopy, I > deleted the on-line copies). > Sorry, deleted mine too. There is an ftp archive somewhere. The origin was in Canada (the Post Office?) Brian From brian@dxcoms.cern.ch Tue Jan 25 16:28:53 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA05160 for ; Tue, 25 Jan 1994 10:27:21 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22805; Tue, 25 Jan 1994 16:28:53 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29156; Tue, 25 Jan 1994 16:28:53 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401251528.AA29156@dxcoms.cern.ch> Subject: Re: PhV as a Transition To: ipng@cmf.nrl.navy.mil Date: Tue, 25 Jan 1994 16:28:53 +0100 (MET) In-Reply-To: <199401251152.GAA03560@picard.cmf.nrl.navy.mil> from "John Curran" at Jan 25, 94 02:57:14 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: 2654 >--------- Text sent by John Curran follows: > > -------- > ] From: bound@zk3.dec.com > ] Subject: PhV as a Transition > ] Date: Mon, 24 Jan 94 22:31:15 -0500 > ] > ] Can I now ask after about 40 man hours working with our transition gurus > ] that any comments stating PhV transition did not work that we please say > ] where and what were the technical problems in detail. Stating that it > ] does not work or that someone stated it broke will not help me answer > ] the questions. > > The major deployment hurdle for PhaseV was the requirement to bring up > _new_ software (in this case, Phase V routing) in an existing production > environment (Phase IV) where both PhaseV and PhaseIV directly interacted > with one another. > In the European HEP DECnet transition we ran Phase V routing on separate routers and separate circuits for a looong time, until we were confident. Then we migrated our backbone routes and routers, over a few very intense days. Then we started migrating on-site routing for the sites that wanted to do it. When it becomes the right time, we will migrate hosts, but this comes last. > The result of PhaseIV/PhaseV interaction was an extremely high level of > coordination required for successful deployment, Yes! > and elimination of the > ability to safely experiment with the new protocol. No, not if you are prepared to dedicate some routers and circuits to experimentation. > My basis for this > statement is discussion with the existing NEARNET base which would rather > undergo a controlled transition to a totally independent protocol (IPv4) > than have to debug interactions between interrelated network protocols. > The fact that IPv4 does not interfere or even try to "help them" by > interoperating with their PhaseIV base is a big plus in this scenario. > We have not seen this in Euro HEP DECnet. (But we have seen a massive move into IP, mainly triggered by Unix growth.) > Sorry, but this has to be said... anyone who causes two different systems > to interact increases the level of knowledge required to perform problem > analysis by a factor of two. I think this is the basis of my anti-translation bias. But (crash helmet on) the DECnet inter-phase routing translation does not depend on a magic C-bit in the address. > Having two two _distinct_ systems allows > problems to be handle by people with non-overlapping skill bases. Personally, > in an age where the complexity of systems is going up dramatically, I cannot > conceive of intentionally causing additional complexities and failure modes > by having network protocols directly interact with one another. > > /John > Brian From jcurran@nic.near.net Tue Jan 25 11:08:32 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA05582 for ; Tue, 25 Jan 1994 11:07:00 -0500 Message-Id: <199401251607.LAA05582@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa11258; 25 Jan 94 11:08 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: PhV as a Transition In-reply-to: Your message of Tue, 25 Jan 1994 16:28:53 +0100. <9401251528.AA29156@dxcoms.cern.ch> Date: Tue, 25 Jan 1994 11:08:32 -0500 From: John Curran -------- ] From: Brian Carpenter CERN-CN ] Subject: Re: PhV as a Transition ] Date: Tue, 25 Jan 1994 16:28:53 +0100 (MET) ] ... ] > The result of PhaseIV/PhaseV interaction was an extremely high level of ] > coordination required for successful deployment, ] ] Yes! ] ] > and elimination of the ] > ability to safely experiment with the new protocol. ] ] No, not if you are prepared to dedicate some routers and circuits ] to experimentation. Ah... I agree. (Some deployment problems can be resolved through the application of sufficient funds.) Mind you, I'm not certain that the average 4 node corporate LAN is going to be happy about establishing a "Transition testing center" so that they can safely migrate. /John From brian@dxcoms.cern.ch Tue Jan 25 17:52:45 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA06116 for ; Tue, 25 Jan 1994 11:51:28 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA12139; Tue, 25 Jan 1994 17:52:47 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03907; Tue, 25 Jan 1994 17:52:46 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401251652.AA03907@dxcoms.cern.ch> Subject: EWOS To: ipng@cmf.nrl.navy.mil, vcerf@cnri.reston.va.us (Vint Cerf) Date: Tue, 25 Jan 1994 17:52:45 +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: 667 IPng Directorate, and Vint, Following the FIRP discussion in the last IPng telechat, I took the initiative of contacting the chair of the EWOS steering committee. [EWOS = European Workshop on Open Systems, which has European Union support.] He is Paul Van Binst who happens to be an ex-physicist. It turns out he will be at CERN this Thursday for another meeting, so I will have a short discussion with him. Unless anybody tells me to stop, I will suggest to him that a recognition by EWOS of the value of the Internet suite as an open protocol suite would be in everybody's interests and would take some of the political aspects out of the IPng process. Brian From deering@parc.xerox.com Tue Jan 25 09:35:46 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA06695 for ; Tue, 25 Jan 1994 12:34:46 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14977(6)>; Tue, 25 Jan 1994 09:36:13 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 25 Jan 1994 09:36:01 -0800 To: Robert_Ullmann.LOTUS@crd.lotus.com Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: Brian's paper/Translation In-reply-to: Robert_Ullmann.LOTUS's message of Mon, 24 Jan 94 20:13:16 -0800. <9401250413.AA09609@Mail.Lotus.com> Date: Tue, 25 Jan 1994 09:35:46 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan25.093601pst.12171@skylark.parc.xerox.com> > No proposal is going to magically invest IPv4 with a larger > address space. It may hand wave and obfuscate, but it won't > actually be able to do it. The IPv4 systems will only ever be > able to operate with a subset of the global network that is > approximately the same size and dimensionality as the > IPv4 space itself. Anything else is snake oil. That's precious: Robert "we-don't-need-no-steenkin'-transition-plan" Ullman accusing someone *else* of being a snake oil salesman! Just for the record: the IPAE folks have never claimed any of the magical powers that are implied by the above passage. We've always said that IPAE will allow a SIP[P] system to communicate with an IPv4 system anywhere in the Internet *until* the IPv4 address space effectively runs out. After that, a SIP[P] system will be able to communicate indefinitely with IPv4 systems within a sub-region of the Internet in which IPv4 addresses can still be guaranteed unique. If you can produce evidence that any of the IPAE developers have ever claimed otherwise, please produce it; otherwise, please curb your insults. Steve From jcurran@nic.near.net Wed Jan 26 01:40:09 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id BAA12059 for ; Wed, 26 Jan 1994 01:38:41 -0500 Message-Id: <199401260638.BAA12059@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa20523; 26 Jan 94 1:40 EST To: Steve Deering cc: Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Tue, 25 Jan 1994 09:35:46 -0800. <94Jan25.093601pst.12171@skylark.parc.xerox.com> Date: Wed, 26 Jan 1994 01:40:09 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Brian's paper/Translation ] Date: Tue, 25 Jan 1994 09:35:46 PST ] ... ] Just for the record: the IPAE folks have never claimed any of the magical ] powers that are implied by the above passage. We've always said that IPAE ] will allow a SIP[P] system to communicate with an IPv4 system anywhere in ] the Internet *until* the IPv4 address space effectively runs out. ] ] After that, a SIP[P] system will be able to communicate indefinitely with ] IPv4 systems within a sub-region of the Internet in which IPv4 addresses can ] still be guaranteed unique. If you can produce evidence that any of the ] IPAE developers have ever claimed otherwise, please produce it; otherwise, ] please curb your insults. Aside from tone, I pretty much agree with Steve D. on this... I don't know any IPAE developers who have misrepresented IPAE. A few may have gotten "caught up in spirit" of IPAE, and overstated its potential for usefulness, but that's generally been the result of different base assumptions rather than anything intentional. I would like to raise a very delicate subject with the IPng directorate regarding our current IPng proposals. Several of my basic assumptions regarding IPng requirements have changed over the past 18 months, and I suspect that the same has occured for other directorate members. I'd like to briefly discuss the underlying assumptions that we're all using for IPng development, on the presumption that some of us now have different IPng assumptions than when we started, and we would (I postulate) design a rather different IPng solution if we were to start over today. Here's some of my recently acquired wisdom: 1. Hierarchical prefix-based routing with aggregation (as recommended in CIDR, SIPP, and TUBA) has the potential for routing scaling if adaquate backpressure mechanisms exist. As a result of CIDR, IPng does not have to "solve" the routing scaling problem for IPv4. 2. IPng has only one absolute requirement: Dramatically increase the address space of IP without sacrificing existing IPv4 functionality. In particular, IPng must include multicasting capabilities just as IPv4. 3. IPng systems deployed during the period of time when IPv4 addresses are available _must_ be able to interoperate with the existing IPv4 base. Once IPv4 addresses are no longer available, it is desirable (but not required) to allow interoperability between new IPng systems and IPv4. 4. IPng must provide additional functionality in the base software to be considered by the marketplace. Autoconfiguration, flow identifiers, mobility and provider selection are _some_ desirable features for IPng base software. 5. IPng performance should be comparable IPv4 performance. 6. The IETF must control the future evolution of IPng. Does anyone have any serious concerns about these generalizations? I don't believe that they're particularly contentious, but some of the implications are rather interesting: o CLNP, "out of the box", _must_ be modified to meet IPng requirements. (At a minimum, it needs multicasting and IPv4 interoperability specs.) Additionally, IPng could be _based upon_ CLNP, it cannot not _be_ CLNP until IETF change control is assured. o The network address length issue which was debated at length at the beginning of the IPng development has turned into a non-issue; SIPP has 64, 128, 192, etc. bit lengths, whereas CLNP has 160, 168, etc. bit lengths. Presumably, the additional bits (when needed) do not represent an unreasonable performance burden. Likewise, the cost of variable length addressing is not actually a performance burden. o IPAE was designed originally as a method for improving route scaling and providing IPng-IPv4 interoperability within IPv4 commonwealths. Given that hierarchical prefix-based aggregation resolves the routing scaling issue, IPAE's signficant difference over other transition schemes remains its ability to support multiple IPv4 uniqueness regions once IPv4 addresses are no longer globally unique. o Interoperability between IPng and IPv4 either involves dual-stacks on the the IPng systems or requires some form of translation. The translation can occur in the IPng systems (i.e. "Internet Protocol address extensions") or can be done via a seperate translation unit which performs the function. o Some common technologies (such as an active "ES-IS"-like protocol for end system interaction, and an SPF protocol for intra-AS routing) were adopted by both TUBA and SIPP as the right way to handle particular problem spaces. Given the above observations, I cannot help but think that there is much more common ground between the various proposals than previously believed. If the goal of the IETF is to produce the _best_ internetworking standards possible, we may be doing a disservice by accepting any of the IPng proposals before us. /John From jcurran@nic.near.net Wed Jan 26 03:52:22 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA12460 for ; Wed, 26 Jan 1994 03:50:41 -0500 Message-Id: <199401260850.DAA12460@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa01578; 26 Jan 94 3:52 EST To: Paul Francis cc: deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Wed, 26 Jan 1994 16:08:53 +0200. <9401260708.AA09457@cactus.ntt.jp> Date: Wed, 26 Jan 1994 03:52:22 -0500 From: John Curran -------- ] From: Paul Francis ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Wed, 26 Jan 94 16:08:53 JST ] ... ] I think the goal of the IETF is to produce the best internetworking standards ] possible in a very short time frame--in other words, the goal is *not* to ] produce the best internetworking standards possible, but to produce a good ] one, and soon. ] ... ] Whatever IPng is chosen, it is going to evolve, probably a lot at first ] as it gets nailed down and built, and perhaps less fast over time. ] Therefore, we should make our decision now, based on fairly high-level ] criteria (design, architecture, functionality, standards process, etc.), ] and sweat the details in the usual way (by building it.....) Do you feel that we can make a decision between the proposals based on high-level criteria?? At a high level, all of the proposals look viable to me, and yet the problems are present. If the goal of deciding is to close down work on the other IPng proposals, then I'm dead against it until we're all confortable that the chosen IPng will actually work. I believe that we need to move quickly on IPng. I do not think we can just "make a decision" until we've gotten feedback from limited deployment, as I have serious doubts about the ability to deploy the current proposals. Dual-stack deployment _cannot_ work in some circumstances (once IPv4 addresses are not readily available, sites will be unable to deploy new systems which can communicate with important IPv4 legacy systems, due to lack of a IPv4 address). Thanks to the directorate for reminding me about glacial equipment replacement schedules. IPAE's mapping tables are simply inconceivable from an operational viewpoint and the odds of all border routers being correctly configured in the 100 or so world-wide providers is nil. The described mechanism for table distribution (ftp) does not meet the needs of Internet operation, and folks familiar with the current failure of keeping the 7 root DNS servers in sync via FTP would not advocate attempting to keep several hundred router under different authorities up to date with this mechanism. The addition of new sites to the Internet will require a level of coordination which simply cannot be obtained. When there are problems, the problem determination process for SIP/IPAE/IPv4 is so complicated that I do not expect most IETF members to diagnose their own difficulties. (The IETF terminal room should become quite entertaining.) If this group needs to make a quick decision, let it be NAT. /John p.s. I'm actually quite pleased with the IPng working group output, and as my last message indicates, I feel that a great deal of consensus was actually reached without anyone noticing. (so much consensus, that it may be possible to define an IPng proposal which looks like SIP, has variable CLNPish addressing made up of little 16-bit elements with PIP-like processing, and local IPAE-like IPv4->IPng translation for new IPng-only hosts communicating with local legacy IPv4 systems; IPng/IPv4 dual for those IPng hosts that speak IPv4 to the IPv4 Internet.) From vcerf@CNRI.Reston.VA.US Wed Jan 26 05:31:16 1994 Return-Path: vcerf@CNRI.Reston.VA.US Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us [132.151.1.35]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id FAA12745 for ; Wed, 26 Jan 1994 05:31:45 -0500 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa01806; 26 Jan 94 5:31 EST To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: EWOS In-reply-to: Your message of "Tue, 25 Jan 94 17:52:45 +0100." <9401251652.AA03907@dxcoms.cern.ch> Date: Wed, 26 Jan 94 05:31:16 -0500 From: "Vinton G. Cerf" Message-ID: <9401260531.aa01806@IETF.CNRI.Reston.VA.US> Brian, it would certainly be helpful if EWOS were to take the view that a broader range of options would be practical for many network users. I haven't followed closely the scope of EWOS efforts in the recent past although its counterpart here in the US (OIW) has recently seemed to re-examine its charter with an eye to expanding on the meaning of "Open Systems." If the EWOS community is still largely focused on getting the OSI protocol suite whipped into shape, you may find it a difficult matter to broaden their charter, but I am sure all of us will be interested to learn how your discussion goes. vint From francis@cactus.ntt.jp Wed Jan 26 16:08:53 1994 Return-Path: francis@cactus.ntt.jp Received: from koudai.cs.titech.ac.jp (koudai.cs.titech.ac.jp [131.112.176.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with ESMTP id CAA12241 for ; Wed, 26 Jan 1994 02:28:21 -0500 Received: by koudai.cs.titech.ac.jp (2.3W/koudai); Wed, 26 Jan 1994 16:29:33 +0900 Received: by lab.ntt.jp (8.6.4/GATENTTMX0.91); Wed, 26 Jan 1994 16:06:23 +0900 Received: from cactus.ntt.jp by ntt-twins.ntt.jp (8.5/NTTcs02b) id QAA13237; Wed, 26 Jan 1994 16:06:21 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Wed, 26 Jan 94 16:08:53 JST Date: Wed, 26 Jan 94 16:08:53 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9401260708.AA09457@cactus.ntt.jp> To: deering@parc.xerox.com, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil I could hardly agree more with John's statements.... (Hmmmm, I wonder if that question will be hard to parse by my Japanese colleagues.....) > If the goal of the IETF is to produce the _best_ internetworking standards > possible, we may be doing a disservice by accepting any of the IPng proposals > before us. I think the goal of the IETF is to produce the best internetworking standards possible in a very short time frame--in other words, the goal is *not* to produce the best internetworking standards possible, but to produce a good one, and soon. Also, I meant to reply to Brian Carpenter's summary of the IPng portion of the RIPE meeting. At the end, he said the points were "slim pickings", but I thought that an incredibly important point was made. That is, that the IETF has all the information it needs to make a decision *now* (or, put another way, waiting 6 months or 1 year or 2 years isn't going to give them/us qualitatively more information with which to make a decision). Whatever IPng is chosen, it is going to evolve, probably a lot at first as it gets nailed down and built, and perhaps less fast over time. Therefore, we should make our decision now, based on fairly high-level criteria (design, architecture, functionality, standards process, etc.), and sweat the details in the usual way (by building it.....) (I also found the last two items Brian listed as ironic. They were, to the best of my memory, that decent policy routing is very important, and that simplicity is key.....we all would like to have our tofu and eat it too.....) Cheers, PF From brian@dxcoms.cern.ch Wed Jan 26 16:51:37 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA14559 for ; Wed, 26 Jan 1994 10:49:59 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03058; Wed, 26 Jan 1994 16:51:38 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09114; Wed, 26 Jan 1994 16:51:37 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401261551.AA09114@dxcoms.cern.ch> Subject: Some IPng input To: ipng@cmf.nrl.navy.mil Date: Wed, 26 Jan 1994 16:51:37 +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: 2184 I solicited IPng input from the European HEPnet committees but so far I have had no collective response. I did receive the attached personal comment from the chair of the HEPnet Requirements Committee. He makes a specific request for more fine-grained support for policy routing and another for better multicast support. [He actually says there is no multicast support today: not strictly true of course, but not far from the truth as a user perception of the MBONE.] Brian >--------- Text sent by J. F. RENARDY follows: > From renardy@dphvx2.saclay.cea.fr Fri Jan 7 17:47:40 1994 > X-Delivered: at request of brian on dxcoms.cern.ch > X-Rerouted-To: Brian@dxcoms.cern.ch by the CERN Automatic Mail Router (v.2.0, July 1993). > X400-Received: by /PRMD=inria/ADMD=atlas/C=FR/; > Relayed; 07 Jan 94 17:47:21+0100 > X400-Received: by /PRMD=cea/ADMD=atlas/C=FR/; > Relayed; 07 Jan 94 17:47:13+0100 > Date: 07 Jan 94 17:47:13+0100 > From: J. F. RENARDY > Message-Id: <9401071647.AA09716@hep.saclay.cea.fr> > To: @hx > Cc: RENARDY@dphdsi.saclay.cea.fr > Subject: IPng suggestion > > IETF IP: next generation area > > > (This is a personal view of the > question and not an official > position of the HRC) > > > The proposals for the next generation > of IP mostly concern features where > HEP is not seriously disturbed by the > current state (i.e. address space, > support for mobile users, security...) > > I see two areas where HEP may have > specific requests: > 1- Support for group policy. > In the current internet, each autonomous > system has its own policy, but only one. > HEP sites are usualy subset of autonomous > systems, so it is impossible to define > an "HEPnet policy". A new version of IP > with support for specific policy at a > level below the current autonomous system > will be usefull for HEP. > 2- Support for work group. > The current IP has no support for > multicast. An efficient multicast suuport > will allow HEP to implement distributed > video-conferences, to perform efficiently > distributed software development, to > access centralized data bases... > > J.F.R. > > From ericf@atc.boeing.com Wed Jan 26 08:52:48 1994 Return-Path: ericf@atc.boeing.com Received: from atc.boeing.com (atc.boeing.com [130.42.28.80]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA15061 for ; Wed, 26 Jan 1994 11:50:03 -0500 Received: by atc.boeing.com (5.57) id AA15307; Wed, 26 Jan 94 08:52:48 -0800 Date: Wed, 26 Jan 94 08:52:48 -0800 From: Eric Fleischman Message-Id: <9401261652.AA15307@atc.boeing.com> To: francis@cactus.ntt.jp, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: Robert_Ullmann.LOTUS@crd.lotus.com, deering@parc.xerox.com, ipng@cmf.nrl.navy.mil Dear Group, I appreciate the dialog between Paul and Dave. I like the theme of proposing a master solution not in the current solution set. However, I doubt its practicality unless a merger (e.g., like IPAE + SIP and then like PIP and SIP) occurs. Yet is this necessarily wise? John's last comment about being sure that the identified solution must work is the key point I wish to highlight. John's concluding statement that the best solution of all would probably be NAT is almost right: in my perspective the best solution of all would be application layer gateways at the security island coupled with local addressing. Of course, neither of these options could stand should our computing algorithm (toasternet) radically shift as predicted by Dave Crocker. For example, if one assumes ubiquitous personal data/ voice devices like Dick Tracy's wrist-watch (except with computer like functions as well) then we would perhaps have several tens of millions of new mobile devices whose addressing really doesn't have the concept of a "network number" imbedded within it (i.e., what network number would these use since each would be unique to that person with no obvious hierarchical element joining them all). Thus, what I'm saying is that my proposed "ideal" solution (above) is too myopic to be viable long-term. Thus, I've now come full circle. I therefore propose that until we have bona fide requirements we can not decide on an IPng and we can not identify the solution. Our requirements identification is occurring far too late in the process. I propose that the IPng Directorate expeditiously propose recommended requirements during February and then have the Requirements WG tune and modify them at the Seattle IETF. The WG results then would be evaluated by the IPng Directorate in April and potentially messaged. The result will then be decreed to be the IPng requirements. In any case, we can not afford to proceed without requirements and we need them now. Sincerely yours, --Eric Fleischman From dino@cisco.com Wed Jan 26 09:50:50 1994 Return-Path: dino@cisco.com Received: from regal.cisco.com (regal.cisco.com [131.108.13.57]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA00329 for ; Wed, 26 Jan 1994 13:59:31 -0500 Received: by regal.cisco.com id AA15343 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Wed, 26 Jan 1994 09:50:50 -0800 Date: Wed, 26 Jan 1994 09:50:50 -0800 From: Dino Farinacci Message-Id: <199401261750.AA15343@regal.cisco.com> To: jcurran@nic.near.net Cc: francis@cactus.ntt.jp, deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil In-Reply-To: John Curran's message of Wed, 26 Jan 1994 03:52:22 -0500 <199401260850.DAA12460@picard.cmf.nrl.navy.mil> Subject: Proposal history (was: Re: Brian's paper/Translation) >> p.s. I'm actually quite pleased with the IPng working group output, >> and as my last message indicates, I feel that a great deal >> of consensus was actually reached without anyone noticing. >> (so much consensus, that it may be possible to define an IPng >> proposal which looks like SIP, has variable CLNPish addressing >> made up of little 16-bit elements with PIP-like processing, and >> local IPAE-like IPv4->IPng translation for new IPng-only hosts >> communicating with local legacy IPv4 systems; IPng/IPv4 dual >> for those IPng hosts that speak IPv4 to the IPv4 Internet.) This sounds vaguely familiar to how ISO defined the network layer, trying to make all camps happy. This will definitely lead to major interoperability problems. We need to define a single protocol/architecture that has the above features, and is required day-1 to implement all the features, there are no optional options. SIPP is taking this stance with respect to Routing Header. I think this is a very important mandate. Dino From bound@zk3.dec.com Wed Jan 26 13:52:31 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA00480 for ; Wed, 26 Jan 1994 14:13:15 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA03262; Wed, 26 Jan 94 10:52:38 -0800 Received: by xirtlu.zk3.dec.com; id AA12710; Wed, 26 Jan 1994 13:52:37 -0500 Message-Id: <9401261852.AA12710@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: Response to John C. and Eric F. mail on Ipng Date: Wed, 26 Jan 94 13:52:31 -0500 X-Mts: smtp I completely agree with John's assesment and we really have much consensus in the consciousness of our group. I also agree with Eric that we need to move into the requirements now. I would like to ask the Directorate two things: 1. When we make a decision or recommend a master solution with detailed plans, then we need to be very careful that time is given to complete all the needed specs. And make it clear to the market IPng has been selected but not ready to be deployed per the IETF. Comments welcome ... 2. I think we need to make IPng better than IPv4 datagram regarding functionality. We need to have new pieces as John pointed out. thanks /jim From jcurran@nic.near.net Wed Jan 26 13:55:32 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id NAA00276 for ; Wed, 26 Jan 1994 13:54:31 -0500 Message-Id: <199401261854.NAA00276@picard.cmf.nrl.navy.mil> Received: from platinum.near.net by nic.near.net id aa27865; 26 Jan 94 13:56 EST To: Dino Farinacci cc: francis@cactus.ntt.jp, deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Wed, 26 Jan 1994 09:50:50 -0800. <199401261750.AA15343@regal.cisco.com> Date: Wed, 26 Jan 1994 13:55:32 -0500 From: John Curran -------- ] From: Dino Farinacci ] Subject: Proposal history (was: Re: Brian's paper/Translation) ] Date: Wed, 26 Jan 1994 09:50:50 -0800 ] ] This sounds vaguely familiar to how ISO defined the network layer, trying ] to make all camps happy. This will definitely lead to major ] interoperability problems. ] ] We need to define a single protocol/architecture that has the above ] features, and is required day-1 to implement all the features, there ] are no optional options. SIPP is taking this stance with respect to ] Routing Header. I think this is a very important mandate. Hold on... I'm not advocating multiple methods for accomplishing the same goal (i.e. the CONS/CLNP problem); I also believe we need a _single_ architecture to satisfy IPng requirements. I just don't happen to believe that any of the proposals on the table are going to satisfy the requirements until such time as the working groups express a willingness to do the best protocol possible, regardless of previous political or personal investments. SIPP's approach to the straightening out the routing header is a great idea; it might be better if we actually designed for the future without IPv4 header legacy. SIP started as close to IPv4 as possible (quite a reasonable starting point) but now that variable length addresses have actually become accepted, simply retrofitting them into SIP via a routing option may not yield the same results as if the WG had used variable length addressing as an initial condition. Forwarding across SIP extended address spaces requires a circular rewrite to get the next address element into the header, and this is not going to pipeline easily in anyone's hardware. TUBA has also gone through some learning experiences, and several of the early decisions were based entirely on the assumption that CLNP could not/ should not be changed to make TUBA a success. At this point, it's recognized that CLNP must be changed to add multicasting, perhaps some flows, etc. TUBA could easily become a more capable proposal, complete with IPv4 address mapping, if one were to revisit the past decisions in the current light. Dino, I'm not advocating merger-mania... I'm calling for reconsideration of the current assumptions behind the proposals. We're going to have to live with IPng output for a century or more; I have no qualms about asking for technical review of the decisions made. This is particularly true when the the proposals have basic transition and/or operational flaws. Again: the proposals on the table have each solved pieces of the problem, and if there is not a willingness on the working groups to test basic assumptions and potentially learn from the other work, we might as well disband now. Paul Francis indicated that we should decide on a proposal, and then refine as needed. I ask that the directorate members put aside their differences and go through the exercise of constructively improving each others work _before_ we do anything as rash as selecting one particular approach to the problem. John "All I have to do is support this fine technology for a living" Curran From smb@research.att.com Wed Jan 26 14:23:38 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA00578 for ; Wed, 26 Jan 1994 14:23:10 -0500 From: smb@research.att.com Message-Id: <199401261923.OAA00578@picard.cmf.nrl.navy.mil> Received: by gryphon; Wed Jan 26 14:23:39 EST 1994 To: ipng@cmf.nrl.navy.mil Subject: Path MTU Date: Wed, 26 Jan 94 14:23:38 EST A number of recent messages have indicated that support for Path MTU is necessary. At the risk of sounding like a heretic, I'm not even convinced that it's a good idea, let alone necessary. The problem with Path MTU is that the current Internet relies on routers that are store-and-forward on a per-packet basis. Given the number of hops a packet typically makes on a long-haul net, and given the comparatively small window sizes, there's a significant amount of starvation due to TCP window size exhaustion. With smaller packets, each router has less waiting time before it can resend the packet; the net effect is that each link can be kept busy, and some data will arrive promptly. To make things quantitative, at DS1 speeds a 1500 byte packet takes about 7.7 milliseconds to be received. If the receiving host uses 8K byte windows, which are hardly atypical, only 5 and a fraction packets can be outstanding at any one time. Each router will take those 7.7 ms to send each packet; if there are more than 6 hops, the sending host will be idle till 7.7ms times the number of hops goes by, and the ack comes back the same number of hops. If smaller packets were used, the 7.7ms multiplier will be much reduced. Based on my comments, Rich Stevens wrote up a much clearer explanation of this phenomenon in his new book ``TCP/IP Illustrated''. Now -- bulk transfer protocols might use great gronking huge windows, and really be able to take advantage of every small increment in throughput from fewer instances of per-packet overhead. But a lot of the other traffic -- mail, ftp, etc. -- is in messages too short for that to matter much. I've done a few tests, btw, that seemed to demonstrate this effect in practice, not theory. The tests involved ttcp over a frame relay link running at DS1 speeds. Cutting the MTU increased througput. (On the other hand, Jeff Mogul thinks I was seeing an artifact of the ACK scheduling in SunOS. One of these days, I'll find or build a TCP simulator.) --Steve Bellovin From dino@cisco.com Wed Jan 26 11:26:19 1994 Return-Path: dino@cisco.com Received: from regal.cisco.com (regal.cisco.com [131.108.13.57]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id OAA00591 for ; Wed, 26 Jan 1994 14:24:43 -0500 Received: by regal.cisco.com id AA27458 (5.67a/IDA-1.5 for ipng@cmf.nrl.navy.mil); Wed, 26 Jan 1994 11:26:19 -0800 Date: Wed, 26 Jan 1994 11:26:19 -0800 From: Dino Farinacci Message-Id: <199401261926.AA27458@regal.cisco.com> To: jcurran@nic.near.net Cc: francis@cactus.ntt.jp, deering@parc.xerox.com, Robert_Ullmann.LOTUS@crd.lotus.com, ipng@cmf.nrl.navy.mil In-Reply-To: John Curran's message of Wed, 26 Jan 1994 13:55:32 -0500 <199401261856.AA28024@hubbub.cisco.com> Subject: Proposal history (was: Re: Brian's paper/Translation) >> SIPP's approach to the straightening out the routing header is a great idea; >> it might be better if we actually designed for the future without IPv4 header >> legacy. SIP started as close to IPv4 as possible (quite a reasonable starting >> point) but now that variable length addresses have actually become accepted, >> simply retrofitting them into SIP via a routing option may not yield the same >> results as if the WG had used variable length addressing as an initial >> condition. Forwarding across SIP extended address spaces requires a circular >> rewrite to get the next address element into the header, and this is not going >> to pipeline easily in anyone's hardware. I don't believe variable length addresses have actually become accepted. Yes, the Routing Header is a great idea, however I was commenting on the mandatory implementation of it. We don't want to fall into the IPv4 trap, that everyone can do option processing at an order of magnitude slower than a packet without options. >> Dino, I'm not advocating merger-mania... I'm calling for reconsideration of >> the current assumptions behind the proposals. We're going to have to live >> with IPng output for a century or more; I have no qualms about asking for >> technical review of the decisions made. This is particularly true when the >> the proposals have basic transition and/or operational flaws. Good, I just wanted to make it clear to the list that you were not making minestrone and mixing it with my recipe for minestrone. >> Again: the proposals on the table have each solved pieces of the problem, >> and if there is not a willingness on the working groups to test basic >> assumptions and potentially learn from the other work, we might as well >> disband now. Paul Francis indicated that we should decide on a proposal, >> and then refine as needed. I ask that the directorate members put aside >> their differences and go through the exercise of constructively improving >> each others work _before_ we do anything as rash as selecting one particular >> approach to the problem. So, do we start a new working group to build a single and final IPng proposal. The working group satisfies all requirements that this directorate puts forth and takes ideas from SIP/IPAE/PIP/TUBA/CATNIP/IPv4. >> John "All I have to do is support this fine technology for a living" Curran And so will your kids. Let's leave them something to be proud of. Soups up, Dino From rcallon@wellfleet.com Wed Jan 26 19:39:49 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA01142 for ; Wed, 26 Jan 1994 19:33:19 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03499; Wed, 26 Jan 94 19:20:26 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA14902; Wed, 26 Jan 94 19:29:58 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA17418; Wed, 26 Jan 94 19:39:49 EST Date: Wed, 26 Jan 94 19:39:49 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401270039.AA17418@cabernet.wellfleet> To: jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: ipng@cmf.nrl.navy.mil .... If the goal of deciding is to close down work on the other IPng proposals, then I'm dead against it until we're all comfortable that the chosen IPng will actually work. I agree with this. I can't imagine that any other result will come out of the selection of one particular IPng, except possibly for the roasting at the stake of the selecters :-(. I doubt that the selection of one proposal will make folks more willing to fix that proposal. I believe that we need to move quickly on IPng. I do not think we can just "make a decision" until we've gotten feedback from limited deployment, as I have serious doubts about the ability to deploy the current proposals. I think that it is possible to learn a lot about the deployability of proposals by looking at the specifications, if only there were complete specifications (for *any* of the proposals). However a substantial deployment will also be necessary. Dual-stack deployment _cannot_ work in some circumstances (once IPv4 addresses are not readily available, sites will be unable to deploy new systems which can communicate with important IPv4 legacy systems, due to lack of a IPv4 address). Thanks to the directorate for reminding me about glacial equipment replacement schedules. This seems to imply a misunderstanding of Dual Stack. One of the main points of Dual Stack is that the development of the two network layers continues, pretty much independently (with the understanding that there may be use of encapsulation in some cases). Thus IP will continue to be used and deployed. My expectation is that when there are too many systems for IP addresses to be globally unique, then folks will continue to use and deploy IP systems, but the bulk of the systems will have local IP addresses (only a few systems will have globally unique IP addresses -- I think that it is more believable that some global IP connectivity will continue to be useful for a long while for some systems, rather than that *all* IP use will become local). This implies that after IP ceases to have globally-sufficient addresses, new sytems, in most cases, will have globally unique IPng addresses, and local IPv4 addresses. This implies that such new systems will talk globally with all IPng systems, and talk locally with local IPv4 systems. A few systems will be able to have globally significant IPv4 and IPng addresses. I don't think that this is much different from the case with IPAE. I think that the difference between dual stack and IPAE is more in the dual- stack requirement that the system support multiple network layer packet formats, including host to router protocols (ARP, ICMP, ES-IS), as well as end to end data packet formats (IP, IPng). I will try to (i) find time to work on the dual stack paper, and (ii) make sure that this is explained clearly in it. IPAE's mapping tables are simply inconceivable from an operational viewpoint and the odds of all border routers being correctly configured in the 100 or so world-wide providers is nil. The described mechanism for table distribution (ftp) does not meet the needs of Internet operation, and folks familiar with the current failure of keeping the 7 root DNS servers in sync via FTP would not advocate attempting to keep several hundred routers under different authorities up to date with this mechanism. The addition of new sites to the Internet will require a level of coordination which simply cannot be obtained. When there are problems, the problem determination process for SIP/IPAE/IPv4 is so complicated that I do not expect most IETF members to diagnose their own difficulties. (The IETF terminal room should become quite entertaining.) Absolutely. I have heard rumors that these tables are being removed from IPAE, but have no idea what they might be replaced with. If this group needs to make a quick decision, let it be NAT. Ugh. Working out how NAT should work may be a good idea (if it is going to happen, then we might as well have some idea *how* it will happen). Ross From rcallon@wellfleet.com Wed Jan 26 19:53:03 1994 Return-Path: rcallon@wellfleet.com Received: from lobster.wellfleet.com (LOBSTER.WELLFLEET.COM [192.32.253.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id TAA01185 for ; Wed, 26 Jan 1994 19:46:32 -0500 Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA03552; Wed, 26 Jan 94 19:33:40 EST Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA15016; Wed, 26 Jan 94 19:43:12 EST Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA17428; Wed, 26 Jan 94 19:53:03 EST Date: Wed, 26 Jan 94 19:53:03 EST From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9401270053.AA17428@cabernet.wellfleet> To: ipng@cmf.nrl.navy.mil, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ...TUBA has also gone through some learning experiences, and several of the early decisions were based entirely on the assumption that CLNP could not/ should not be changed to make TUBA a success. Strangely, if I had realized that folks were going to be so resistant to updating CLNP, I would not have proposed using CLNP in the original TUBA RFC. My reason for choosing CLNP was that I thought that it was a sound protocol which is very close to what we actually need, and we could easily update it where needed to make it into a technically excellent protocol. Thus, I never thought that the fact that it already existed was particularly important. However, I soon discovered both (i) my previous company didn't want me to work on it; and (ii) the working group was resistant to changing it, even in compatible ways (ie, in ways that were compatible with existing equipment). ... At this point, it's recognized that CLNP must be changed to add multicasting, perhaps some flows, etc. TUBA could easily become a more capable proposal, complete with IPv4 address mapping, if one were to revisit the past decisions in the current light. Dino, I'm not advocating merger-mania... I'm calling for reconsideration of the current assumptions behind the proposals. We're going to have to live with IPng output for a century or more; I have no qualms about asking for technical review of the decisions made. This is particularly true when the the proposals have basic transition and/or operational flaws. I have wondered if we should throw out all existing proposals, lock about 5 or 6 of the directorate in a room, and not let them out until they come out with a solution (presumeably after sending the correct colored smoke up the chimney). Perhaps we could send them in with one case of very good wine, one case of lousy wine, enough food for three weeks, and enough water for 6 months. If they couldn't agree quickly, then they might come out very thin :-). ...if there is not a willingness on the working groups to test basic assumptions and potentially learn from the other work, we might as well disband now. Strongly agree. ... Paul Francis indicated that we should decide on a proposal, and then refine as needed. But how can we agree to a proposal unless we think that it is at least marginally workable as it stands? It has been suggested that some of the directorate discussions have been a bit too negative. I am actually concerned about almost the opposite: In private numerous folks seem to be willing to admit to technical concerns that they are not willing to say to the list, possibly for fear of insulting each other. If we see serious problems with a proposal then I think that we need to be able to admit this, or we run the risk of ending up with an unworkable solution. ...I ask that the directorate members put aside their differences and go through the exercise of constructively improving each others work _before_ we do anything as rash as selecting one particular approach to the problem. Yes! Ross From jcurran@nic.near.net Wed Jan 26 23:41:41 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id XAA04506 for ; Fri, 28 Jan 1994 23:07:45 -0500 Message-Id: <199401290407.XAA04506@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id ab13416; 26 Jan 94 23:41 EST To: Ross Callon cc: ipng@cmf.nrl.navy.mil Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: Your message of Wed, 26 Jan 1994 19:39:49 -0500. <9401270039.AA17418@cabernet.wellfleet> Date: Wed, 26 Jan 1994 23:41:41 -0500 From: John Curran -------- ] From: Ross Callon ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Wed, 26 Jan 94 19:39:49 EST ] ... ] My expectation is that when there are too many systems for IP addresses ] to be globally unique, then folks will continue to use and deploy IP ] systems, but the bulk of the systems will have local IP addresses (only ] a few systems will have globally unique IP addresses -- I think that it ] is more believable that some global IP connectivity will continue to be ] useful for a long while for some systems, rather than that *all* IP use ] will become local). ] ] This implies that after IP ceases to have globally-sufficient addresses, ] new sytems, in most cases, will have globally unique IPng addresses, and ] local IPv4 addresses. This implies that such new systems will talk globally ] with all IPng systems, and talk locally with local IPv4 systems. A few ] systems will be able to have globally significant IPv4 and IPng addresses. One sites' "local IPv4 address" is another sites "globally-unique" address?? In the absence of clear guidance from the transition documentation, this is clearly the case. In 2003, the system administrator for foo.com unpacks 2 new computer systems. Host A is assigned the last address in foo.com's address range. The admin calls and says: "I need one more, what should I do?" I tell him: "You should start using LOCALLY-unique IP addresses." He then assigns his new system the address "192.32.180.26" (picked totally out of thin air) and begins telling his 1000 hosts abut this new address space for routing purposes. Such fun. Meanwhile, down the hall in foo.com, someone starts swearing at the network. His communication with Ross Callon (the "true owner" of 192.32.180.26) has suddenly stopped. Ross, working at ABC Corp., suddenly finds that he can no longer talk to anyone at FOO, due to their address selection. The entire thing takes about 2 weeks realtime to resolve, and the estimate for lost time for all involved comes to slightly under $35K. Ross, when you write the dual-stack paper, would you specify where these local addresses come from? If there is going to be a reserved address space for this purpose, we need to document such interesting topics as how sites handle DNS for the local address space and the use of overlapping IPv4 netowrks on the local network. Perhaps dual-stack is viable, under the right administrative circumstances. We need documentation on this as soon as possible. If you're advocating something other than a reserved set of networks for this purpose (i.e. IPv4 uniqueness within scopes shared between sites) then how we get from one unique space to _one space with multiple uniqueness scopes_ needs to be described. Needless to say, the same type of information is desperately needed in order to evaluate transition ala IPAE. Scott Bradner: How would Harvard (hypothetically) adapt to the situation of having to add new systems on a local-use-only IPv4 net? Would "local" mean "local for Harvard" or "local for Harvard and affiliates"? Would it be a matter of weeks or years before you had to go buy a translator box with dynamic addr mapping to a small number of valid IPv4 addresses for global communication? Should NEARNET attempt to coordinate use of "locally-assigned" address space so that functionality is maintained for folks on such addresses within most of NE? Anyone else who is involved in local area network service care to comment on the above issues? This is real; think about how having local-use only systems would impact your organization. I would normally apologize for taking everyone's time, but I'm afraid that the time for open, content-full dialogue is upon us. Ross, I appreciate your notes on dual-stack transition: now I can conceive of using dual-stack as a transition mechanism, and would just like to see the details on these local address assignments on paper. Steve Deering: Ross indicated that the IPAE mapping tables may be replaced by something else. (This shouldn't be too surprising, given that they contain what is effectively routing information.) Can you supply any details as to what the replacement will be? It would also be useful to know how the actual transition from one uniqueness scope to multiple will be administratively handled; is there a forthcoming document on this? /John p.s. Paul Francis: It took over 18 months of planning and dialogue to get CIDR/BGP4 to the point where we knew it was operationally viable. Until the same type of dialogue occurs for the IPng proposals, there is no way of knowing whether they, in fact, can be deployed. I don't see any particular reason to declare "The" IPng proposal until we know that it _should_ work. Do you see some other value in making a selection prior everyone having confidence in the solution? From brian@dxcoms.cern.ch Thu Jan 27 08:34:10 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id CAA02401 for ; Thu, 27 Jan 1994 02:32:31 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08600; Thu, 27 Jan 1994 08:34:11 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA18532; Thu, 27 Jan 1994 08:34:10 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401270734.AA18532@dxcoms.cern.ch> Subject: Re: Path MTU To: ipng@cmf.nrl.navy.mil Date: Thu, 27 Jan 1994 08:34:10 +0100 (MET) In-Reply-To: <199401261923.OAA00578@picard.cmf.nrl.navy.mil> from "smb@research.att.com" at Jan 26, 94 02:23:38 pm 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: 3155 Steve, Van Jacobson has made the same point in his tutorials on long fat networks: for a given route with N routers and a given (bulk) transfer scenario there is an optimum MTU which is less than infinity and may be surprisingly small. He also points out, however, that if you can make a cut-through router (i.e. output starts as soon as the header has been read in) the parameters of the problem change by several orders of magnitude. The point is, the optimum MTU is strongly dependent on the scenario. If we are talking about a client/server scenario on a campus there may be only one router in the path and the optimum MTU will be large, maybe 4k in our experience here with FDDI. If we are talking about ftp between research.att.com and dxcoms.cern.ch the optimum MTU may be 576 bytes. So MTU discovery is only the first step; it should be followed by MTU tuning, but that is another story. There has been violent argument on this topic in the IPoverATM WG for many months. Brian >--------- Text sent by smb@research.att.com follows: > > A number of recent messages have indicated that support for Path MTU > is necessary. At the risk of sounding like a heretic, I'm not even > convinced that it's a good idea, let alone necessary. > > The problem with Path MTU is that the current Internet relies on routers > that are store-and-forward on a per-packet basis. Given the number of > hops a packet typically makes on a long-haul net, and given the comparatively > small window sizes, there's a significant amount of starvation due to > TCP window size exhaustion. With smaller packets, each router has less > waiting time before it can resend the packet; the net effect is that each > link can be kept busy, and some data will arrive promptly. > > To make things quantitative, at DS1 speeds a 1500 byte packet takes about > 7.7 milliseconds to be received. If the receiving host uses 8K byte > windows, which are hardly atypical, only 5 and a fraction packets can > be outstanding at any one time. Each router will take those 7.7 ms > to send each packet; if there are more than 6 hops, the sending host > will be idle till 7.7ms times the number of hops goes by, and the > ack comes back the same number of hops. If smaller packets were used, > the 7.7ms multiplier will be much reduced. > > Based on my comments, Rich Stevens wrote up a much clearer explanation > of this phenomenon in his new book ``TCP/IP Illustrated''. > > Now -- bulk transfer protocols might use great gronking huge windows, > and really be able to take advantage of every small increment in throughput > from fewer instances of per-packet overhead. But a lot of the other > traffic -- mail, ftp, etc. -- is in messages too short for that to matter > much. > > I've done a few tests, btw, that seemed to demonstrate this effect in > practice, not theory. The tests involved ttcp over a frame relay link > running at DS1 speeds. Cutting the MTU increased througput. (On the > other hand, Jeff Mogul thinks I was seeing an artifact of the ACK > scheduling in SunOS. One of these days, I'll find or build a TCP > simulator.) > > > --Steve Bellovin > From francis@cactus.ntt.jp Thu Jan 27 09:55:27 1994 Return-Path: francis@cactus.ntt.jp Received: from koudai.cs.titech.ac.jp ([131.112.176.1]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with ESMTP id UAA01260 for ; Wed, 26 Jan 1994 20:00:17 -0500 Received: by koudai.cs.titech.ac.jp (2.3W/koudai); Thu, 27 Jan 1994 10:01:31 +0900 Received: by lab.ntt.jp (8.6.4/GATENTTMX0.91); Thu, 27 Jan 1994 09:52:56 +0900 Received: from cactus.ntt.jp by ntt-twins.ntt.jp (8.5/NTTcs02b) id JAA11010; Thu, 27 Jan 1994 09:52:54 +0900 Received: by cactus.ntt.jp (4.1/NTTcs01b) with TCP; Thu, 27 Jan 94 09:55:27 JST Date: Thu, 27 Jan 94 09:55:27 JST From: francis@cactus.ntt.jp (Paul Francis) Message-Id: <9401270055.AA13044@cactus.ntt.jp> To: ericf@atc.boeing.com, francis@atc.boeing.com, jcurran@nic.near.net Subject: Re: Proposal history (was: Re: Brian's paper/Translation) Cc: Robert_Ullmann.LOTUS@crd.lotus.com, deering@parc.xerox.com, ipng@cmf.nrl.navy.mil > > I therefore propose that until we have bona fide requirements we can not > decide on an IPng and we can not identify the solution. Our requirements > identification is occurring far too late in the process. I propose that > ........ > the IPng requirements. In any case, we can not afford to proceed without > requirements and we need them now. > I've become rather cynical about efforts to define requirements. Even more so than protocols designed in committee, requirements defined in committee tend to be all-inclusive. Also, I think agreeing on requirements is about as hard as agreeing on a protocol, mainly because the path from requirement to corresponding protocol field is pretty short, so agreeing on requirements isn't much different than agreeing on protocol. Way back in Amsterdam, Frank pointed out that his and Craig's requirements doc failed for this very reason....they found that they couldn't include requirements that excluded certain protocols..... Once we pick the protocol, it is going to be hard enough to keep it clean. SIP has already suffered significant featurism (look at Steve's *original* proposal...), and it hasn't even yet been handed over to the masses in an "ownership" sense. If we choose a protocol now, there will be plenty of opportunity to fix bugs we find, and to add features if they are deemed required. PF From brian@dxcoms.cern.ch Thu Jan 27 09:02:14 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA02451 for ; Thu, 27 Jan 1994 03:00:38 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA15416; Thu, 27 Jan 1994 09:02:15 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20044; Thu, 27 Jan 1994 09:02:14 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401270802.AA20044@dxcoms.cern.ch> Subject: Where next (was: Re: Proposal history...) To: ipng@cmf.nrl.navy.mil Date: Thu, 27 Jan 1994 09:02:14 +0100 (MET) In-Reply-To: <9401270055.AA13044@cactus.ntt.jp> from "Paul Francis" at Jan 27, 94 09:55:27 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: 857 All, I have to support the view that we are doing this backwards (first identifying the solutions, and then identifying the requirements). It's unreasonable to ask the WGs to stop until the requirements are agreed, but I think we should put top priority on the requirements aspect between now and Seattle. In physics we talk about Grand Unified Theory, or Theory Of Everything: the attempt to produce a master theory that implies all other theories. You don't do this by writing down all the existing equations on the same page, but by looking for simpler equations with more universality. Same for IPng: you won't get the perfect IPng by taking the logical OR of SIPP, TUBA and CATNIP. So we do have to ask the question - do we want to improve one of the existing proposals or do we want to look for the genius who can invent the perfect IPng? Brian From bound@zk3.dec.com Thu Jan 27 09:18:53 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id JAA03491 for ; Thu, 27 Jan 1994 09:50:18 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA16072; Thu, 27 Jan 94 06:19:02 -0800 Received: by xirtlu.zk3.dec.com; id AA07208; Thu, 27 Jan 1994 09:18:59 -0500 Message-Id: <9401271418.AA07208@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: ipng@cmf.nrl.navy.mil Subject: Re: Path MTU In-Reply-To: Your message of "Wed, 26 Jan 94 14:23:38 EST." <199401261923.OAA00578@picard.cmf.nrl.navy.mil> Date: Thu, 27 Jan 94 09:18:53 -0500 X-Mts: smtp Steve, Another interesting problem I am seeing now is storing per host routes and use of that memory, and then doing the garbage collection. Another interesting issue is whether to move PMTU into the transport layer which one of my colleagues feels is a good idea. Do you not think its a good idea to determine bandwith potential and then use it? PMTU can increase performance too. PC code doing frag/reassembly is costly at this time too. I am open to this technical discussion. thanks /jim From bound@zk3.dec.com Thu Jan 27 09:43:12 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03542 for ; Thu, 27 Jan 1994 10:03:21 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA17188; Thu, 27 Jan 94 06:43:22 -0800 Received: by xirtlu.zk3.dec.com; id AA08125; Thu, 27 Jan 1994 09:43:19 -0500 Message-Id: <9401271443.AA08125@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil Subject: Re: Path MTU In-Reply-To: Your message of "Thu, 27 Jan 94 08:34:10 +0100." <9401270734.AA18532@dxcoms.cern.ch> Date: Thu, 27 Jan 94 09:43:12 -0500 X-Mts: smtp Brian, One part of PMTU I am working on right now is detecting increases in PMTU across the network path. Do you think this is part of PMTU fine tuning? Also if we think PMTU discovery should be a requirement (and I do right now), a proposoal should not reduce the PMTU path because of tunneling IPng or IPv4 permanently, or the MTUs should be increases on either side of the tunnel. thanks /jim From bound@zk3.dec.com Thu Jan 27 10:00:34 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03780 for ; Thu, 27 Jan 1994 10:41:14 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA18088; Thu, 27 Jan 94 07:00:41 -0800 Received: by xirtlu.zk3.dec.com; id AA08728; Thu, 27 Jan 1994 10:00:40 -0500 Message-Id: <9401271500.AA08728@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: IPng prototype code base and master solution Date: Thu, 27 Jan 94 10:00:34 -0500 X-Mts: smtp One aspect I want to point out about all these discussions is getting the code up for operational experience, and the effect of resources to work on the problem, per the master solution. I am leading and writing code and have been given a few other resources to work on IPng prototype. These resources are not given to me for infinite time and will have to be used elsewhere at some time. What we have going is a TUBA and SIPP code base and what I am trying to create too is the logical OR of TUBA and SIPP code base. All of this will be under AF_INET (internet family protoocol switch). The work right now is for a Host, but routers being looked at now. The work is being done on OSF/1 only fyi. If we move to a master solution it would be good to get some basic assumptions now and quickly because this cannot be a perpetual project at my end. One design objective is to not break existing binary compatibility of exising IPv4 applications. Our goal is that an IPv4 application (except apps that use IPv4 addresses inherently like FTP) should only need to present an address type to the transport via the sock_addr structure to become an IPng app. This has not been totally figured out but are close. Our large ISV customers polled stated this was important to them. Disclamer - Because we are neutral on IPng and working on all solutions I am not permitting this code base, until it really tests some operational problems for the Internet and IPng efforts, to be used by marketing types for quick demos that prove nothing other than a file got transfered etc. I want to see the nuts and bolts get tweeked. /jim From brian@dxcoms.cern.ch Thu Jan 27 16:34:48 1994 Return-Path: brian@dxcoms.cern.ch Received: from cmsun.cmf.nrl.navy.mil (cmsun.cmf.nrl.navy.mil [134.207.10.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03718 for ; Thu, 27 Jan 1994 10:32:55 -0500 Received: from dxmint.cern.ch by cmsun.cmf.nrl.navy.mil (4.1/client-1.3) id AA18183; Thu, 27 Jan 94 10:33:05 EST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA05896; Thu, 27 Jan 1994 16:34:49 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA16038; Thu, 27 Jan 1994 16:34:48 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401271534.AA16038@dxcoms.cern.ch> Subject: Re: Path MTU To: ipng@cmf.nrl.navy.mil Date: Thu, 27 Jan 1994 16:34:48 +0100 (MET) In-Reply-To: <9401271443.AA08125@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jan 27, 94 09:43:12 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: 1083 Jim, > > One part of PMTU I am working on right now is detecting increases in > PMTU across the network path. Do you think this is part of PMTU fine > tuning? This is part of it of course. However as I understood Van's arguments (I have his transparencies, but only on paper) there is more to it. With a sliding window protocol, if you send one big packet per window (i.e. packet size = MTU size = window size) you will lose throughput, since the next window will have to wait until the whole packet has been handled consecutively by every router and completely read into the remote host. If you send many smaller packets you will get pipelining and therefore more throughput. This proves that there must be an optimum packet size, significantly smaller than the window size if there are many routers on the path. Therefore, it is a false assumption that the ideal packet size is the PMTU size; it may well be less. I am not an expert in this area so I think I'd better shut up. (However we definitely want all our suppliers to implement MTU discovery by yesterday :-) Brian From smb@research.att.com Thu Jan 27 10:49:35 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03819 for ; Thu, 27 Jan 1994 10:48:23 -0500 From: smb@research.att.com Message-Id: <199401271548.KAA03819@picard.cmf.nrl.navy.mil> Received: by gryphon; Thu Jan 27 10:49:36 EST 1994 To: Brian.Carpenter@cern.ch cc: ipng@cmf.nrl.navy.mil Subject: Re: Path MTU Date: Thu, 27 Jan 94 10:49:35 EST > > One part of PMTU I am working on right now is detecting increases in > PMTU across the network path. Do you think this is part of PMTU fine > tuning? This is part of it of course. However as I understood Van's arguments (I have his transparencies, but only on paper) there is more to it. With a sliding window protocol, if you send one big packet per window (i.e. packet size = MTU size = window size) you will lose throughput, since the next window will have to wait until the whole packet has been handled consecutively by every router and completely read into the remote host. If you send many smaller packets you will get pipelining and therefore more throughput. This proves that there must be an optimum packet size, significantly smaller than the window size if there are many routers on the path. Therefore, it is a false assumption that the ideal packet size is the PMTU size; it may well be less. You've got it exactly right, with one minor addition: the problem still shows up if even if you send more than one packet per window, so long as the number of packets per window is (roughly) less than the number of hops. I'm glad Van is worrying about this point, too. From smb@research.att.com Thu Jan 27 10:56:42 1994 Return-Path: smb@research.att.com Received: from research.att.com (ninet.research.att.com [192.20.225.3]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id KAA03858 for ; Thu, 27 Jan 1994 10:55:23 -0500 From: smb@research.att.com Message-Id: <199401271555.KAA03858@picard.cmf.nrl.navy.mil> Received: by gryphon; Thu Jan 27 10:56:43 EST 1994 To: bound@zk3.dec.com cc: ipng@cmf.nrl.navy.mil Subject: Re: IPng prototype code base and master solution Date: Thu, 27 Jan 94 10:56:42 EST One design objective is to not break existing binary compatibility of exising IPv4 applications. Our goal is that an IPv4 application (except apps that use IPv4 addresses inherently like FTP) should only need to present an address type to the transport via the sock_addr structure to become an IPng app. This has not been totally figured out but are close. Our large ISV customers polled stated this was important to them. How are you going to make that work? There's a lot of code lying around that assumes that IP addresses fit in a struct inaddr, which is 4 bytes long. From bound@zk3.dec.com Thu Jan 27 11:23:31 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA04392 for ; Thu, 27 Jan 1994 11:47:09 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA21628; Thu, 27 Jan 94 08:23:43 -0800 Received: by xirtlu.zk3.dec.com; id AA11508; Thu, 27 Jan 1994 11:23:38 -0500 Message-Id: <9401271623.AA11508@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: IPng prototype code base and master solution In-Reply-To: Your message of "Thu, 27 Jan 94 10:56:42 EST." <9401271557.AA20564@decvax.dec.com> Date: Thu, 27 Jan 94 11:23:31 -0500 X-Mts: smtp Steve, One design objective is to not break existing binary compatibility of exising IPv4 applications. Our goal is that an IPv4 application (except apps that use IPv4 addresses inherently like FTP) should only need to present an address type to the transport via the sock_addr structure to become an IPng app. This has not been totally figured out but are close. Our large ISV customers polled stated this was important to them. >How are you going to make that work? There's a lot of code lying >around that assumes that IP addresses fit in a struct inaddr, which >is 4 bytes long. Well at first for SIP (without plus P) it was real easy as the sin_zero field was exactly 8 bytes. The gethostbyname would ask for a type SIP or IPv4 and start a server concurrent or iterative session on a port. If a client needed IPv4 or SIP the server would know and just pass a parameter to the forked or threaded client SIP or IPv4 and it could then use either address space via my integrated network layer. But with SIPP [Plus P] the address now could be an Address Sequence Record of multiple 64bit segments. Now SIPP has the same potential problem TUBA does in that there is no way to fit the large address in the present sock_addr_in structure. But I would still like to not break apps. So (and this is very rough and we are talking technical turkey now internally on this now OK) mabye we move in the kernel space to the BSD 4.4 sock_addr which permits a length field and variable address length. At the application layer the address structure it becomes even more opaque than now and for those instances where the binary would break we build "shims" (I know I hate this word). All addresses now in the kernel are using the 4.4 variable address structure. But in case of SIPP if 64bits of the address sequence record can alwayus be unique and in the transport I can differentiate the sequence records then I can prepend the prefix and addr seq segments to the tcpcb structure using 4.4 sock_addr_in. This would take care of alignments. But I am now believing we should move to 4.4 sock_addr_in regardless for any IPng. We may have no choice but to break binary compatibility but I am going to try to figure out a way to not let this happen for any IPng. I think the reason APIs keep coming up in IPng now is not that we want to get into that standards effort in the IETF but then the IETF never created a standard protocol that broke the API before either. /jim From bound@zk3.dec.com Thu Jan 27 11:43:47 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id MAA08861 for ; Thu, 27 Jan 1994 12:09:56 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA22554; Thu, 27 Jan 94 08:43:55 -0800 Received: by xirtlu.zk3.dec.com; id AA12038; Thu, 27 Jan 1994 11:43:53 -0500 Message-Id: <9401271643.AA12038@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: ipng@cmf.nrl.navy.mil, bound@zk3.dec.com Subject: Re: Path MTU In-Reply-To: Your message of "Thu, 27 Jan 94 16:34:48 +0100." <9401271534.AA16038@dxcoms.cern.ch> Date: Thu, 27 Jan 94 11:43:47 -0500 X-Mts: smtp Brian and Steve too, >This is part of it of course. However as I understood Van's arguments (I >have his transparencies, but only on paper) there is more to it. With a >sliding window protocol, if you send one big packet per window (i.e. >packet size = MTU size = window size) you will lose throughput, since the >next window will have to wait until the whole packet has been handled >consecutively by every router and completely read into the remote host. >If you send many smaller packets you will get pipelining and therefore >more throughput. This proves that there must be an optimum packet size, >significantly smaller than the window size if there are many routers on >the path. Therefore, it is a false assumption that the ideal packet size >is the PMTU size; it may well be less. Yes this is definitely an issue. But, the PMTU can converge on the optimum segment size via the congestion window. Also the window size must be an exact multiple of the segment size. If networks get faster and throughput more efficient the PMTU can be larger. >I am not an expert in this area so I think I'd better shut up. Please dont do that the discussion is going good I think. We may need to get Jeff Mogul, Steve Deering, or Steve Bellovin to correct us once in awhile but we should move forward >(However we definitely want all our suppliers to implement MTU discovery >by yesterday :-) OK ......thats good input too.............. /jim From bound@zk3.dec.com Fri Jan 28 00:16:06 1994 Return-Path: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com (inet-gw-2.pa.dec.com [16.1.0.23]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id AAA13850 for ; Fri, 28 Jan 1994 00:22:11 -0500 From: bound@zk3.dec.com Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/13Jan94) id AA17994; Thu, 27 Jan 94 21:16:13 -0800 Received: by xirtlu.zk3.dec.com; id AA26990; Fri, 28 Jan 1994 00:16:12 -0500 Message-Id: <9401280516.AA26990@xirtlu.zk3.dec.com> To: ipng@cmf.nrl.navy.mil Subject: PMTU and Pipelining Date: Fri, 28 Jan 94 00:16:06 -0500 X-Mts: smtp I asked Jeff Mogul if he could give me an interpretation of Vans pipeline issue. Here is what I got back. /jim ------------------------------- Text from Brian However as I understood Van's arguments (I have his transparencies, but only on paper) there is more to it. With a sliding window protocol, if you send one big packet per window (i.e. packet size = MTU size = window size) you will lose throughput, since the next window will have to wait until the whole packet has been handled consecutively by every router and completely read into the remote host. If you send many smaller packets you will get pipelining and therefore more throughput. This proves that there must be an optimum packet size, significantly smaller than the window size if there are many routers on the path. Therefore, it is a false assumption that the ideal packet size is the PMTU size; it may well be less. End Test from Brian --------------------------- ----------------------------- Text from Jeff This is only part of Vans argument there is more. Yes, it is quite horribly awful to have MTU size = window size (actually, to have window size < 2 * MSS), but that is independent of pipelining in general, or MTU discovery in particularly. It has to do mostly with the standard TCP delayed ACK mechanism. What an end-system TCP implementation should do is to *not allow* the use of window sizes (receive or transmit buffer sizes) below (2 * first_hop_mss), which is normally (2 * (first_hop_mtu - 40)). With today's common networks, this normally means that the window size has to be larger than 3kB (for Ethernet) or 8.7kB (for FDDI, unless people would follow my suggestion and use a 4K MSS for FDDI, in which case the minimal safe window size would be exactly 8K and life would be a lot better. Hint, hint.) Note that PMTUD will never increase the path MTU estimate above the first hop MTU. So if the system sets the window size at least to (2 * first_hop_mss), then the condition "window size >= 2 * MSS" will always be true. Note that this is complicated by the fact that sosend() does manifestly the wrong thing in deciding when to move more data from user space into an outgoing socket buffer. It can screw up spectactularly badly even when PMTUD is not used, but because its effect on performance is so unstable, if PMTUD causes use of a different MSS, people may encounter nasty surprises. The proper solution is to get rid of sosend(), or at least make it cognizant of the underlying transport's current MSS. Getting back to pipelining: if you want TCP to exhibit proper pipelining, then the window size (i.e., both receive and transmit buffer size) has to be large enough to hold enough data to fill the entire pipeline. This has little to do with MSS size, except that if the MSS is small, then a given amount of useful data requires more header bytes, and so the pipeline fills faster. But it fills up with useless bits, so this is not a net win for useful-data bandwidth. Also, since many routers limit the number of packets queued (not just the number of bytes queued), using unnecessarily small packets can cause early buffer overflow and packet loss. In short: PMTUD does the right thing. TCP does the right thing, if the buffer sizes are large enough. sosend() does the wrong thing, but that's independent of PMTUD. -Jeff ------------------------------------ From brian@dxcoms.cern.ch Fri Jan 28 09:02:08 1994 Return-Path: brian@dxcoms.cern.ch Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id DAA14390 for ; Fri, 28 Jan 1994 03:00:27 -0500 Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA00739; Fri, 28 Jan 1994 09:02:10 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01396; Fri, 28 Jan 1994 09:02:08 +0100 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9401280802.AA01396@dxcoms.cern.ch> Subject: My discussion with Paul Van Binst To: ipng@cmf.nrl.navy.mil, vcerf@cnri.reston.va.us (Vint Cerf) Date: Fri, 28 Jan 1994 09:02:08 +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: 897 Just a few words on my discussion yesterday with Paul Van Binst, who chairs the EWOS Steering Committee. Paul is convinced that to get official recognition in Europe (i.e. by governments and by the European Union) standards have to be formal, i.e. ISO or ITU standards. EWOS is currently discussing what to do about de facto standards, and unfortunately they include IETF standards in this category. His view is that only by submitting IETF standards on fast-track procedures to ISO can they achieve the necessary level of formality. This of course raises the issue of change control passing from IETF to ISO. He mentioned that EWOS is planning a conference on Open Systems Standards later this year (date t.b.d.) where these issues will be debated. My conclusion: there is zero chance of anything equivalent to the FIRP report in Europe, on a timescale relevant to the IPng choice. Brian From sob@hsdndev.harvard.edu Fri Jan 28 10:06:38 1994 Return-Path: sob@hsdndev.harvard.edu Received: from hsdndev.harvard.edu (hsdndev.harvard.edu [128.103.202.40]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id LAA00675 for ; Fri, 28 Jan 1994 11:31:34 -0500 Date: Fri, 28 Jan 94 10:06:38 -0500 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9401281506.AA23269@hsdndev.harvard.edu> To: ipng@cmf.nrl.navy.mil Subject: John"s points I've been catching up on mail after two days off to ComNet. I notice that John Curran sent out a message postulating a few things that generated quite a bit of exchange but I noticed that the prime representives for the three proposals did not seem to take part in the exchanges. Can Steve, Mark & Rob chime in with their thoughts? Scott From deering@parc.xerox.com Fri Jan 28 14:29:56 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id RAA03241 for ; Fri, 28 Jan 1994 17:28:43 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <15059(7)>; Fri, 28 Jan 1994 14:30:12 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 28 Jan 1994 14:30:06 -0800 To: ipng@cmf.nrl.navy.mil Cc: deering@parc.xerox.com Subject: Re: Proposal history (was: Re: Brian's paper/Translation) In-reply-to: jcurran's message of Wed, 26 Jan 94 10:55:32 -0800. <94Jan26.105653pst.15338(2)@alpha.xerox.com> Date: Fri, 28 Jan 1994 14:29:56 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan28.143006pst.12171@skylark.parc.xerox.com> > From: John Curran > > 1. Hierarchical prefix-based routing with aggregation (as recommended in > CIDR, SIPP, and TUBA) has the potential for routing scaling if adaquate > backpressure mechanisms exist. As a result of CIDR, IPng does not have > to "solve" the routing scaling problem for IPv4. I think this is still an open question -- if a significant number of those sites that have obtained a (pre-CIDR) IP network number, but have never attached to the Internet, were to attach over the next year or so (not an entirely farfetched possibility, given all the hype that the Internet is getting), the backbone routing tables still might explode. But perhaps you are right. IN THAT CASE, the IPAE mapping table degenerates into a table with only ONE entry, which maps all IP network numbers to a single, 32-bit prefix. Maintenance of that "table" is a non-issue. In that mode, IPAE is basically the same as CATNIP when translating from IPv4 to IPng. (However, it differs in the IPng to IPv4 direction, in that IPAE does not rely on the correct handling of previously-undefined IPv4 options by existing IPv4 systems, a black-hole-vulnerable assumption of CATNIP. In the last CATNIP draft I read, that was only one of several black-hole vulnerabilities; I'd better read Robert's latest to see if he has patched those holes before I say more.) On the other hand, you may be wrong. Maybe we will have a routing-table- size crisis before we have sufficient deployment of IPng systems. In that case, if we adopt IPAE, we will have a backup solution in place. Yes, it will be a major chore to maintain the mapping tables, but if we come to that point, I assume we will be willing to perform that chore in order to keep the Internet alive. > Once IPv4 addresses are no longer available, it is desirable (but not > required) to allow interoperability between new IPng systems and IPv4. Who are we to say that allowing IPng systems to communicate with IPv4 systems basically "for ever" within local sub-regions of the Internet (whether by translation or by dual-stacking) is not a requirement? I suspect that it *would* be a requirement for many sites. > ...Likewise, the cost > of variable length addressing is not actually a performance burden. Huh? It depends on your particular device, whether or not variable-length addressing is a performance burden. It might not be a burden on the latest hot-shot router architecture, but it might well be a burden on a memory- or CPU-challenged host. > o IPAE was designed originally as a method for improving route scaling > and providing IPng-IPv4 interoperability within IPv4 commonwealths. Extending the IPv4 address space was also one of its major design goals. > ...IPAE's signficant difference over other transition schemes remains > its ability to support multiple IPv4 uniqueness regions once IPv4 > addresses are no longer globally unique. I don't think that property is unique to IPAE -- any of the proposed schemes can provide that capability. What IPAE provides is that capability *without* having to keep an IPv4 stack on your IPng systems indefinitely. > Dual-stack deployment _cannot_ work in some circumstances (once IPv4 > addresses are not readily available, sites will be unable to deploy new > systems which can communicate with important IPv4 legacy systems, due to > lack of a IPv4 address). As Ross pointed out, this can be handled by allocating part of the IPv4 address space for local-use only. > If this group needs to make a quick decision, let it be NAT. Gag me with a chainsaw. > ... SIP started as close to IPv4 as possible (quite a reasonable starting > point) but now that variable length addresses have actually become accepted, Well, there's still at least one hold-out for fixed-length (64-bits, in fact) addresses -- me. SIPP happens to support variable-length addressing through use of the Routing Header, but I consider that observation as something to increase the comfort level of the address-space claustrophobes, not something we'd ever really need to use. (The real value of the Routing Header is for other functionality, such as provider-selection.) > ... Forwarding across SIP extended address spaces requires a circular > rewrite to get the next address element into the header, and this is not > going to pipeline easily in anyone's hardware. If we never go to extended addresses, that won't be a issue. And if we do, the effect occurs only at major boundaries (not at every or even most hops), where performance is probably already being sacrificed for things like firewall filtering. Steve From deering@parc.xerox.com Fri Jan 28 15:05:39 1994 Return-Path: deering@parc.xerox.com Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA03428 for ; Fri, 28 Jan 1994 18:04:14 -0500 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <15207(7)>; Fri, 28 Jan 1994 15:05:45 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 28 Jan 1994 15:05:40 -0800 To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: ipng@cmf.nrl.navy.mil, deering@parc.xerox.com Subject: Re: what do you all think? In-reply-to: sob's message of Fri, 21 Jan 94 18:06:33 -0800. <9401220206.AA13477@hsdndev.harvard.edu> Date: Fri, 28 Jan 1994 15:05:39 PST Sender: Steve Deering From: Steve Deering Message-Id: <94Jan28.150540pst.12171@skylark.parc.xerox.com> Scott, You asked what we thought of the message from Rex Buddenburg regarding future evolution of the Internet and the role of XTP in that future. I think his description of the likely evolution of the Internet is quite believable (though the idea of switching ATM cells over the CATV cable plant is even more braindamaged than expected from the packet-shredding crowd), but I don't see any place for XTP in that future. For years, XTP has been trying to find an ecological niche -- first it was going to replace TCP because TCP was too slow, then it was peddled to ANSI as TP-5, and to IEEE as a new LLC, and now its being positioned as the "next generation transport protocol" that can do not only everything TCP can do, but multicast video and audio too! I guess we'd better stop sending audio and video around the Internet until we get XTP deployed, eh? Uncharitably, Steve From jcurran@nic.near.net Fri Jan 28 18:17:03 1994 Return-Path: jcurran@nic.near.net Received: from nic.near.net (nic.near.net [192.52.71.4]) by picard.cmf.nrl.navy.mil (8.6.4/8.6.4) with SMTP id SAA03460 for ; Fri, 28 Jan 1994 18:14:51 -0500 Message-Id: <199401282314.SAA03460@picard.cmf.nrl.navy.mil> Received: from nic.near.net by nic.near.net id aa10007; 28 Jan 94 18:17 EST To: Steve Deering cc: ipng@cmf.nrl.navy.mil Subject: Re: Proposal history In-reply-to: Your message of Fri, 28 Jan 1994 14:29:56 -0800. <94Jan28.143006pst.12171@skylark.parc.xerox.com> Date: Fri, 28 Jan 1994 18:17:03 -0500 From: John Curran -------- ] From: Steve Deering ] Subject: Re: Proposal history (was: Re: Brian's paper/Translation) ] Date: Fri, 28 Jan 1994 14:29:56 PST ] ] I think this is still an open question -- if a significant number of those ] sites that have obtained a (pre-CIDR) IP network number, but have never ] attached to the Internet, were to attach over the next year or so (not an ] entirely farfetched possibility, given all the hype that the Internet is ] getting), the backbone routing tables still might explode. Either: o These new sites will acquire CIDR-friendly addresses. -or- o These new sites will pay sufficient funds to offset the cost of their route entry in the global Internet. Explosion isn't a possibility, business factors enter the equation first. ] But perhaps you are right. IN THAT CASE, the IPAE mapping table degenerates ] into a table with only ONE entry, which maps all IP network numbers to a ] single, 32-bit prefix. Maintenance of that "table" is a non-issue. In that ] mode, IPAE is basically the same as CATNIP when translating from IPv4 to IPng. ] (However, it differs in the IPng to IPv4 direction, in that IPAE does not ] rely on the correct handling of previously-undefined IPv4 options by ] existing IPv4 systems, a black-hole-vulnerable assumption of CATNIP. ] In the last CATNIP draft I read, that was only one of several black-hole ] vulnerabilities; I'd better read Robert's latest to see if he has patched ] those holes before I say more.) Interesting view of CATNIP... I hadn't thought of it in comparision to IPAE. (Time to catch up with reading :-) ] On the other hand, you may be wrong. Maybe we will have a routing-table- ] size crisis before we have sufficient deployment of IPng systems. In that