From owner-Big-Internet@munnari.oz.au Thu Sep 10 02:32:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24646; Thu, 10 Sep 1992 02:32:53 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24610; Thu, 10 Sep 1992 02:32:04 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA04971; Wed, 9 Sep 92 09:32:00 PDT Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA02405; Wed, 9 Sep 92 09:32:01 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA29575; Wed, 9 Sep 92 09:29:37 PDT Date: Wed, 9 Sep 92 09:29:37 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9209091629.AA29575@bigriver.Eng.Sun.COM> To: big-internet@munnari.oz.au Cc: Bob.Hinden@Eng.Sun.COM Subject: Test Test, please ignore. Bob From owner-Big-Internet@munnari.oz.au Thu Sep 10 07:57:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05674; Thu, 10 Sep 1992 07:58:28 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05617; Thu, 10 Sep 1992 07:57:26 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA20639; Wed, 9 Sep 92 14:57:05 -0700 Message-Id: <9209092157.AA20639@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: Correction (was: Re: new ip protocol proposal..... ) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 19 May 92 17:12:36 +0100. <9205191613.20262@munnari.oz.au> Date: Wed, 09 Sep 92 14:57:05 -0700 From: Dave Crocker X-Mts: smtp Small point, from Paul's previous note. He mentions something called "IPIP". Since there was such a proposal, quite awhile ago, and since the current, derivative work is quite substantially different, I'll mention that the current work is called IPAE (IP Address Encapsulation) and that anyone who knows only about IPIP probably does not understand enough about the IPAE proprosal. This has confused a number of people, so it seemed worth repeating. Dave From owner-Big-Internet@munnari.oz.au Tue Sep 15 02:25:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26211; Tue, 15 Sep 1992 02:25:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209141625.26211@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26199; Tue, 15 Sep 1992 02:25:47 +1000 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) To: dkatz@cisco.com Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com In-Reply-To: <9207302221.AA14244@cider.cisco.com> Date: Mon, 14 Sep 92 10:28:49 EDT Mail-System-Version: >Date: Thu, 30 Jul 92 15:21:32 -0700 >From: Dave Katz >To: callon@bigfut.enet.dec.com >Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com >Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) > > First of all, it would not be necessary to carry the > IP address in the IDI. An AFI for IP (or for the ISOC) could have > a null IDI, and then a binary DSP assigned however we want it > >I think this is true only if ISO actually assigns the AFI to ISOC; otherwise, >the trail of adminstrative authority is lost. One of the functions of the >NSAP structure is to show a clear hierarchy of administrative authority. The >only reason that the "local AFIs" (48/49) can be owned by ISO and have no >IDI is because there is *no* administrative authority defined for such >addresses. Think about it--what would 8348 say about this AFI w/o IDI? Dave, It would have to say something that it currently does not say about any of the other formats - that is, not only "the IDI is such and such" (in this case null) and "the abstract syntax of the DSP is such and such" (in this case binary), but also "the structure and semantics of the DSP are defined and governed by some Internet body" (perhaps the IANA; perhaps, more in keeping with the way in which the NSAP standard is currently organized, an Internet Standard, since the other "authorities" in 8348/Add 2 are actually standards, rather than bodies). Currently, it's the value of the IDI that tells you who or what defines the DSP; but with a null IDI, it's not unreasonable for this discrimination to back up into the AFI itself. - Lyman > > Also, the most recent re-write of > the Network service definition (including the Network address > specification) have removed the coupling between binary and decimal > address encodings, which means that now an address can be purely > binary and does not have to be capable of being represented in decimal. > >This does syntactically make binary IDIs possible; however, unless there >has been a change to the appropriate parts of 8348, it still says that the >IDI has decimal abstract syntax (meaning that only decimal numbers are >valid, which are then encoded as BCD). This would have the side effect of >making the abstract syntax of the IDI dependent on the AFI (the existing >IDIs must continue to be decimal), which is not currently true (not that it's >a huge problem). > > address fields in IDPR, to be used for routing IP traffic > >Careful, you mean IDRP! > > There is one other issue here: We have to decide whether we actually > need our own address space. My *very* rough back-of-the-envelope > calculation suggests that the format already used by US GOSIP / ANSI / > OSINET / european CLNP pilot will be able to scale to several orders of > magnitude larger than anyone is projecting the Internet could possible > scale to (I even allowed for a possible Chinese PTT delivering CLNP > service to a LAN in every home in China). Naturally, it is very hard to > figure out how to make such projections, and any projections are likely > to be controversial and full of contigency plans, given that we really > don't know how an infrastructure for 10^9 administrative domains will > be put together (eg, will there be more than 10,000 public providers > worldwide? If so, then will they be structured in some way to facilitate > routing between them). > >The assignment of an ICD value to ISOC would add three octets to the space >already available, even if a version number octet were included *and* >assuming that the GOSIP/ANSI "reserved" field was used in the current >addressing structure. An AFI would add two more. > > We might however want to have our own AFI so that we can have greater > control over the manner in which addresses are assigned in the Internet. > >I think this is a red herring; ISOC has complete control over the chunk of >address space assigned to it, regardless of where the ISOC address space >branches off of the tree (AFI, ICD, GOSIP AAI). > > From owner-Big-Internet@munnari.oz.au Tue Sep 15 05:46:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02860; Tue, 15 Sep 1992 05:47:08 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02848; Tue, 15 Sep 1992 05:46:57 +1000 (from dave@sabre.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA28210; Mon, 14 Sep 92 15:50:37 EDT Received: by sword.bellcore.com;id 9209141947.AA19705 Message-Id: <9209141947.AA19705@sword.bellcore.com> Date: Mon, 14 Sep 1992 15:52:50 -0500 To: big-internet@munnari.oz.au From: dave@sabre.bellcore.com Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) >... Currently, it's the value of >the IDI that tells you who or what defines the DSP; but with a null IDI, >it's not unreasonable for this discrimination to back up into the AFI itself. > >- Lyman I really don't understand the confusion--the AFI sez "this is ISOC's string of bits, go ask them about what follows since we (ISO) don't know". It doesn't suggest that there is any loss of administration, only that ISO and ISOC (sounds a lot like conjugating verbs to me) do not share the structure > There is one other issue here: We have to decide whether we actually > need our own address space. My *very* rough back-of-the-envelope > calculation suggests that the format already used by US GOSIP / ANSI / > OSINET / european CLNP pilot will be able to scale to several orders of > magnitude larger than anyone is projecting the Internet could possible Maybe someone on this mailing list can answer this question, since it was posted to the tuba list and no one offered an answer. Exactly what *is* wrong with the current (RFC1237) NSAPA plan for the internet? --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) From owner-Big-Internet@munnari.oz.au Tue Sep 15 07:36:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07590; Tue, 15 Sep 1992 07:36:28 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA07584; Tue, 15 Sep 1992 07:36:15 +1000 (from dee@ranger.enet.dec.com) Received: from inet-gw-2.pa.dec.com (via [16.1.0.23]) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA01936; Mon, 14 Sep 92 17:30:23 -0400 Received: by inet-gw-2.pa.dec.com; id AA28763; Mon, 14 Sep 92 14:24:59 -0700 Received: by us1rmc.bb.dec.com; id AA23456; Mon, 14 Sep 92 17:22:20 -0400 Message-Id: <9209142122.AA23456@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 14 Sep 92 17:22:21 EDT Date: Mon, 14 Sep 92 17:22:21 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 14-Sep-1992 1724" To: dave@sabre.bellcore.com Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, dave@sabre.bellcore.com Subject: RE: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) Like a lot of other people, I think 20 bytes addresses are ridiculously long and wasteful. Donald -------------- From: US1RMC::"dave@sabre.bellcore.com" "MAIL-11 Daemon" 14-SEP-1992 16:49 > There is one other issue here: We have to decide whether we actually > need our own address space. My *very* rough back-of-the-envelope > calculation suggests that the format already used by US GOSIP / ANSI / > OSINET / european CLNP pilot will be able to scale to several orders of > magnitude larger than anyone is projecting the Internet could possible Maybe someone on this mailing list can answer this question, since it was posted to the tuba list and no one offered an answer. Exactly what *is* wrong with the current (RFC1237) NSAPA plan for the internet? --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) From owner-big-internet@munnari.oz.au Wed Sep 16 00:11:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16162; Wed, 16 Sep 1992 00:11:55 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13886; Tue, 15 Sep 1992 23:38:22 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA110461 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Tue, 15 Sep 1992 09:37:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Sep 1992 09:37:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Sep 1992 09:37:53 -0400 Date: Tue, 15 Sep 1992 09:35:56 -0400 From: Dennis Ferguson Message-Id: <199209151335.AA29468@foo.ans.net> To: dave@sabre.bellcore.com Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) Cc: big-internet@munnari.oz.au > From: dave@sabre.bellcore.com > Maybe someone on this mailing list can answer this question, since it was > posted to the tuba list and no one offered an answer. Exactly what *is* > wrong with the current (RFC1237) NSAPA plan for the internet? I can offer an opinion. Personally I find the separation of routing information in an address from end-point identification to be an attractive feature of the more radical of the other IPv7 proposals. TUBA, as originally presented, was to have this property as well. The requirement to implement this is that the NSAP contain an ID which is guaranteed to be globally unique, and which is either fixed length and in a fixed location in the NSAP (so hosts can find it) or can at least be locatable from other well-known information carried in the NSAP. I think that pragmatically, to avoid operational difficulties, this ID has to be assigned to hosts with a fair degree of permanence (the dynamic host ID assignment some OSI implementions use depends on the existance of a directory service capable of tracking possible changes to the host ID as they occur, without service glitches. The Internet has no such directory service). It probably needs enough internal structure to identify organizational responsibility for the host (so the content of the routing portion of the address can be freed of any semantics other than topological) and perhaps needs to be structured such that the ID portion of the address can be used for directory lookups by itself (to avoid the need for the directory service to track mobile hosts, for example). In any case, I think carrying a globally-unique, globally-locatable host ID in NSAPs for TUBA has a lot of advantages. In contrast, in rfc1237 we have | The ID field may be from one to eight octets in length, but must have | a single known length in any particular routing domain. Each router is | configured to know what length is used in its domain. The SEL field is | always one octet in length. Each router is therefore able to identify | the ID and SEL fields as a known number of trailing octets of the NSAP | address. The area address can be identified as the remainder of the | address (after truncation of the ID and SEL fields). and | * Level 1 routing acts on the ID field. The ID field must be unique | within an area for ESs and level 1 ISs, and unique within the | routing domain for level 2 ISs. The ID field is assumed to be | flat; Simply, rfc1237 NSAPs do not have a guaranteed-globally-unique identifier. The identifier in rfc1237 NSAPs need only be unique within the routing domain (at worst), and need not be locatable in the NSAP outside the routing domain. No existing NSAP format that I know of requires the presence of a globally unique ID either, and NSAPs in use on the Internet now do not have one. I can think of several ways to fix this. (1) Forget about globally-unique identifiers, use the entire NSAP for end-point identification (and include the whole thing in the TCP and UDP checksums) instead. This will allow existing NSAPs to be used for TCP and UDP, but makes the TUBA proposal less attractive (in my view). (2) Retrofit existing NSAP formats with globally unique IDs. This is dangerous since many are already in use without globally unique IDs, and may require implementations to maintain long lists of NSAP formats which have globally unique IDs so they can tell them from NSAPs which don't have this property. (3) Define a new NSAP format which has a globally unique ID in a well known location, and use only this for TCP/UDP. This will allow implementations to distinguish NSAPs which carry a globally-unique ID from those which don't fairly easily. The last is where the Internet AFI might be useful, I guess. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Wed Sep 16 02:11:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20193; Wed, 16 Sep 1992 02:11:19 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20186; Wed, 16 Sep 1992 02:11:09 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA04909 (5.65b/CWI-2.175); Tue, 15 Sep 1992 18:10:37 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA08100; Tue, 15 Sep 92 18:11:01 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA20771; Tue, 15 Sep 92 18:10:31 +0200 Message-Id: <9209151610.AA20771@dxcern.cern.ch> Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) To: big-internet@munnari.oz.au Date: Tue, 15 Sep 92 18:10:30 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <9209141947.AA19705@sword.bellcore.com>; from "dave@sabre.bellcore.com" at Sep 14, 92 3:52 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by dave@sabre.bellcore.com follows: > ... > > Maybe someone on this mailing list can answer this question, since it was > posted to the tuba list and no one offered an answer. Exactly what *is* > wrong with the current (RFC1237) NSAPA plan for the internet? Well, as I _have_ said on the TUBA list (why do I keep typing TUNA?) I believe that any plausible NSAPA plan for the Internet should embed an encapsulation of IPv4 addresses to allow IP islands to be interconnected by a CLNP infrastructure, with only the routers having to know about it. I even proposed some text for the relevant TUNA draft, here it is at the risk of boring you. I don't think this invalidates 1237, but maybe it adds value. Or subtracts value, according to your philosophy. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | ------------- Rationale: the address formats specified should include one that allows IP (version 4) addresses to be carried in a valid CLNP header. This would be used during transition from IP (version 4) to TUBA, to support interconnection of IP (version 4) islands via TUBA islands, or to allow the implementation of translating routers. Proposed additions: =================== After CASE 1: ISOC obtains an AFI. ================================== 1 byte Second currently assigned value is "IP version 4 mode" if addr type specifies "IP version 4 mode", rest of address looks like: 7 bytes Reserved for allocation by IETF. A specific allocation might include any future "IP version 7" extension of the IP version 4 address space. 4 bytes IP version 4 address identifying the host 6 bytes Identifies the host. This is globally unique. May be dummy value for some IP version 4 hosts. 1 byte Identifies higher level protocol running over CLNP. (Uses values from current "assigned numbers" RFC) total: 20 bytes After CASE 2: ISOC obtains an ICD. ================================== 1 byte Second currently assigned value is "IP version 4 mode" if addr type specifies "IP version 4 mode", rest of address looks like: 5 bytes Reserved for allocation by IETF. A specific allocation might include any future "IP version 7" extension of the IP version 4 address space. 4 bytes IP version 4 address identifying the host 6 bytes Identifies the host. This is globally unique. May be dummy value for some IP version 4 hosts. 1 byte Identifies higher level protocol running over CLNP. (Uses values from current "assigned numbers" RFC) total: 20 bytes Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | From owner-Big-Internet@munnari.oz.au Wed Sep 16 06:39:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29307; Wed, 16 Sep 1992 06:39:16 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29303; Wed, 16 Sep 1992 06:39:11 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA09078 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Tue, 15 Sep 1992 16:38:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 15 Sep 1992 16:38:46 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 15 Sep 1992 16:38:46 -0400 Date: Tue, 15 Sep 1992 16:36:51 -0400 From: Dennis Ferguson Message-Id: <199209152036.AA45765@foo.ans.net> To: brian@dxcern.cern.ch Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) Cc: big-internet@munnari.oz.au Brian, > Well, as I _have_ said on the TUBA list (why do I keep typing TUNA?) > I believe that any plausible NSAPA plan for the Internet should > embed an encapsulation of IPv4 addresses to allow IP islands to > be interconnected by a CLNP infrastructure, with only the routers > having to know about it. I would be interested in hearing the rest of the plan, that is how would embedding IPv4 addresses allow IP islands to be interconnected by a CLNP infrastructure? It isn't clear to me that embedding the IPv4 addresses is either necessary or sufficient. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Wed Sep 16 17:17:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24335; Wed, 16 Sep 1992 17:17:36 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24330; Wed, 16 Sep 1992 17:17:23 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA14350 (5.65b/CWI-2.175); Wed, 16 Sep 1992 09:17:11 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA21839; Wed, 16 Sep 92 09:17:35 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA01495; Wed, 16 Sep 92 09:17:05 +0200 Message-Id: <9209160717.AA01495@dxcern.cern.ch> Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) To: Dennis Ferguson Date: Wed, 16 Sep 92 9:17:04 MET DST From: Brian Carpenter CERN-CN Cc: big-internet@munnari.oz.au In-Reply-To: <199209152036.AA45765@foo.ans.net>; from "Dennis Ferguson" at Sep 15, 92 4:36 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] Dennis, > > > Well, as I _have_ said on the TUBA list (why do I keep typing TUNA?) > > I believe that any plausible NSAPA plan for the Internet should > > embed an encapsulation of IPv4 addresses to allow IP islands to > > be interconnected by a CLNP infrastructure, with only the routers > > having to know about it. > > I would be interested in hearing the rest of the plan, that is how > would embedding IPv4 addresses allow IP islands to be interconnected > by a CLNP infrastructure? > > It isn't clear to me that embedding the IPv4 addresses is either necessary > or sufficient. > A very valid challenge. Sadly, I have no time to work out a transition plan in sufficient detail - I sincerely wish I had - so this is based on gut feeling about what would be in such a plan. It's one of the things TUBA has to produce. Embedding the IPv4 address in the NSAPA is only one way of carrying IP datagrams across CLNS (S for Service), and since there are clearly other ways, I cannot claim it is strictly _necessary_. There is an analysis in the TUBA drafts of the equivalence between fields of the IPv4 header and those in the CLNP header which suggests to me that the functionality can be mapped, i.e. mapping an IPv4 header into a CLNP header and back again should be _sufficient_ to give the same service to the IP user (TCP, UDP or whatever). In such a model routers have to translate between IP and CLNP formats. I am not a routing expert, but I don't think any new routing problems are introduced. Clearly not everybody (certainly not the originators of TUBA) like this approach. All I propose at this stage is to define an address format which would _allow_ this approach if it became desirable at some future date and for some subset of sites. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | From owner-Big-Internet@munnari.oz.au Thu Sep 17 16:34:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18389; Thu, 17 Sep 1992 16:34:44 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18378; Thu, 17 Sep 1992 16:34:06 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA17169; Wed, 16 Sep 92 23:33:39 -0700 Received: by us1rmc.bb.dec.com; id AA00964; Thu, 17 Sep 92 02:30:50 -0400 Message-Id: <9209170630.AA00964@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Thu, 17 Sep 92 02:30:51 EDT Date: Thu, 17 Sep 92 02:30:51 EDT From: Ross Callon To: dennis@ans.net Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: dennis@ans.net, big-internet@munnari.oz.au Subject: re: identifiers (was, NSAP AFI for IP) Let's try to think about at least one aspect of the ID selection without getting tied up in specific addressing proposals. > I think that pragmatically, to avoid operational difficulties, this ID > has to be assigned to hosts with a fair degree of permanence (the dynamic > host ID assignment some OSI implementions use depends on the existance > of a directory service capable of tracking possible changes to the host ID > as they occur, without service glitches. The Internet has no such directory > service). It probably needs enough internal structure to identify > organizational responsibility for the host (so the content of the routing > portion of the address can be freed of any semantics other than topological) > and perhaps needs to be structured such that the ID portion of the > address can be used for directory lookups by itself (to avoid the need > for the directory service to track mobile hosts, for example). I agree that IDs should be assigned with a fair amount of permanence. For example, I think that if I pick up my portable PC, get on an airplane, fly to a meeting, and plug in the portable at the local network there, then I think that the ID should stay the same regardless of where the meeting happens to be (for example, even if I have flown from Boston to Australia, and am at a facility owned by a different company, or have hooked up my portable to the network in my hotel room, or to the home network in the house that I happen to be staying in). In fact, the proposed requirement (in TUBA) that it must be possible to manually configure the ID is based on the desire to be able to pick up a temporary replacement portable while mine is in the repair shop, and still keep the same ID. Now, I don't understand your suggestion that the ID should have "internal structure to identify organizational responsibility for the host". This is something that makes sense in application level names or in directories maintained outside of the address. Why do you want organization information in the address which is outside of / in addition to topological information? Are you thinking that policy routing will be based on information stored in the ID? If so, then I fear that the IDs will get *quite* large. Now, I think that the desire to keep the same ID wherever I go anywhere in the world is semi-incompatible with the requirement that it be cheap and easy to look up addresses when you have only the ID. In particular, since I can go anywhere in the world and keep my same ID, this implies that the ID does not contain information which tells a casual observer where I am. Thus, either the location of the directory information has no relationship to where I am, or the location of the directory information has no relationship to the ID, or the information is massively replicated. The best alternative that I can think of for this is to have the ID to address lookup information maintained at a location which is independent of where my system is, but which depends upon what the ID is. Thus, if my system is normally located in Boston, but is currently on travel (with me) in Australia, its ID stays the same, and the location of the lookup is dependent upon the first "n" bytes of the ID. This might happen to cause the lookup information to be at some central site in Iceland or Japan. As long as the lookup is not done too frequently, this is fine. We could also maintain some number of local cache's. Thus, if my normal locations are at work and at home, and my current temporary location is on vacation in Hawaii, then I might have my ID to address and name lookup be cached at locations in all three locations. Thus, anyone who is in the next office (or next hotel room) will be able to lookup my address and name without going to some global resource. Also, it is not clear to me that it is *necessary* to be able to lookup the address and name given only the ID (or, at least not necessary for this lookup to be cheap and easy). Certainly this is not *required* for mobile operation (At least, it is not hard to come up with a proposal which works somewhat like the current IP mobile host proposals, at least to the extent that the packet starts out with an address which is based on the systems "normal" location. This would rely on there being some device located at the "normal" location which is capable of forwarding the packet and/or redirecting the source towards the "current" location). Yes, there are *other* proposals for dealing with mobile hosts which use ID to address lookups, but we don't need to use these. The only proposals that I have seen for dealing gracefully with permanent changes to addresses work rather similarly to the mobile host proposals, and thus again do not need a mapping from ID to address. For network management some folks have discussed the possibility of maintaining traffic statistics by ID (rather than by address). However, since this is based on monitoring actual traffic, the address should be capable of being monitored at the same time, even if the index into the network management traffic is the ID. Thus, I think that *any* method that allows for a global ID is compatible with ID to (address and name) lookups at some price (given that the authoritative location for the lookup is likely to be far flung from the associated system). I think that *any* ID scheme which allows IDs to stay the same regardless of changes to the global location of the system will cause such lookups to at least require access across a global Internet in some cases. Finally I think that local caches can cut down on the frequency with which "across the global Internet" lookups can be made. Ross From owner-Big-Internet@munnari.oz.au Thu Sep 17 23:49:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04291; Thu, 17 Sep 1992 23:49:23 +1000 (from owner-Big-Internet) Return-Path: Received: from CSEIC.SAIC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04274; Thu, 17 Sep 1992 23:49:09 +1000 (from carlberg@cseic.saic.com) Received: by cseic.saic.com (4.1/1.34) id AA28745; Thu, 17 Sep 92 09:44:58 EDT Date: Thu, 17 Sep 92 09:44:58 EDT From: carlberg@cseic.saic.com (Kenneth Carlberg) Message-Id: <9209171344.AA28745@cseic.saic.com> To: callon@bigfut.enet.dec.com, dennis@ans.net Subject: re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au Ross, [..desire to keep the same ID wherever I go anywhere in the world..] > The best alternative that I can think of for this is to have the ID to > address lookup information maintained at a location which is independent > of where my system is, but which depends upon what the ID is. Thus, if my > system is normally located in Boston, but is currently on travel (with me) > in Australia, its ID stays the same, and the location of the lookup is > dependent upon the first "n" bytes of the ID. > > We could also maintain some number of local cache's. Thus, if my normal > locations are at work and at home, and my current temporary location is > on vacation in Hawaii, then I might have my ID to address and name lookup > be cached at locations in all three locations. Keeping in mind that the *duration* of mobility is not something that can be easily answered, what is the criteria for timeout of a cache entry ? (...no answer required, just something to think about...) > Also, it is not clear to me that it is *necessary* to be able to lookup > the address and name given only the ID (or, at least not necessary for > this lookup to be cheap and easy). Certainly this is not *required* for > mobile operation (At least, it is not hard to come up with a proposal > which works somewhat like the current IP mobile host proposals, at least > to the extent that the packet starts out with an address which is based > on the systems "normal" location. > ...This would rely on there being some > device located at the "normal" location which is capable of forwarding > the packet and/or redirecting the source towards the "current" location). I agree. It is not *necessary* or *required* to lookup the address and name given only the ID. But I think there are some additional aspects and views that should be taken in consideration. First, lets clarify some things (or at least put them in a different perspective). I tend to favor two classifications of host movement: Mobility and Portability. A (simplified) example of Portability is much like the one you have described above - taking my portable computer to some other location, "plugging" it into a local network, and then doing something (like sending mail). When I'm finished, I shut down the portable and go my merry way. Mobility, on the other hand, goes beyond this in that end-to-end connections (such as those established for Telnet) are maintained as the host moves from one network to another. I like this distinction because it reflects the different responsibilities that must be addressed for each type of movement (or migration). I don't mean to imply that a solution for one type of movement cannot be a solution for another. On the contrary, the work that was originated by Columbia (and now advanced by the Mobile Hosts WG) is a fine example of how one solution resolves both problems. However, the question becomes what are the tradeoffs ? I believe you have made some good points that help address Portability. But I also think that Mobility (as described above) doesn't allow your arguements to be all encompassing. My 2 cents. -ken From owner-Big-Internet@munnari.oz.au Fri Sep 18 01:25:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08409; Fri, 18 Sep 1992 01:25:36 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08406; Fri, 18 Sep 1992 01:25:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19510; Thu, 17 Sep 92 11:25:23 -0400 Date: Thu, 17 Sep 92 11:25:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209171525.AA19510@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, dennis@ans.net Subject: re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Ross, an excellent summary. (I see no need for a Noelgram, even! :-) I am basically in complete agreement with you; the only minor point I could find to quibble about is this one: Now, I think that the desire to keep the same ID wherever I go anywhere in the world is semi-incompatible with the requirement that it be cheap and easy to look up addresses when you have only the ID. I'm not sure that this is *necesarily* incompatible. I don't see it as any harder to do the EID->address translation than it is to do DNS->address translations, and we do those all the time now, at a reasonable cost. I think your observation in the following paragraph ("best alternative..") is the appropriate one. Having said that, I agree *totally* that *once the system is fully deployed*, we *will not* be doing EID-> translations very often, any more than we do address-> translations now. So, I don't think the actual cost of allowing EID-> lookups is a big issue *in the long run*. Everyone should think very hard about the fact that Ross and Noel agree; this should say something! :-) Noel From owner-Big-Internet@munnari.oz.au Fri Sep 18 03:21:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12273; Fri, 18 Sep 1992 03:21:38 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12267; Fri, 18 Sep 1992 03:21:30 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA07615 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 17 Sep 1992 13:20:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 17 Sep 1992 13:20:44 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 17 Sep 1992 13:20:44 -0400 From: Dennis Ferguson Message-Id: <199209171718.AA50013@foo.ans.net> To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: (Your message of Thu, 17 Sep 92 02:30:51 EDT.) <9209170630.AA00964@us1rmc.bb.dec.com> Date: Thu, 17 Sep 92 13:18:48 -0500 Ross, > I agree that IDs should be assigned with a fair amount of permanence. [...] > In fact, the proposed requirement (in TUBA) that it must be possible to > manually configure the ID is based on the desire to be able to pick up > a temporary replacement portable while mine is in the repair shop, and > still keep the same ID. But what if your service contract is swap, instead of repair? Then you shouldn't manually configure anything, since the next owner of your portable may end up using the same ID. Of course you may want to configure the old ID despite this, since if people actually use the ID to identify your host you may find the new portable doesn't do things you need to until you find an administrator to change your DNS server and caches get flushed all over. But then you may find the new owner of the old hardware, who in good faith used the hardware ID, and you are making each other unhappy, so you lose either way. And of course there is entropy accumulating here too. Now that you've taken the trouble to configure an ID what would ever prompt you to unconfigure it? I think the end result will be that, as hardware comes and goes, more and more hosts will run with configured IDs that never get unconfigured (and which may overlap with new owners of said hardware). It is currently much easier to copy configuration from disk to disk then it is to change your address with the current directory service, and I can't see this changing in a hurry. My assertion is that if it is useful that IDs be fairly permanent (something you seem to agree with), then they should be permanent. And if the uniqueness of IDs is important to the reliability of the transport protocol then one shouldn't pick a scheme for assignment which may encourage people to do things which lead to non-unique IDs coming into use. Hardware is more ephemeral than hosts. > Now, I think that the desire to keep the same ID wherever I go anywhere > in the world is semi-incompatible with the requirement that it be cheap > and easy to look up addresses when you have only the ID. In particular, > since I can go anywhere in the world and keep my same ID, this implies > that the ID does not contain information which tells a casual observer > where I am. Thus, either the location of the directory information has > no relationship to where I am, or the location of the directory information > has no relationship to the ID, or the information is massively replicated. > > The best alternative that I can think of for this is to have the ID to > address lookup information maintained at a location which is independent > of where my system is, but which depends upon what the ID is. Thus, if my > system is normally located in Boston, but is currently on travel (with me) > in Australia, its ID stays the same, and the location of the lookup is > dependent upon the first "n" bytes of the ID. This might happen to cause > the lookup information to be at some central site in Iceland or Japan. As > long as the lookup is not done too frequently, this is fine. > > We could also maintain some number of local cache's. Thus, if my normal > locations are at work and at home, and my current temporary location is > on vacation in Hawaii, then I might have my ID to address and name lookup > be cached at locations in all three locations. Thus, anyone who is in the > next office (or next hotel room) will be able to lookup my address and > name without going to some global resource. I'm not sure I understand. Are you really suggesting that if your host is named something.dec.com when it is in Boston, and you take it to Australia on a trip, that you need to rename it to something.au when you get there to meet "the requirement that it be cheap and easy to look up addresses"? And if name-to-address and name-to-other-info queries aren't worth the cost and trouble of geographically optimization, isn't it a little unproductive to be worrying about where address-to-name lookups are answered? More than this, "local cache's" and information being "massively replicated" is already well supported by the DNS. When a host in Australia or Hawaii needs to know your name, or address, it may need to ask Boston the first time, but after that the information will be cached locally to answer future queries. So it already works the way you want. What the DNS doesn't do well, however, is change in a hurry. The DNS was designed based on the assumption that the information stored there would be fairly static, and that changes would be both infrequent and well planned. And this is the problem that allowing the ID to be used for address-to-name queries is meant to address. If your host acquires a new address in Australia, then address-to-name queries will not work unless someone in Australia also updates their name service to know about you (and until the secondary servers sync to the primary, and perhaps until other people's negative caches expire). And every time you move they'll have to go through the same process again, to delete your old entry and add a new one. If only the ID is used for lookups, however, the DNS need not change at all as you travel. All you need is something in Boston which knows where you are, to forward packets addressed to your home address on to you (this is needed in any case), and all will work fine. And while mobile hosts are interesting, this also has implications for other, more important, issues. From a routing perspective, CLNP only scales if people are willing to change their routing prefixes as topology changes. Otherwise, over time, we'll end up with the same problems we will have with IP, except with 20 byte addresses instead of four. Because of this, anything which lessens the dependence of applications (most certainly including the DNS) on the particular routing prefix in use is bound to have a positive effect on peoples' willingness to allow their routing prefix to changed, which in turn has a direct effect on the scalability of the protocol. The less that breaks when the routing prefix changes, the better. But the real issue here is not whether end-system ID's should be useful as DNS lookup keys (if you creating a number space to use for Internet end-system ID's from scratch, and assigning this to organizations, you would most certainly structure it so that it would be usable as keys for DNS lookups since there is no advantage in not doing so. And if you decided to use the IP address space for "starter" EIDs it would done already), but rather whether the IEEE identifiers associated with bits of hardware are useful as end-system ID's (since this number space is not administratively structured in a way that would be useful to the DNS) particularly when it has been decided that EIDs *must* be globally unique and *must* be trackable using the existing DNS rather than some futuristic lean, mean, dynamically changeable directory service . I think not. I'd be happy to debate the latter issue, since I think it is more fundamental. Dennis From owner-Big-Internet@munnari.oz.au Fri Sep 18 03:42:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13090; Fri, 18 Sep 1992 03:42:47 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13080; Fri, 18 Sep 1992 03:42:31 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA100928 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 17 Sep 1992 13:42:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 17 Sep 1992 13:42:03 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 17 Sep 1992 13:42:03 -0400 From: Dennis Ferguson Message-Id: <199209171740.AA67694@foo.ans.net> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: callon@bigfut.enet.dec.com, big-internet@munnari.oz.au Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: (Your message of Thu, 17 Sep 92 11:25:23 D.) <9209171525.AA19510@ginger.lcs.mit.edu> Date: Thu, 17 Sep 92 13:40:07 -0500 Noel, > Having said that, I agree *totally* that *once the system is fully > deployed*, we *will not* be doing EID-> translations very often, any ^^^^^^^^^^ > more than we do address-> translations now. So, I don't think the > actual cost of allowing EID-> lookups is a big issue *in the long > run*. > Everyone should think very hard about the fact that Ross and Noel > agree; this should say something! :-) It may be just me, but I am having difficulty figuring out what you are agreeing with Ross about. Ross' position, as I understand it, is that the ability to do EID-> lookups shouldn't exist, that we should be doing -> (i.e. using the whole NSAP instead of just the EID) lookups instead and that the DNS should be modified to track changes to the as they occur. While this is possible for CLNP NSAPs, where the is fairly rigidly structured and is available in every packet, if I translate this view to a NIMROD environment I think what you end up with is a mess. The issue is not how often EID-> lookups are done, it is whether one should be able to do such lookups at all. Dennis From owner-Big-Internet@munnari.oz.au Fri Sep 18 04:21:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14564; Fri, 18 Sep 1992 04:21:50 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14555; Fri, 18 Sep 1992 04:21:38 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA21302; Thu, 17 Sep 92 11:21:24 -0700 Received: by us1rmc.bb.dec.com; id AA16011; Thu, 17 Sep 92 14:18:43 -0400 Message-Id: <9209171818.AA16011@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Thu, 17 Sep 92 14:18:45 EDT Date: Thu, 17 Sep 92 14:18:45 EDT From: Ross Callon To: carlberg@cseic.saic.com Cc: big-internet@munnari.oz.au Apparently-To: carlberg@cseic.saic.com, big-internet@munnari.oz.au Subject: re: re: identifiers (was, NSAP AFI for IP) > Keeping in mind that the *duration* of mobility is not something that > can be easily answered, what is the criteria for timeout of a cache > entry ? (...no answer required, just something to think about...) Yes, this is the hard part -- or at least is the part that I don't yet have a complete answer to. My feeling is that a host that moves has to (i) know somehow whether the move is permanent or temporary; and (ii) if the move is temporary, go and tell something at its "home" location where it is, and also plan to do the same when it leaves; (iii) If the move is permanent, then it needs to tell the "mobile host server" at its old location that it has permanently moved away. Also, if a mobile host goes off line for a period of time, then it probably needs to tell someone not to bother trying to forward traffic. I don't see how the host can know whether the move is permanent of temporary without asking a human to tell it what is going on. Also, if we are going to use similar mechanisms for address changing, then probably a network operator will need to set up an "address change server" to intercept packets sent to the old address and forward them to the new address. Finally, for permanent address changes (whether due to permanent moving of a mobile host, or due to a topological change with topologically significant addresses) then over a period of time someone needs to gradually update the name service. Presumeably (i) this needs to be controlled by a human; and (ii) for temporary short term address changes, this should not be needed at all. I am sorry that I have not had enough time to look hard at the various IP mobile host schemes to see how much can be borrowed from them. > I tend to favor two classifications of host movement: > Mobility and Portability. A (simplified) example of Portability is much > like the one you have described above - taking my portable computer to > some other location, "plugging" it into a local network, and then doing > something (like sending mail). When I'm finished, I shut down the > portable and go my merry way. Mobility, on the other hand, goes beyond > this in that end-to-end connections (such as those established for > Telnet) are maintained as the host moves from one network to another. Yes, I also like this classification. I have been thinking of mobile hosts as including both types of things, but never thought to clearly specify the two as different functions which (hopefully) will use many of the same mechanisms. Ross From owner-big-internet@munnari.oz.au Fri Sep 18 05:11:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16216; Fri, 18 Sep 1992 05:11:13 +1000 (from owner-big-internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15156; Fri, 18 Sep 1992 04:38:20 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA10424); Thu, 17 Sep 92 13:38:12 CDT Received: by san-miguel.is.rice.edu (AA13500); Thu, 17 Sep 92 13:38:09 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9209171838.AA13500@san-miguel.is.rice.edu> Subject: Re: identifiers (was, NSAP AFI for IP) To: dennis@ans.net (Dennis Ferguson) Date: Thu, 17 Sep 92 13:38:08 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <199209171718.AA50013@foo.ans.net>; from "Dennis Ferguson" at Sep 17, 92 1:18 pm X-Mailer: ELM [version 2.3 PL11] Dennis Ferguson > > But what if your service contract is swap, instead of repair? Then you > shouldn't manually configure anything, since the next owner of your portable > may end up using the same ID. Hello? Who are we identifying here, the machine or the owner? I am coming to the realization that I think the ID components need at two things: 1. Provider chits. 2. Enduser chits. The Provider chits may include things like path routing and end station identification. The Enduser chits identify who should be receiving the information. It is not clear to me that it is feasible to put Enduser chits into the packets, although that would solve the problem of mobil hosts/nets. The privacy issues would keep the security folks in business for a LONG time. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Fri Sep 18 05:17:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16388; Fri, 18 Sep 1992 05:17:22 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16372; Fri, 18 Sep 1992 05:17:08 +1000 (from dave@sword.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA18008; Thu, 17 Sep 92 15:20:08 EDT Received: by sword.bellcore.com;id 9209171916.AA22361 Message-Id: <9209171916.AA22361@sword.bellcore.com> Date: Thu, 17 Sep 92 15:16:22 EDT From: dave@sword.bellcore.com (Dave Piscitello) To: dave@sabre.bellcore.com, dennis@ans.net Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) Cc: big-internet@munnari.oz.au Dennis, I'm forever catching up, but I think your assessment of RFC1237 is the most complete yet. I agree that a global unique ID is a good thing, and a new AFI or AFI=6523ICD would work well (your point 3, expanded); any other pearls in your pockets? From owner-Big-Internet@munnari.oz.au Fri Sep 18 07:35:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20971; Fri, 18 Sep 1992 07:35:58 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20961; Fri, 18 Sep 1992 07:35:34 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA29556; Thu, 17 Sep 92 14:35:13 -0700 Received: by us1rmc.bb.dec.com; id AA22162; Thu, 17 Sep 92 17:32:30 -0400 Message-Id: <9209172132.AA22162@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Thu, 17 Sep 92 17:32:31 EDT Date: Thu, 17 Sep 92 17:32:31 EDT From: Ross Callon To: dennis@ans.net Cc: big-internet@munnari.oz.au Apparently-To: dennis@ans.net, big-internet@munnari.oz.au Subject: re: Re: identifiers (was, NSAP AFI for IP) > Ross' position, as I understand it, is that the ability to do EID-> > lookups shouldn't exist, that we should be doing > -> (i.e. using the whole > NSAP instead of just the EID) lookups instead and that the DNS should be > modified to track changes to the as they > occur. While this is possible for CLNP NSAPs, where the > is fairly rigidly structured and is available > in every packet, if I translate this view to a NIMROD environment I think what > you end up with is a mess. Well, this is not quite Ross' position as I understand it (actually, my position on whether NIMROD is a mess is not yet determined -- Noel and I haven't gone through enough San Gria yet :-). However, my position may have adapted over time (mostly in response to our discussions on this list, and the TUBA list). My proposal is that EIDs should remain the same when I move my system ANYWHERE in the world (or even out of the world, if relevant). I believe that this implies that EID--> lookups are not cheap. Thus, we should not plan on having EID--> lookups be a normal part of packet forwarding. Also, given that the EID needs to be the same where ever in the world we move a system, the EID will end up having no useful correlation between EID structure and the location of the system. Also, any proposal which requires to table lookups probably needs to be very clear how large the tables will need to be, how the information is stored, and how the lookups are accomplished. However, I am beginning to lean towards the belief that EID to lookups might be needed in some cases, thus we should not preclude the possibility. This would seem to imply that we need to steal an idea from Paul Tsuchiya's old Landmark Routing proposal, and have the location of the information be based on the high order part of the EID, without concern for where the system actually is. Ross From owner-Big-Internet@munnari.oz.au Fri Sep 18 08:20:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22321; Fri, 18 Sep 1992 08:20:54 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22316; Fri, 18 Sep 1992 08:20:42 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA01688; Thu, 17 Sep 92 15:20:06 -0700 Received: by us1rmc.bb.dec.com; id AA23248; Thu, 17 Sep 92 18:17:09 -0400 Message-Id: <9209172217.AA23248@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Thu, 17 Sep 92 18:17:10 EDT Date: Thu, 17 Sep 92 18:17:10 EDT From: Ross Callon To: dennis@ans.net Cc: big-internet@munnari.oz.au Apparently-To: dennis@ans.net, big-internet@munnari.oz.au Subject: re: Re: identifiers > But what if your service contract is swap, instead of repair? Then you > shouldn't manually configure anything, since the next owner of your portable > may end up using the same ID. Of course you may want to configure the > old ID despite this, since if people actually use the ID to identify your > host you may find the new portable doesn't do things you need to until > you find an administrator to change your DNS server and caches get flushed > all over. But then you may find the new owner of the old hardware, who in > good faith used the hardware ID, and you are making each other unhappy, so > you lose either way. For some reason this reminds me of automotive license plates. Does the license plate stay with the car when it is sold, stay with the person, or go away and never get used again? I have lived in enough places to see all three in use. > My assertion is that if it is useful that IDs be fairly permanent (something > you seem to agree with), then they should be permanent. And if the uniqueness > of IDs is important to the reliability of the transport protocol then one > shouldn't pick a scheme for assignment which may encourage people to do > things which lead to non-unique IDs coming into use. Hardware is more > ephemeral than hosts. I agree that IDs need to be fairly permanent, and unique. But what does this mean? Are you proposing that IDs should be permanently assigned to people, instead of being permanently assigned to systems? > I'm not sure I understand. Are you really suggesting that if your host is > named something.dec.com when it is in Boston, and you take it to Australia > on a trip, that you need to rename it to something.au when you get there > to meet "the requirement that it be cheap and easy to look up addresses"? > And if name-to-address and name-to-other-info queries aren't worth the > cost and trouble of geographically optimization, isn't it a little > unproductive to be worrying about where address-to-name lookups are > answered? Actually, I am proposing that neither the name, nor the address returned by a name server, nor the ID, changes when the host moves. What does change is the address actually used by the system. Thus, when a different system tries to reach you, it goes to the name server and looks up your address, and gets your normal permanent address. It then sends a packet to your normal address, which gets forwarded to your current address by a "mobile host server". You receive the packet and respond. The correspondant system knows that the packet is from you because the ID is the same. It also knows to start sending packets to your new (temporary) location either because it picked up the new address from the incoming packet, or because it received a redirect message sent from the mobile host server (which approach to use is open to debate). > More than this, "local cache's" and information being "massively > replicated" is already well supported by the DNS. When a host in Australia > or Hawaii needs to know your name, or address, it may need to ask Boston > the first time, but after that the information will be cached locally > to answer future queries. So it already works the way you want. Well, this would seem to say that a lookup via DNS and DNS name is no harder than a lookup of a Unique ID. However, DNS has a hierarchical structure which implies that the information about my system is located in a data structure which is stored somewhere near my system. This implies that someone in my building, in order to look up my address based on my name, does not need to go outside of this building. Similarly, someone who is located in the next network over, only needs to go a small distance to look up my address. Thus, the person in Australia who has to look up my address (given my name) does indeed have to send a packet to the US the first time, but he does this only when he is actually trying to talk to someone in the US. With current DNS and current DNS names, if a person in australia is trying to talk to someone in australia, then they can lookup the address by probing a name service in australia. In contrast, let's suppose that IDs are assigned to people, and are tatooed on an inconspicuous part of our bodies at birth. Suppose that we then just type our Human-ID into our personal systems, plus a personal system demultiplexing byte (allowing up to 256 machines for every human on the face of the earth -- probably enough in the short term). In this case, my ID on my system here in Littleton would have some sort of hierarchical structure based on where and when I was born (Northern Quebec, longer ago than I would like :-). The person in the next office over would have an ID based on where and when he was born (India, about the same time). Thus, the IDs would have a structure which has no relation to where the system is. This implies that for someone to lookup my ID, they may have to go anywhere in the world. My concern is that the worldwide Internet is likely to get large enough that you don't want to go "anywhere in the Internet" to look up an ID every time you want to send a message to someone in your local network. > What the DNS doesn't do well, however, is change in a hurry. The DNS > was designed based on the assumption that the information stored there > would be fairly static, and that changes would be both infrequent and > well planned. Yes, I think that we all agree on this part. > And this is the problem that allowing the ID to be used > for address-to-name queries is meant to address. Here is where we are disconnecting. I understand that allowing an ID to be used for ID to address to name queries is one way to handle this problem. However IT IS NOT THE ONLY WAY. I don't think that it is the best way. > If your host acquires > a new address in Australia, then address-to-name queries will not work > unless someone in Australia also updates their name service to know about > you (and until the secondary servers sync to the primary, and perhaps > until other people's negative caches expire). And every time you move > they'll have to go through the same process again, to delete your old > entry and add a new one. If only the ID is used for lookups, however, > the DNS need not change at all as you travel. All you need is something > in Boston which knows where you are, to forward packets addressed to > your home address on to you (this is needed in any case), and all will > work fine. Ah, here again is where we are disconnecting. You are assuming that each system has only one address at any point in time. I am assuming that mobile hosts have two addresses: One which identifies the hosts normal "home" location, another which identifies where the system actually is currently. ] Hmmmmmmmm, you do have a good point here: For the address to name lookup to work, you need to have the host's permanent home location. The temporary location is really only good for getting a packet to the system, and not much else. > And while mobile hosts are interesting, this also has implications for > other, more important, issues. From a routing perspective, CLNP only > scales if people are willing to change their routing prefixes as topology > changes. Otherwise, over time, we'll end up with the same problems we > will have with IP, except with 20 byte addresses instead of four. Because > of this, anything which lessens the dependence of applications (most > certainly including the DNS) on the particular routing prefix in use > is bound to have a positive effect on peoples' willingness to allow their > routing prefix to changed, which in turn has a direct effect on the > scalability of the protocol. The less that breaks when the routing > prefix changes, the better. Yes, we all agree that we need to make address changes easy. I also agree that this may be more important than hosts which are actually moving. Once again, I claim that there is another way to do this which I believe is simpler and more efficient than sending out a packet with only an ID (and no complete address) and then trying to do an ID-to-address lookup in the router's forwarding path. > But the real issue here is ... whether the IEEE identifiers > associated with bits of hardware are useful as end-system ID's (since > this number space is not administratively structured in a way that would > be useful to the DNS) particularly when it has been decided that EIDs > *must* be globally unique and *must* be trackable using the existing DNS > rather than some futuristic lean, mean, dynamically changeable directory > service . I think not. I'd be happy to debate the latter issue, since > I think it is more fundamental. Yes, I agree that this is the other real issue. My claim is that if we leave the ID the same as systems move, then they are going to end up being just as flat as the IEEE ID space. Thus I think that there are probably three options: 1. Change the ID whenever a system moves. 2. Leave the ID the same for a while, but slowly change IDs over time so that systems which move permanently have to change their ID. 3. Admit that IDs are going to be "topologically flat", and learn to live with this unfortunate fact. I think that 1 defeats the point of having an ID. I suspect that 3 is going to end up being simpler than 2. If we accept that IDs are going to end up being flat, then we are left with a few nits relating to whether IDs are assigned to people or machines, and what to do when I either sell my used machine to someone else and buy a new model, or when I temporarily take my laptop in to be fixed, or when I throw away my old machine. Ross From owner-Big-Internet@munnari.oz.au Fri Sep 18 17:18:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14328; Fri, 18 Sep 1992 17:19:25 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14299; Fri, 18 Sep 1992 17:18:53 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA08915; Fri, 18 Sep 1992 09:11:05 +0200 Message-Id: <199209180711.AA08915@mitsou.inria.fr> To: Dennis Ferguson Cc: Ross Callon , big-internet@munnari.oz.au Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: Your message of "Thu, 17 Sep 92 13:18:48 CDT." <199209171718.AA50013@foo.ans.net> Date: Fri, 18 Sep 92 09:10:44 -0400 From: Christian Huitema X-Mts: smtp >And while mobile hosts are interesting, this also has implications for >other, more important, issues. From a routing perspective, CLNP only >scales if people are willing to change their routing prefixes as topology >changes. Otherwise, over time, we'll end up with the same problems we >will have with IP, except with 20 byte addresses instead of four... This is a very valid point. In all the proposal we see, one or another form of source routing is proposed for handling situations where "hierarchical routing" is inappropriate. For example, it is quite reasonable to access a mobile host by source routing the packets through the particular hub to which this host is "connected" at a given time; changing the hub address during a connection's time is relatively easy. The same techniques can be used for some forms of policy routing, etc. If you look at these cases, you end up with a frequent use of 2 intermediate host addresses -- one for exiting the local domain, one for locating the remote access hub. And there are cases where you need more, e.g. if you want to follow a particular route on which resources have been reserved, or if you want to specify a particular transit network. Let say that 5 or 6 intermediates will not be too uncommon. In those situations, 20 bytes addresses are clearly suboptimal. If I was using Marshall silent(T) Rose vocabulary, I would say that this 20 bytes long addressing plan is a ponderous overkill, one more example of the triumph of politics over technology... This is, IMHO, a sufficient reason to discard the current NSAP addressing plan. This is also in fact one reason why, in the ill fated Kobe meeting, several IAB members insisted that we do not endorse the current NSAP plans even if we were to adopt the CLNP formats. Christian Huitema From owner-Big-Internet@munnari.oz.au Fri Sep 18 19:00:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18140; Fri, 18 Sep 1992 19:00:11 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209180900.18140@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18135; Fri, 18 Sep 1992 19:00:04 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 18 Sep 1992 09:59:34 +0100 To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: identifiers In-Reply-To: Your message of "Thu, 17 Sep 92 18:17:10 EDT." <9209172217.AA23248@us1rmc.bb.dec.com> Date: Fri, 18 Sep 92 09:59:29 +0100 From: Zheng Wang >Yes, I agree that this is the other real issue. My claim is that if >we leave the ID the same as systems move, then they are going to end >up being just as flat as the IEEE ID space. Thus I think that there >are probably three options: I agree that if IDs dont change when hosts move, any structure in the ID becomes less useful and you may end up doing a lookup from a remote site for a local host. But if we dont change IDs, it is inevitable. I think what we should do in this case is trying to accommodate common situations. Encoding IDs to identify a permanent location may be a reasonable approach. After all, most machines are likely to stay at one place for their lifetime (5 year?). Another approach may be to allow a host to have multiple IDs. When a host moves to another place rather permanently (eg. sold to another company), it may have a second ID to allow gradual changeover to the new ID. People do this with their email addresses. Cheers Zheng From owner-Big-Internet@munnari.oz.au Fri Sep 18 21:55:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24238; Fri, 18 Sep 1992 21:55:29 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24235; Fri, 18 Sep 1992 21:55:23 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA34849 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Fri, 18 Sep 1992 07:53:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 18 Sep 1992 07:53:40 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 18 Sep 1992 07:53:40 -0400 From: Dennis Ferguson Message-Id: <199209181151.AA46750@foo.ans.net> To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: (Your message of Thu, 17 Sep 92 17:32:31 EDT.) <9209172132.AA22162@us1rmc.bb.dec.com> Date: Fri, 18 Sep 92 07:51:44 -0500 Ross, > My proposal is that EIDs should remain the same when I move my > system ANYWHERE in the world (or even out of the world, if > relevant). I believe that this implies that EID--> > lookups are not cheap. Thus, we should not plan on having > EID--> lookups be a normal part of packet forwarding. > Also, given that the EID needs to be the same where ever in the > world we move a system, the EID will end up having no useful > correlation between EID structure and the location of the system. Ah, on this we agree, I think. All I'm interested in is that when you do the TUBA equivalent of looking up the PTR record for 1.1.1.128.in-addr.arpa to find the name of the host, you are able to do this with just the EID rather than having to include the routing portion of the NSAP. I would hope packet forwarding would remain well independent of the DNS. > However, I am beginning to lean towards the belief that EID to > lookups might be needed in some cases, thus we > should not preclude the possibility. This would seem to imply that > we need to steal an idea from Paul Tsuchiya's old Landmark Routing > proposal, and have the location of the information be based on the > high order part of the EID, without concern for where the system > actually is. Exactly. Dennis From owner-Big-Internet@munnari.oz.au Fri Sep 18 23:10:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26721; Fri, 18 Sep 1992 23:10:34 +1000 (from owner-Big-Internet) Return-Path: Received: from xap.xyplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26718; Fri, 18 Sep 1992 23:10:20 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Fri, 18 Sep 92 09:09:01 -0500 Received: by mjm.xyplex.com (4.1/SMI-4.1) id AA20808; Fri, 18 Sep 92 09:11:05 EDT Date: Fri, 18 Sep 92 09:11:05 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9209181311.AA20808@mjm.xyplex.com> To: big-internet@munnari.oz.au Subject: re: routing to mobile/portable hosts I suppose that a plausible model for mobile hosts could be "call forwarding." In this scenario, it would be the host's responsibility to inform some central authority of its new location, or at least send a "hold messages until I call in" notification. But, I think everyone here is assuming some sort of hierachial distribution of routing information, so that the central authority isn't beaten up by each and every routing request in the universe. If so, the key question IMHO isn't how you find out where the host is now, but how you purge stale route information that is cached in the lower levels of your hierarchy, without unduly burdening the network with update messages. Milan J. Merhar milan@eng.xyplex.com Phone:(508)264-9900 330 Codman Hill Rd. Boxborough, MA 01915 Fax:(508)264-9930 From owner-Big-Internet@munnari.oz.au Sat Sep 19 00:20:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00559; Sat, 19 Sep 1992 00:22:00 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00530; Sat, 19 Sep 1992 00:20:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29232; Fri, 18 Sep 92 10:20:08 -0400 Date: Fri, 18 Sep 92 10:20:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181420.AA29232@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, dennis@ans.net Subject: Re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Hmm, I think I have to wake up here. (This is *not* about Nimrod; again, everyone shoudl *really* read this one.) In my view, people need to keep one thing *crystal clear* in the front of the minds in this debate, which is "what are we naming with these identifiers". So far, I don't recall any serious debate with Dave Oran's position (which I adopted the instant I heard it :-), which is that the identifiers name the *endpoints of a network transaction*; i.e. something like the two participants in a TCP connection. If this is true, then the only things you are really talking about are: i) how volatile *should* the binding between these names and other names in the systems (such as DNS names, network addresses) be, and ii) is this level of volatility easy to engineer in the name binding mechanisms (such as DNS, etc), or should we build extra frobs onto the architecture (such as the 'base station' stuff) to deal with the fact that the *desired* level of volatility cannot be achieved by the name-binding mechanism. If you don't understand what this is saying, you need to read it again until you do, and if you still can't, ask a question on the list, since probably others don't understand it either. Anyway, once you start to think about things in these terms, it's pretty easy to answer some of the other questions that I see going back and forth. Q: Should the ID stay with the hardware? A: Doesn't really matter; it depends on how flexible the name binding mechanism is, and how much aggravation you want with ID assignement. Ideally, each box would have it's own ID built in, and it you swap boxes, you update the directory which maps DNS names to ID's. You *could* keep the same ID, and configure the box to know that, but this is less ideal, since it's work, and open to confusion. It's another tradeoff; which is worse, the cost of building in the dynamicity, or the ugly kludges you have to go if the name binding isn't dynamic enough? Not a hard guess as to which I prefer! Note: The world won't *really* stop if two boxes, at different addresses, have the same ID: all it means is you can't do the mapping from ID-> uniquely. Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 00:49:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01396; Sat, 19 Sep 1992 00:49:19 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01390; Sat, 19 Sep 1992 00:49:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29702; Fri, 18 Sep 92 10:49:09 -0400 Date: Fri, 18 Sep 92 10:49:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181449.AA29702@ginger.lcs.mit.edu> To: dennis@ans.net, jnc@ginger.lcs.mit.edu Subject: Re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu It may be just me, but I am having difficulty figuring out what you are agreeing with Ross about. I guess the point of Ross' that I heavily agreed with was his feeling that ID's not have any structure that tells you anything, but I also agreed with: i) his point that the id-> mapping is (*thus necessarily*, in my opinion) maintained at a place which has nothing to do with either the location of the system (topologically or organizationally) ii) his point that you shouldn't need to do the id-> mapping iii) his point that one way to do mobile host support, by changing name&id->address mappings, uses the same mechanism as the one for dealing gracefully with permanent changes to addresses. iv) all the points in his last paragraph Ross' position, as I understand it, is that the ability to do EID-> lookups shouldn't exist, that we should be doing -> I'm not sure if this *is* Ross' position, but I certainly don't agree with it. I see three *completely separate* namespaces: i) string names organized along an organizational hierarchy (i.e. DNS/X.mumble type names), the 'Hostname'. ii) 'shortish' fixed length unique 'random' binary identifiers for 'endpoints' (i.e. 48/64/96 bit IEEE like numbers), the 'Identifier'. iii) variable length, variable number of levels, topologically *only* organized names for network attachment points, the 'Address'. You'd be able to translate back and forth, but any one serves as a unique key (although some might map to multiple entries *in either direction*; e.g a flock of mobile process Identifiers might be at the same address, a service named in the DNS might have two Identifier, etc). The most common translation would be Hostname->Identifier & Address. Once the system is up, this is pretty much the only one you'd do. Identifier-> and Address-> would be used for diagnostics, etc. In an interim deployment period, Identifier->Address mappings might be needed for interoperable deployment. While this is possible for CLNP NSAPs, where the is fairly rigidly structured and is available in every packet, if I translate this view to a NIMROD environment I think what you end up with is a mess. Huh? The only thing *guaranteed* to be in every Nimrod packet are the source and destination Identifiers, which are well structured. Nimrod addresses are well structured too. What's the problem? Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 00:58:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01601; Sat, 19 Sep 1992 00:59:08 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01594; Sat, 19 Sep 1992 00:58:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29854; Fri, 18 Sep 92 10:57:11 -0400 Date: Fri, 18 Sep 92 10:57:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181457.AA29854@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, carlberg@cseic.saic.com Subject: re: re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu My feeling is that a host that moves has to ... (ii) if the move is temporary, go and tell something at its "home" location where it is, and also plan to do the same when it leaves; (iii) If the move is permanent, then it needs to tell the "mobile host server" at its old location that it has permanently moved away. Ross, this is the US mail model. However, is it really cleaner and less expensive than the model where you tell the sources directly that the destination has moved? I mean, if I'm driving to my friend's house, and he has moved, I don't drive to his old house first to get directions! I don't see how the host can know whether the move is permanent of temporary without asking a human to tell it what is going on. This is useless linguistics. Almost all hosts move sooner or later; some move more often, and stay shorter times, is all. How do you tell what the dividing line is? One hour? One day? One week? One month? It's not as hard as the mobile/portable distinction (where this *is* a noticeable boundary; whether open connections stay open or not). This is why I like a model where we *don't* have separate mechanisms for portable hosts and address changes. Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 01:04:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01730; Sat, 19 Sep 1992 01:04:56 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01727; Sat, 19 Sep 1992 01:04:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00238; Fri, 18 Sep 92 11:04:47 -0400 Date: Fri, 18 Sep 92 11:04:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181504.AA00238@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, dennis@ans.net Subject: Re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I am coming to the realization that I think the ID components need at two things: Not a bad idea; allows id allocation for mobile processes easily. The Provider chits may include things like path routing Barf. If it includes a route (or even an address :-) it's more than a unique identifier of one end of a network connection. Why do you feel it's necessary to overload these functions onto the identifier? It is not clear to me that it is feasible to put Enduser chits into the packets Damn well better be; how do you distinguish between packets to two different client otherwise? The privacy issues would keep the security folks in business for a LONG time. Yes, but then again, security in the network is pretty much a swiss cheese anyway. We need to securely relate something like a private key to each identifier. Hmm, maybe the thing to do is make the locally allocated part of the identifier a private key... (Aiieeeee, 128 bit Identifiers :-). Noel From owner-big-internet@munnari.oz.au Sat Sep 19 01:18:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02026; Sat, 19 Sep 1992 01:18:28 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00531; Sat, 19 Sep 1992 00:20:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29235; Fri, 18 Sep 92 10:20:22 -0400 Date: Fri, 18 Sep 92 10:20:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181420.AA29235@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, dennis@ans.net Subject: Re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu And if name-to-address and name-to-other-info queries aren't worth the cost and trouble of geographically optimization, isn't it a little unproductive to be worrying about where address-to-name lookups are answered? Excellent observation. What the DNS doesn't do well, however, is change in a hurry. The DNS was designed based on the assumption that the information stored there would be fairly static, and that changes would be both infrequent and well planned. True. However, note that most hosts which can be Mobile or Portable (great terminology!) *know that in advance*. You can use this knowledge to adapt the behviour of the DNS to something reasonable; nodes which are either should make sure that their mapping are given out with short (zero if they know they are about to move) cache lifetimes. This shouldn't be much more costly than the system now, since only leaf nodes will not be cached remotely; I don't imagine servers (even for bottom level zones) will be moving much. Of course, we still need to solve the problem of how to reliably and securely update the DNS, but that shouldn't be a killer. And this is the problem that allowing the ID to be used for address-to-name queries is meant to address. Sorry, I don't agree that, in the long run, we should be doing ID-> mappings as anything but a diagnostic. We may do it as a kludge to get a new routing archietecture deployed, but that's it, as far as I can see. They are just short, unique, random numbers; they aren't *organized* to do anything with, including looking them up. All you need is something in Boston which knows where you are, to forward packets addressed to your home address on to you (this is needed in any case), and all will work fine. This is far more expensive, in system terms, than forcing people to do the name->id->address mapping more often (to get the current truth), or sending the ends of all open connections new id->address mappings (yes, I know there are still problems with datagram things like NFS), in the case of mobile/portable hosts. Sure, it spreads the knowledge of the dynamicity more widely, but so what? It gives the endpoints more information about the true state of reality, too. From a routing perspective, CLNP only scales if people are willing to change their routing prefixes as topology changes. Yes, *yes*, YES! Everyone should engrave this on their forehead. Another reason to make a more dynamic mapping from name->id->address supported! anything which lessens the dependence of applications ... on the particular routing prefix in use is bound to have a positive effect on peoples' willingness to allow their routing prefix to changed, which in turn has a direct effect on the scalability of the protocol. The less that breaks when the routing prefix changes, the better. Yup. Another for the forehead, and another reason to identify things in terms of names and id's, not addresses, and to make the mapping more dynamic. particularly when it has been decided that EIDs *must* be globally unique and *must* be trackable using the existing DNS rather than some futuristic lean, mean, dynamically changeable directory service Huh? I don't recall agreement on this latter point at all (that EID's must be trackable, that is). I would imagine that for mobile processes, etc, you'd want to be able to cons them up and throw them away. Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 01:21:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02089; Sat, 19 Sep 1992 01:21:44 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02085; Sat, 19 Sep 1992 01:21:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00403; Fri, 18 Sep 92 11:21:34 -0400 Date: Fri, 18 Sep 92 11:21:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181521.AA00403@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, dennis@ans.net Subject: re: Re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu actually, my position on whether NIMROD is a mess is not yet determined -- Noel and I haven't gone through enough San Gria [sic] yet I have this problem with a lot of people. I remain utterly, absolutely convinced that if people *really understand* Nimrod (the routing architecture, that is, not the deployment plan with no new packet format, which is a separate thing), they will be just as convinced as I am that it's the *only* way to go, not in the sense that it's better engineering (because that's not done yet :-), but that the basic line of attack is the only *possible* one. The problem seems to be twofold. First, it's very *different*. (I sometimes think to *really* get it, you have to take your head off, turn it upside down, remove the insides and put them on the outside, rethread with a British reverse Whitworth thread, and reinstall.) Second, there's a *lot* of stuff (like architectural principles for large systems, and fundamental analysis of large scale routing) lurking *behind* the bland surface details, and the time investment to shovel the whole thing in is too large for most of you busy people. Sigh.... I continue to push the boulder uphill. My proposal is that EIDs should remain the same when I move my system ANYWHERE in the world I agree, it's dangerous to start changing them. Thus, we should not plan on having EID--> lookups be a normal part of packet forwarding. Not to a distributed database as a part of handling every packet in a flow, no. However, I assume you're not precluding using the EID's as cache tags on forwarding cache entries in the routers, right? Also, given that the EID needs to be the same where ever in the world we move a system, the EID will end up having no useful correlation between EID structure and the location of the system. Also, any proposal which requires to table lookups probably needs to be very clear how large the tables will need to be, how the information is stored, and how the lookups are accomplished. Yes to both! Add to the second, how dynanmic changes to the mappings are allowed to be. Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 01:40:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02653; Sat, 19 Sep 1992 01:40:40 +1000 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02650; Sat, 19 Sep 1992 01:40:32 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA25682); Fri, 18 Sep 92 10:40:24 CDT Received: by san-miguel.is.rice.edu (AA14115); Fri, 18 Sep 92 10:40:21 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9209181540.AA14115@san-miguel.is.rice.edu> Subject: Re: identifiers (was, NSAP AFI for IP) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 18 Sep 92 10:40:20 CDT Cc: big-internet@munnari.oz.au, bmanning@is.rice.edu (William Manning) In-Reply-To: <9209181504.AA00238@ginger.lcs.mit.edu>; from "Noel Chiappa" at Sep 18, 92 11:04 am X-Mailer: ELM [version 2.3 PL11] Whoops. Made a big mess there. Let me define some terms here: Provider chits: Those bits that a service provider supplies, be it IEEE 48bit addresses, circuit ids, cell ids, IPV4 addresses, Route Fragments, AFIs, etc. I think that some of these may be globally unique, while some may not. These are things that define the infrastructure, including the workstation. Enduser chits: The permanent, global/chronological unique ID assigned to each individual that identifies them as separate from everyone else. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Sat Sep 19 01:51:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02931; Sat, 19 Sep 1992 01:51:20 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02919; Sat, 19 Sep 1992 01:51:01 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01164; Fri, 18 Sep 92 11:49:59 -0400 Date: Fri, 18 Sep 92 11:49:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181549.AA01164@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, dennis@ans.net Subject: re: Re: identifiers Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu However, DNS has a hierarchical structure which implies that the information about my system is located in a data structure which is stored somewhere near my system. Tilt! DNS make *No Such Assumption*. We needed *some* structure to avoid having one giant flat translation table, which would be difficult to manage (no duplicate names), engineer (one giant databese), etc. Almost any hierarchical structure would do; we picked an organizational heirachy for administrative *and* human convenience. It's much easier for me to remember bigfut.enet.dec.com as your machine than it's network topological association, 'cause I know you work for DEC and DEC is a company. This implies that someone in my building, in order to look up my address based on my name, does not need to go outside of this building. Similarly, someone who is located in the next network over, only needs to go a small distance to look up my address. There's no guarantee *whatsoever* that the server(s) which hold the *mappings* for DNS name A.B.C.D is *anywhere* near the host *named* A.B.C.D. It usually is, but the system would work fine even if it wasn't. It's good engineering to put them close together, to minimize traffic, and for fate sharing (who cares if you can't get to the name server for A.B.C.D if you can't get to A.B.C.D itself either), but it's not necessary. The structure in DNS is purely administrative, not topological. This implies that for someone to lookup my ID, they may have to go anywhere in the world. So? If you don't do it often, why is this a problem? (I agree, keeping the mapping databese up to date could be a hassle, and is probably the single biggest hurdle. Probably some organization would have to do all of them, like the white pages now.) My concern is that the worldwide Internet is likely to get large enough that you don't want to go "anywhere in the Internet" to look up an ID every time you want to send a message to someone in your local network. Why on *earth* would we be doing this, though? You'd be mostly doing Hostname -> Identifier & Address mappings, and using the Identifier returned there to thereafter uniquely identify your packets as going to that destination, to avoid putting these long, grubby Addresses (or even worse, source routes thereof :-) into packets. > What the DNS doesn't do well, however, is change in a hurry. Yes, I think that we all agree on this part. So? Let's fix it, if having a more dymanic DNS is the *best way* to provide the capabilities we want to provide. Yes, we all agree that we need to make address changes easy. I also agree that this may be more important than hosts which are actually moving. Once you understand that topology changes mean address changes, this becomes clear. All hosts aren't mobile/portable, but the network topology is going to change in ways which affect all hosts' addresses. Once again, I claim that there is another way to do this which I believe is simpler and more efficient than sending out a packet with only an ID (and no complete address) and then trying to do an ID-to-address lookup in the router's forwarding path. Why on *earth* would you do this? 3. Admit that IDs are going to be "topologically flat", and learn to live with this unfortunate fact. I think that 1 defeats the point of having an ID. I suspect that 3 is going to end up being simpler than 2. Yes! Ah, now I feel *much* better. Now, if everyone else agrees, we'll really be making progress... If we accept that IDs are going to end up being flat, then we are left with a few nits relating to whether IDs are assigned to people or machines, and what to do when I either sell my used machine to someone else and buy a new model, or when I temporarily take my laptop in to be fixed, or when I throw away my old machine. ID's are assigned to endpoints. Whether you allow any of the things you talk about is an engineering tradeoff of the costs of doing one thing versus the cost of doing another, and in general, I prefer the clean engineering. I.e. don't reassign endpoint id's to something else; get a new one if you have to. In the long run, it's cheaper (I mean, that's the definition of 'clean engineering', right?) Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 02:01:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03187; Sat, 19 Sep 1992 02:01:49 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209181601.3187@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03184; Sat, 19 Sep 1992 02:01:43 +1000 (from jcurran@nic.near.net) To: big-internet@munnari.oz.au Subject: Re: identifiers (was, NSAP AFI for IP) Date: Fri, 18 Sep 92 12:01:34 -0400 From: John Curran Apologies... I directed my response to tuba, not big-internet. /John ------- Forwarded Message To: Dennis Ferguson Cc: Ross Callon , tuba@lanl.gov Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: Your message of Fri, 18 Sep 92 07:51:44 -0500. <199209181151.AA46750@foo.ans.net> Date: Fri, 18 Sep 92 10:53:54 -0400 From: John Curran - -------- From: Dennis Ferguson Subject: Re: identifiers (was, NSAP AFI for IP) Date: Fri, 18 Sep 92 07:51:44 -0500 Ross, > My proposal is that EIDs should remain the same when I move my > system ANYWHERE in the world (or even out of the world, if > relevant). I believe that this implies that EID--> > lookups are not cheap. Thus, we should not plan on having > EID--> lookups be a normal part of packet forwarding. > Also, given that the EID needs to be the same where ever in the > world we move a system, the EID will end up having no useful > correlation between EID structure and the location of the system. Ah, on this we agree, I think. All I'm interested in is that when you do the TUBA equivalent of looking up the PTR record for 1.1.1.128.in-addr.arpa to find the name of the host, you are able to do this with just the EID rather than having to include the routing portion of the NSAP. I would hope packet forwarding would remain well independent of the DNS. For efficiency, you would want to avoid any lookups during packet forwarding. This is pragmatic issue; we could introduce mobility today by rewriting the network layer to use host names (sendto("nic.near.net", ...) and not caching the mapping at any point. We all know the performance implications of this. There might be some unusual cases where a "router/gateway" might want to discard the supplied RD and reaquire a new one based upon certain conditions. For example, this is a natural function for a mobility server. Another example would be certain encrytion devices which restore the data contents and then insert the real internal RD before forwarding. Note that in both of these cases, it's more likely that these "gateways" will be using a private database keyed by EID, and not a global DB. > However, I am beginning to lean towards the belief that EID to > lookups might be needed in some cases, thus we > should not preclude the possibility. This would seem to imply that > we need to steal an idea from Paul Tsuchiya's old Landmark Routing > proposal, and have the location of the information be based on the > high order part of the EID, without concern for where the system > actually is. Exactly. In support of the above, I feel that EID to address lookups will be a necessary evil. This is derived from two realities of any new Internet protocol deployment: 1) People will want to utilize their existing IP addresses as EIDs. 2) In order for us to introduce this new network layer, it had better handle looking up complete addresses when given 4-octet IP address via socket calls. /John ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Sat Sep 19 02:13:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03535; Sat, 19 Sep 1992 02:13:43 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03532; Sat, 19 Sep 1992 02:13:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01338; Fri, 18 Sep 92 12:10:54 -0400 Date: Fri, 18 Sep 92 12:10:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181610.AA01338@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, dennis@ans.net Subject: Re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu In those situations, 20 bytes addresses are clearly suboptimal. If I was using Marshall silent(T) Rose vocabulary, I would say that this 20 bytes long addressing plan is a ponderous overkill, one more example of the triumph of politics over technology... This is, IMHO, a sufficient reason to discard the current NSAP addressing plan. Christian, I'd draw a different conclusion. I'd say that this points out that you don't want *either* destination addresses *or* source routes in every packet which is part of a flow. You've clearly shown why the latter is not good; why do I add the former? If you do route cache lookups based on the Identifiers, then you use the same mechanism to forward packets, whether it is a source specified route or not. This economy of mechanism seems to me like the Right Thing. In addition, I have recently started to become very suspicious of *all* hop-by-hop routing/forwarding systems. (This includes the hop-by-hop optimization for Nimrod in section 6.1.) The problem is that hop-by-hop routing/forwarding requires global consistency to function correctly. (Technically speaking, it's not actually global consistency, but if you take the set of all endpoints which wish to communicate with a given destination, the set of all the nodes between them and the destination must be consistent; this will usually be close to a global set. The engineering is probably actually easier if you shoot for the larger target, since you don't have to figure out the subset...) Global consistency is a harder and harder target as the system gets larger. Part of the problem is that system dynamics cannot be perfectly predicted, and *all* large systems exhibit unforseen failure modes. Sure, you can design things which usually enforce consistency, etc, (and both DV and class LS systems have these), but there's no guarantee that you didn't miss a failure mode. (The Day the Arpanet Died was an example of such a failure mode in an LS system.) Far better to avoid a whole raft of possible tarpits and avoid everything which requires global consistency. However, this does knock out all hop-by-hop routing/forwarding, since without consistency there's no guarantee the traffic will get there. This does leave Nimrod with a problem, which is how to optimize single packet transactions, without all the hassle of a flow setup. I've started to look again at source routes in the packet for this, perhaps using one (or more, if you want to presupport several classes of service) pre-computed tree(s). For one shots, you read the source route off (the path from the root to the destination), and stick it in; for flows, it is used in the flow setup. This could be done by the first hop router for hosts which don't care... Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 02:16:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03665; Sat, 19 Sep 1992 02:17:07 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03655; Sat, 19 Sep 1992 02:16:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01374; Fri, 18 Sep 92 12:16:46 -0400 Date: Fri, 18 Sep 92 12:16:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181616.AA01374@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: identifiers Cc: jnc@ginger.lcs.mit.edu Encoding IDs to identify a permanent location may be a reasonable approach. Why do people persist in trying to use a hammer to drive screws? If it encodes the location, it is not an identifier, but an address, unless both your addresses and your identifiers encode location. If so, what's the use of having two things which do much the same thing? What do you do if they disagree? Believe the address? If the system works if the identifier location is wrong, what good is it? If not, are you saying you don't want an identifier, and prefer to have just an address? They are different kinds of names, which do different things. When a host moves to another place rather permanently (eg. sold to another company), it may have a second ID to allow gradual changeover to the new ID. People do this with their email addresses. Yes, but you just said "address". They tend to keep the same logon id, unless company policy enforces a change. Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 02:25:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03866; Sat, 19 Sep 1992 02:25:24 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209181625.3866@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03863; Sat, 19 Sep 1992 02:25:18 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8136; Fri, 18 Sep 92 12:25:10 EDT Date: Fri, 18 Sep 92 12:17:53 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, callon@bigfut.enet.dec.com, dennis@ans.net Cc: big-internet@munnari.oz.au Subject: Re: identifiers (was, NSAP AFI for IP) Ref: Your note of Fri, 18 Sep 92 11:21:34 -0400 >I remain utterly, absolutely convinced that if people >*really understand* Nimrod,... they will be just as convinced >as I am that its the *only* way to go. Just out of curiosity, what made *you* convinced that "its the *only* way to go" ? Is "the *only* way to go" statement relative to our current knowledge, or is it like an absolute truth which should be correct both today (9/25/92) as well as 10 year from today (9/25/2002) ? Yakov. From owner-Big-Internet@munnari.oz.au Sat Sep 19 02:33:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04114; Sat, 19 Sep 1992 02:34:04 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209181634.4114@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04085; Sat, 19 Sep 1992 02:33:52 +1000 (from jcurran@nic.near.net) To: Noel Chiappa Cc: dennis@ans.net, big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: Your message of Fri, 18 Sep 92 10:49:09 -0400. <9209181449.AA29702@ginger.lcs.mit.edu> Date: Fri, 18 Sep 92 12:32:21 -0400 From: John Curran -------- ] From: Noel Chiappa ] Subject: Re: identifiers (was, NSAP AFI for IP) ] Date: Fri, 18 Sep 92 10:49:09 -0400 ] ] ... ] ] Ross' position, as I understand it, is that the ability to do ] EID-> lookups shouldn't exist, that we should be doing ] -> ] ] I'm not sure if this *is* Ross' position, but I certainly don't agree ] with it. I see three *completely separate* namespaces: ] ] i) string names organized along an organizational hierarchy (i.e. ] DNS/X.mumble type names), the 'Hostname'. ] ] ii) 'shortish' fixed length unique 'random' binary identifiers for ] 'endpoints' (i.e. 48/64/96 bit IEEE like numbers), the 'Identifier'. ] ] iii) variable length, variable number of levels, topologically *only* ] organized names for network attachment points, the 'Address'. I agree with your view of the namespaces, except for the "strucure" of the EID's. See below. ] You'd be able to translate back and forth, but any one serves as a ] unique key (although some might map to multiple entries *in either ] direction*; e.g a flock of mobile process Identifiers might be at ] the same address, a service named in the DNS might have two ] Identifier, etc). Agreed. ] The most common translation would be Hostname->Identifier & Address. ] Once the system is up, this is pretty much the only one you'd do. ] Identifier-> and Address-> would be used for diagnostics, ] etc. Hmm... this would indicate that mobility/portability would probably not use the (ID->address) mapping service (due to speed concerns), but instead a more dynamic method such as explicit notification, or a dynamic server. I think I am in sync with this, but also want to avoid deploying two methods of (ID->address) mapping if at all possible. ] In an interim deployment period, Identifier->Address mappings might ] be needed for interoperable deployment. Doesn't this imply some hierarchy in the Identifier space, even if only for the short term mapping function. I have been pondering the use of IP addresses as EID's in the short term (which would provide the necessary structure) and then long-term introducing larger "unstructured" EIDs which would not support efficient (ID -> address) mappings. This would only be possible with the common deplyoment of the Hostname->(ID + address) usage. Thoughts? /John From owner-Big-Internet@munnari.oz.au Sat Sep 19 02:52:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04643; Sat, 19 Sep 1992 02:52:41 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04640; Sat, 19 Sep 1992 02:52:33 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA91023 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Fri, 18 Sep 1992 12:48:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 18 Sep 1992 12:48:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 18 Sep 1992 12:48:57 -0400 From: Dennis Ferguson Message-Id: <199209181647.AA63097@foo.ans.net> To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: identifiers In-Reply-To: (Your message of Thu, 17 Sep 92 18:17:10 EDT.) <9209172217.AA23248@us1rmc.bb.dec.com> Date: Fri, 18 Sep 92 12:47:00 -0500 Ross, I think I have perhaps been unclear about what I want the ID to do, since I really don't want much. I am really only thinking about things which are done with IP, and how one might do the equivalent operation with TUBA. Sorry if this is too basic, but I'd really like to be clear this time. The particular operation I am worrying about is lookups for PTR records. Generally servers do this when a client connects, to determine the client's name (if it is an SMTP server, perhaps to write the name in the received header. If it is an ftp or telnet server, perhaps to write the name in a log. It it is an rlogin or rsh server, it may use the name for "authentication", as fragile as this might be). At this point the server only knows the client's IP address. This type of lookup is not uncommon, a long time ago when I worried about this more I found that about 30% of the queries to a University of Toronto server which had full data for the University of Toronto were for PTR records. Suppose the server receives a connection from, say, 128.100.3.1. To determine the name of the client, it then asks the DNS to find a PTR record for 1.3.100.128.in-addr.arpa, i.e. it uses the address as a key for the database search. The data for a PTR record is the name of the host. I think this is the only type of DNS query which doesn't use the name of the host as the search key, i.e. if you only know a host's address and you want information other than the name, first you look up the host's name (with a PTR query) and then you look up the information you want using the name as the search key. Note too that the information is stored in a way which is related to the innards of the IP address. In the particular case above, the root name servers will refer you to a set of name servers which know about 100.128.in-addr.arpa (i.e. 128.100). These servers in turn will refer you to servers which know about 3.100.128.in-addr.arpa. The latter will return the information you want. The question is, then, how will a TUBA server do the equivalent operation to this? That is, when a TUBA server knows nothing about its client other than its CLNP address, how will it determine its name using the DNS? You would be correct to answer that this operation isn't really necessary, that there are other ways (perhaps at the application level) to achieve what this accomplishes, but this isn't really relevant here since existing IP applications do it this way. I would suggest that there are exactly two ways to do the analog of what IP applications do now: (1) Take the *entire* NSAP, write it in little-endian order (maybe in hex) with "."s every once in a while (every byte or two?), append something well known to the end of it and use this as a key for the PTR lookup. (2) Take *only the ID portion of the NSAP*, write it little-endian order (maybe in hex) with "."s every once in a while (every byte or two?), append something well known to the end of it and use this as a key for the PTR lookup. If you do (1) then your IP service provider (or your IP-service-provider-de-jour) will be involved in the provision of your address-to-name name service because of the need for hierarchical location of name servers. If you do (1) the ID number space can be truly flat. If you do (2) then your address-to-name service is entirely independent of network topology (just like name-to-anything service is now), you can change the routing portion of your host's NSAP at will without affecting anyone's ability to determine your host's name from its address. If you do (2) the ID number space will need to be structured such that hierarchical location of name servers is possible, which implies organizational assignment of IDs. Now, pragmatically, I don't think there is a (3). This isn't an optional feature. There is an existing DNS, and there are existing applications, which you don't want to break, which use the DNS and expect to be able to determine a host's name from the information available when a transport connection is initiated. At that point the only information it has to do this with is the remote peer's address. If the ID portion is not structured so that it is useful on its own to determine the name from the DNS, then the whole NSAP will need to be used. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Sat Sep 19 02:57:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04749; Sat, 19 Sep 1992 02:57:21 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209181657.4749@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04746; Sat, 19 Sep 1992 02:57:13 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9221; Fri, 18 Sep 92 12:57:06 EDT Date: Fri, 18 Sep 92 12:49:24 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, callon@bigfut.enet.dec.com, dennis@ans.net Cc: big-internet@munnari.oz.au Subject: Re: identifiers Ref: Your note of Fri, 18 Sep 92 11:49:59 -0400 >>What the DNS doesn't do well, however, is change in a hurry... >So, let's fix it... Noel, That sounds a bit underspecified. For instance, the following questions need to be answered: (a) who is going to design/develop the fix (b) when will this fix become available and deployed (c) shall this fix be self-contained, or would it cause a cascading need to fix other things By the way, this is not an attempt to list all the questions that need to be answered. Yakov. From owner-Big-Internet@munnari.oz.au Sat Sep 19 03:10:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05122; Sat, 19 Sep 1992 03:10:39 +1000 (from owner-Big-Internet) Return-Path: Received: from asylum.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05113; Sat, 19 Sep 1992 03:10:29 +1000 (from dab@asylum.sf.ca.us) Received: from dab.port.asylum.sf.ca.us by asylum.sf.ca.us via PCMAIL with DMSP id AA01552; Fri, 18 Sep 92 13:10:19 -0400 (EDT) Date: Fri, 18 Sep 92 13:10:19 -0400 (EDT) Message-Id: <9209181710.AA01552@asylum.sf.ca.us> To: jnc@GINGER.LCS.MIT.EDU (Noel Chiappa) Subject: Re: identifiers (was, NSAP AFI for IP) From: dab@asylum.sf.ca.us (David Bridgham) Reply-To: dab@asylum.sf.ca.us Cc: big-internet@MUNNARI.OZ.AU Sender: dab@asylum.sf.ca.us Repository: asylum Originating-Client: port.asylum.sf.ca.us I thought I was doing a pretty good job of following Noel's architecture and terminology. Then along came this message. I understood and believed in the first paragraph. But the second paragraph sounds to me contradictory so obviously I missed something. ii) 'shortish' fixed length unique 'random' binary identifiers for 'endpoints' (i.e. 48/64/96 bit IEEE like numbers), the 'Identifier'. Huh? The only thing *guaranteed* to be in every Nimrod packet are the source and destination Identifiers, which are well structured. Nimrod addresses are well structured too. What's the problem? What structure is there to Identifiers? Or by 'well structured' did you mean that it's well defined that they have no structure? Dave (lost again) Bridgham From owner-Big-Internet@munnari.oz.au Sat Sep 19 03:54:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06355; Sat, 19 Sep 1992 03:55:05 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06352; Sat, 19 Sep 1992 03:54:59 +1000 (from kre) To: Big-Internet@munnari.oz.au Subject: Identifiers, motion, and the DNS Date: Sat, 19 Sep 92 03:54:54 +1000 Message-Id: <3761.716838894@munnari.oz.au> From: Robert Elz Advance warning ... This has turned into a long message - 200 lines or so. Please, if you're going to include some of it in a reply you send, edit HEAVILY - the full message can always be obtained from the archives. Its good to see this question back on the front burner, as I think its one that needs a solution fast - before users of the ID (EID, whatever) bind themselves to something that won't work. In the past couple of days, when I haven't been paying much attention to what's been happening, there has been much discussion, some of which seems to me to be way off the track, and none of which seems to have really grasped all the issues at once (not that I'm likely to either). To work out what we want the EID to be, we need to know what we're going to use it for, which no-one seems to have set out explicitly yet, so here's an attempt... 1) The EID is what is used in TCP (etc) as the identifier of the end points of the connection (so a TCP connection is the quad: remote EID, remote port, local EID, local port). 2) The EID is the thing you'd log (if not hostname, or in addition to) to indicate where a connection came from. 3) The EID is what we use to discover a hostname from the binary mess that appears in packet headers. 4) Noel wants to use it as a cache tag for forwarding through routers, which is nice, but doesn't seem to place any restrictions at all on the EID, so I think can be ignored. And similar. That is, consider an IP address, take away all of the routing connotations, and what's left is an EID. Which is not to say that IP addresses are what we want to use (they're clearly not big enough) but you get the idea this way - anything you can currently do with an IP address other than anything in any way directly related to routing, you want to be able to do with an EID. Even the restriction on "not routing" is probably too much if we use the jnc definition of routing, whereby routing isn't something routers do (they forward) but something the source host does - we would want to be able to "route" based on the EID, though not effeciently (about the same as how you'd currently "route" using the domain name). When I say "everything" excluding routing (forwarding) that an IP address can do, I really mean it - so I definitely do mean stuff like To: user@[eid-in-text-encoding] in SMTP mail, which would probably be used about as much as To: user@[ip.dot.ted.quad] which isn't much, so it needn't be effecient, but it certainly is useful, so we should be making it work. Add to this stuff like using the EID in SNMP (wherever IP addresses appear now, except probably in ARP and IP routing tables, or interface labels), and you get some of the idea. What an EID isn't, is anything a router can (in any reasonble way, excluding the cache tag idea) use to forward a packet to its destination (ie: the EID alone will tell you nothing about the path to use). Nor is it 1::1 with any of names, addresses, or pieces of hardware (and certainly not interfaces, with which it has no relationship whatever). Names can map to multiple ID's (though just what this means I'm not sure I understand - ie: just how anyone should chosoe which EID to use), names can certainly map to multiple addresses, so EID's can clearly be mapped to many addresses. names and addresses can also be mapped to multiple names, though in most cases you'd want those names to be essentially aliases for the same "thing". The longevity of an EID isn't too important right now - I know there's this idea of simply creating one for a process to use - personally I don't see the merit in that, and don't think we need to support it, that kind of identifier is on a different astral plane. We definitely do need to look up EID's in some directory, to obtain either the hostname or the address (the thing that is used, in some way or other which will depend on the protocols using it, for routing in the forwading sense) - I doubt getting only the address would be useful, but whether the directory returns just the hostname, or both, shouldn't matter, as there will obviously also be a hostname -> EID & Address mapping, two directory lookups to map from EID (via Name) -> Address (the least common of all EID lookups) would be just fine. Now, those lookups won't be all that frequent, and so don't need to be highly optimised, that's certainly true - some have taken that to mean that it doesn't matter where in the directory the EID is found - that's bogus. The directory location problem has nothing whatever to do with how well the lookups can be done - or rather, clearly some technique for reasonable lookups needs to be devised, ie: something like in-addr.arpa, rather than the ancient DNS IQUERY stuff which required a complete tree search - but that's not the issue that matters. What counts for the directory here is what happens when I get some new host delivered, and I want to register it properly, where do I send the registration? What if I have 50 new hosts, do I send 50 registrations out to 50 random locations round the globe? This gets farcical very quickly - the EID's really need to be arranged so that registration can be done effeciently and reasonably, ie: the EID's need to be registered locally. That almost certainly means they need to be allocated locally. What happens after the host is moved doesn't matter at all - its registered then, the registration from EID -> name (which is what I'd do) can remain constant wherever the host moves. If it is essentially abandoned, then the same hardware happens to appear elsewhere, with a new name, it should have a new EID as well, I can't think of a sensible justification for retaining a host's EID while its name changes, with the possible exception of changing the name with the host continuing to keep its current connections open, which doesn't really fit the scenario I just described. I don't see any need to keep the EID permanent with the host for all time, the cases where one piece of hardware is wheeled away and another replaces it and similar can all involve a replacement EID if that helps - just as they can involve a replacement IP address if necessary (neither required nor prohibited). On the contrary, in some cases I'd say keeping the EID with the "host" to be positively detrimental, depending on just what in your opinion is the essence of the "host". If the "host" is the bit of board with tracks etched in and chips soldered on, then the EID simply doesn't belong to that thing at all - or doesn't need to, and probably shouldn't. On the other hand, if the "host" is the combined processor, filesystems, and users, then keeping the same EID with the "host" would be OK (not essential, just OK). The reason that you don't want the EID to go with the "host" (== board) is just the same as why there needs to be some structure in the EID - if the service organisation takes away my "host" and replaces it with a new one, then fixes the one that was mine and swaps it in someplace else on a later service call, that poor luser shouldn't need to contact me to have his EID->name mapping done, he should be doing that locally - the recipient simply doesn't want the EID I used. For hosts that move what happens depends on the kind of motion involved. If we're considering some host in a caravan (== "trailer" to those in North America) raoming the country, keeping its connectins open as it moves, or one in use on a plane as you fly around the globe, then the EID simly wants to remain fixed - in fact needs to so connections stay open. This is not any kind of problem, that the host is not near the directory where it was registered doesn't matter at all, nothing is changing in that registry (the EID->name one) nothing needs to be altered, and lookups will work as always. On the other hand, if your definition of "move" is pack up the host, send it across the country in a truck along with the rest of your belongings as you move from one job to another, then the EID probably should be changed, so the registry remains close to the natural home of the host. While we're considering EID's, we don't even need to begin to think about dynamic DNS updates, or any of the rest of that stuff - EID's simply don't change with that kind of frequency, that's addresses that are changing, and how they're obtained, how they're altered as a host moves, if they're altered as a host moves, will all depend on just what kind of address is being used, and how it is defined to handle mobile hosts, an important question, but not related to EID's. Now I think I can conclude by saying that I don't believe that IEEE addresses have any place as EID's at all - their sole reason for even being put forward in this role seems to be that they're of more or less adequate size (46 bits padded to 48) and are already allocated by someone or other, so by using them we get to piggy back on someone else's work which is always a great way to solve problems. (That they come delivered with the host is just another way of saying "allocated already"). Unfortunately their disadvantage - totally meaningless collections of bits - outweighs this I think, the directory maintenance problem is too important to simply shove aside till some other day - it simply won't work with IEEE numbers. Now I know that there are some who believe that the IEEE number will be qualified by the address, and locality of directory lookups will be obtained that way (this seems to arise in TUBA, where the idea is to put the EID in the address, and not assume the EID is globally unique, even if it happens to be in practice). Personally I think this is simply idiotic - the addresses have to be variable things, that can change quickly as a host moves, and even perhaps for random other topology changes (you switch from one net provider to another, plug in a line to your new provider, and unplug your old one once the first works - but there's no reason that you should have to break existing connections to make this work, yet that would be required if the address were part of the EID that TCP uses.) Also against use of IEEE numbers, is that I would certainly not be prepared to guarantee that no vendor, ever, has made a mistake in allocating from his range of IEEE supplied numbers, and given the same one to two different pieces of hardware. Can you? While duplicate EID's in the net wouldn't be absolutely fatal (its the routing connotations that makes that impossible for IP addresses) its not something that you'd want to have normally. The way IEEE numbers are used now, it would be a one in several million chance probably that anyone would ever notice a duplicate allocation, but if all those IEEE numbers suddenly become globally visible the whole issue of ensuring uniqueness moves to a totally different plane. This essay (I was going to say "note" but its grown way beyond that) is too long already, I'll leave it here for now, but please do continue to discuss just what is an EID, what its used for, and how it needs to be constructed to be useable for its intended purposes - its a critical thing to get right now, as other protocols are going to depend on this. If they're to be ready for November, the EID question better be resolved this month, at the latest (should have really been last month, or the month before...) kre ps: this became so long because I've tried to say much the same before, and failed miserably, as I know lots of people didn't understand what I was getting at. I hope this time the point (EID's have to be locally allocated), and the reason (directory maintenance), can sink in... From owner-big-internet@munnari.oz.au Sat Sep 19 04:10:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06771; Sat, 19 Sep 1992 04:10:57 +1000 (from owner-big-internet) Return-Path: Message-Id: <9209181810.6771@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05267; Sat, 19 Sep 1992 03:16:15 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9896; Fri, 18 Sep 92 13:16:08 EDT Date: Fri, 18 Sep 92 13:15:26 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au >Sure, you can design things which usually enforce consistency, etc, >but there's no guarantee that you didn't miss a failure mode. >Far better to avoid a whole raft ot possible tarpits and avoid >everything which requires global consistency. Noel, There is one flaw in your logic. The "problem" you perceive with hop-by-hop is because you can't guarantee that you didn't miss a failure mode. So, "to avoid a whole raft ot possble tarpits" you need something that doesn't have a failure mode. Do you have that "something" that are suppose to be "failure mode free" ? Yakov. From owner-Big-Internet@munnari.oz.au Sat Sep 19 04:30:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07241; Sat, 19 Sep 1992 04:30:27 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07238; Sat, 19 Sep 1992 04:30:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03939; Fri, 18 Sep 92 14:30:16 -0400 Date: Fri, 18 Sep 92 14:30:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209181830.AA03939@ginger.lcs.mit.edu> To: yakov@watson.ibm.com Subject: Re: identifiers (was, NSAP AFI for IP) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Just out of curiosity, what made *you* convinced that "its the *only* way to go" ? You don't know how much I wish I had a short, clear answer to that question. I'm not being flip; the massive amount of time and energy I spend making up Noelgrams is really a drain. In some sense it is a combination of system design principles, and a lot of large scale routing theory. The problem is passing this massive body of data on; it's a combination of system design stuff I learned at school (in MIT's undergrad information systems course, 6.033, through working directly with Jerry Saltzer, and from studying many, many older information systems), and many years of thinking about routing in large scale computer networks (starting in 1977, when I joined Dave Clark's group at MIT, when TCP was just getting underway). Is "the *only* way to go" statement relative to our current knowledge, or is it like an absolute truth which should be correct both today (9/25/92) as well as 10 year from today (9/25/2002) ? Well, I think it's pretty absolute. Things like the trade-off between the costs of routing overhead and the costs of non-optimal routing (implicit in heirarchical routing), address heirarchies having to change as the topology changes to keep overall the routing costs minimal, etc pretty much just *are*. Think of them as the Laws of Thermodynamics for routing. Nimrod is basically driven by acknowledging these fundamentals, together with system design principles. The basic outline (source routed link state system) has been the same since 1987 or so. Some of the understanding of how to handle the difficult abstraction issues dates from a year or so later, (Perhaps Deborah remembers the date of the 'blister model' meeting at ISI.) Even things as deep as that didn't change the basic design. I'm getting a deeper and deeper understanding all the time, of course (e.g. recent thoughts on addresses changing, and global consistency), and things change around the edges (like various optimizations), but the basic architecture hasn't changed in several years. The fact that all this new stuff fits with no upheaval makes me even more confident this is *the* path. Noel From owner-Big-Internet@munnari.oz.au Sat Sep 19 05:27:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08763; Sat, 19 Sep 1992 05:28:06 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08755; Sat, 19 Sep 1992 05:27:51 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA04146; Fri, 18 Sep 92 12:27:37 -0700 Received: by us1rmc.bb.dec.com; id AA21738; Fri, 18 Sep 92 15:24:57 -0400 Message-Id: <9209181924.AA21738@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Fri, 18 Sep 92 15:24:58 EDT Date: Fri, 18 Sep 92 15:24:58 EDT From: Ross Callon To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: re: re: re: identifiers > Ross, this is the US mail model. However, is it really cleaner and less > expensive than the model where you tell the sources directly that the > destination has moved? Clearly, if you are already talking to someone, and you move, then you tell them that you have moved. I should have added to my list that you tell all folks that you are currently talking to. The question is whether you also tell the directory service, and how quickly the directory service catches up with changes. (more below) Also, if it takes a while for the directory service to catch up, then you better have some way for hosts which get your old address from the directory service to find you. > I don't see how the host can know whether the move is permanent of > temporary without asking a human to tell it what is going on. > > This is useless linguistics. Almost all hosts move sooner or later; some > move more often, and stay shorter times, is all. How do you tell what > the dividing line is? One hour? One day? One week? One month? It's not > as hard as the mobile/portable distinction (where this *is* a noticeable > boundary; whether open connections stay open or not). Again, my point here is that you need to decide whether to tell the directory service that you have moved. If I go up to New Hampshire for a week vacation, I don't tell NYNEX to change their directory service. On the other hand, if I accept a job in Hawaii and move permanently, then I do get the directory service updated. Similarly, for a short term temporary move the DNS just keeps returning your old (home) address, packets get forwarded to you and the sources trying to contact you get redirected to use the correct address. Certainly there is no point in updating the directory service unless you are going to be in the new location for longer than it takes the directory service to get back to normal. My feeling is that we should think about how to try to get DNS to accept changes more gracefully and quickly, but we cannot expect a global directory service to change instantly and frequently (i.e, given that we have not yet spent much time thinking about how to make DNS more dynamic, I won't assume absolute success). > This is why I like a model where we *don't* have separate mechanisms for > portable hosts and address changes. Agree. Ross From owner-Big-Internet@munnari.oz.au Sat Sep 19 06:03:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10323; Sat, 19 Sep 1992 06:03:40 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10315; Sat, 19 Sep 1992 06:03:27 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA06172; Fri, 18 Sep 92 13:03:08 -0700 Received: by us1rmc.bb.dec.com; id AA23022; Fri, 18 Sep 92 16:00:19 -0400 Message-Id: <9209182000.AA23022@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Fri, 18 Sep 92 16:00:20 EDT Date: Fri, 18 Sep 92 16:00:20 EDT From: Ross Callon To: dennis@ans.net Cc: big-internet@munnari.oz.au Apparently-To: dennis@ans.net, big-internet@munnari.oz.au Subject: re: Re: identifiers > The question is, then, how will a TUBA server do the equivalent operation > to this? That is, when a TUBA server knows nothing about its client > other than its CLNP address, how will it determine its name using the > DNS? You would be correct to answer that this operation isn't really > necessary, that there are other ways (perhaps at the application level) to > achieve what this accomplishes, but this isn't really relevant here since > existing IP applications do it this way. Certainly, the main point of TUBA is to take advantage of existing and partially deployed things to solve the scaling problem for existing Internet applications. Thus, we have to work with existing IP applications and thus your question is a good one. > I would suggest that there are exactly two ways to do the analog of what > IP applications do now: > > (1) Take the *entire* NSAP, write it in little-endian order (maybe in hex) > with "."s every once in a while (every byte or two?), append something > well known to the end of it and use this as a key for the PTR lookup. > > (2) Take *only the ID portion of the NSAP*, write it little-endian order > (maybe in hex) with "."s every once in a while (every byte or two?), > append something well known to the end of it and use this as a key for > the PTR lookup. Yes, I think that you can either do the lookup by address, or by ID. > If you do (1) then your IP service provider (or your > IP-service-provider-de-jour) will be involved in the provision of your > address-to-name name service because of the need for hierarchical location > of name servers. If you do (1) the ID number space can be truly flat. However, if you do (1), then when a system moves to a new location and thereby gets a new address, it will need to contact a local DNS service in order to make sure that the resulting address to name mapping is available (really, this should not be all that hard to get to work). > If you do (2) then your address-to-name service is entirely independent > of network topology (just like name-to-anything service is now), you can > change the routing portion of your host's NSAP at will without affecting > anyone's ability to determine your host's name from its address. If you > do (2) the ID number space will need to be structured such that hierarchical > location of name servers is possible, which implies organizational > assignment of IDs. But, if the ID stays the same as the system moves, then it stops being organizational after a while. On the other hand, *regardless* of how you assign IDs, you can just take the first byte, map this onto "top level DNS server", send a request there, etc. This will allow you to map from ID to name. Thus, however you assign IDs, you can pretend that there is structure, and do the hierarchical lookup appropriately. However, the lookup might have to go just about anywhere (presumeably, to a server located conveniently to a public backbone -- also we might replicate the information on each continent, so you don't have to really go anywhere in the world). I think that if you assign IDs organizationally according to where a system is currently, then you will probably find that you want to change IDs as the systems move. > Now, pragmatically, I don't think there is a (3). This isn't an optional > feature. There is an existing DNS, and there are existing applications, which > you don't want to break, which use the DNS and expect to be able to determine > a host's name from the information available when a transport connection is > initiated. At that point the only information it has to do this with is the > remote peer's address. If the ID portion is not structured so that it is > useful on its own to determine the name from the DNS, then the whole NSAP > will need to be used. But, you can structure the DNS records around the ID, rather than vice versa. There is of course one other option (which seems to be implicit in KRE's recent note, if not explicit): You could just do away with the notion that you can move a system anywhere and keep the same ID. Now, if you have to change ID when you change location, then when you change location you will have to contact the name service and get your new ID to name stored (for the lookups that you mentioned earlier). Also, it will not be possible to tell from looking at two addresses whether they are the same, which means that any system that needs to know (such as a system which was talking to you while you moved -- where you want the TCP connection to stay active while you change addresses and IDs), will need to be explicitly told of the address change. Thus, if you change ID when you change location, then I don't see a globally meaningful ID as being anything more than a shorthand for the address, which has some of the same features as the address (such as uniquely identifying the host), but which has no advantage over the address except that it is shorter. Ross From owner-Big-Internet@munnari.oz.au Sat Sep 19 06:45:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12124; Sat, 19 Sep 1992 06:46:12 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12098; Sat, 19 Sep 1992 06:45:54 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA08829; Fri, 18 Sep 92 13:45:48 -0700 Received: by us1rmc.bb.dec.com; id AA24506; Fri, 18 Sep 92 16:42:55 -0400 Message-Id: <9209182042.AA24506@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Fri, 18 Sep 92 16:42:56 EDT Date: Fri, 18 Sep 92 16:42:57 EDT From: Ross Callon To: kre@munnari.oz.au Cc: big-internet@munnari.oz.au Apparently-To: kre@munnari.oz.au, big-internet@munnari.oz.au Subject: re: Identifiers, motion, and the DNS > This gets farcical very quickly - the EID's really need to be arranged > so that registration can be done efficiently and reasonably, ie: the > EID's need to be registered locally. That almost certainly means they > need to be allocated locally. Local allocation has two implications: Some human has to manually configure a system when its EID is assigned. Depending upon what you mean by "locally", the EID will need to change when the system moves. The whole point of stamping a piece of equipment with an ID at birth is to make assignment extremely easy. When a system is plugged in locally, then registration (i.e., telling some local server than ID number xxxxxxxxxx has gotten attached to the net) can be done automatically without human intervention. > While we're considering EID's, we don't even need to begin to think > about dynamic DNS updates, or any of the rest of that stuff - EID's > simply don't change with that kind of frequency, that's addresses that > are changing, and how they're obtained, how they're altered as a host > moves, if they're altered as a host moves, will all depend on just what > kind of address is being used, and how it is defined to handle mobile > hosts, an important question, but not related to EID's. Now I don't fully understand what you are proposing. You say that EIDs are assigned locally, but that they don't change with much frequency. When do they change, and when do they stay the same? I guess what we are talking about is more or less what the rate of change is, and how network managers know when they are supposed to change an EID, and when they don't. > Now I think I can conclude by saying that I don't believe that IEEE > addresses have any place as EID's at all - their sole reason for even > being put forward in this role seems to be that they're of more or less > adequate size (46 bits padded to 48) and are already allocated by > someone or other, so by using them we get to piggy back on someone > else's work which is always a great way to solve problems. (That they > come delivered with the host is just another way of saying "allocated > already"). Unfortunately their disadvantage - totally meaningless > collections of bits - outweighs this I think, the directory maintenance > problem is too important to simply shove aside till some other day - it > simply won't work with IEEE numbers. Well, the directory maintenance problem is indeed made worse if you rely on using the EID as the directory lookup (rather than the full address), and if you use an ID which hardly ever changes (so that systems move much more quickly than IDs change, implying that most systems' ID has no relationship with its present location). However, note that this complication of the ID to name lookup is caused by the slowness of the change in ID, not by the fact that one might use IEEE IDs rather than some other pretty much permanent ID. > Now I know that there are some who believe that the IEEE number will be > qualified by the address, and locality of directory lookups will be > obtained that way (this seems to arise in TUBA, where the idea is to > put the EID in the address, and not assume the EID is globally unique, > even if it happens to be in practice). Well, I think that we are still discussing the details here. However, my feeling is that the EID should be globally unique. This does not necessarily require you to use it for the "incoming network layer packet to name lookup". > ...Personally I think this is > simply idiotic - the addresses have to be variable things, that can > change quickly as a host moves, and even perhaps for random other > topology changes (you switch from one net provider to another, plug in > a line to your new provider, and unplug your old one once the first > works - but there's no reason that you should have to break existing > connections to make this work, yet that would be required if the > address were part of the EID that TCP uses.) "Idiotic" is a rather strong word, particularly for a subject this complex where there are currently **zero** fully specified proposals. Also, this paragraph makes it clear that you don't understand the TUBA proposal. We explicitly are planning that the TCP connection does not break when the address changes (why else would be be doing all this discussion about globally unique IDs??). Why does the EID that TCP uses for identifying connections have to be identical to the thing (address or name) which is used for "incoming network packet to name" lookup? Couldn't we use the complete address to lookup the name, but only use the ID to identify the TCP connection? As I mentioned above, figuring out details like this is why I consider this discussion of IDs to be worthwhile. > Also against use of IEEE numbers, is that I would certainly not be prepared > to guarantee that no vendor, ever, has made a mistake in allocating from > his range of IEEE supplied numbers, and given the same one to two different > pieces of hardware. Can you? ... This is certainly true. Mistakes do happen. However, is there another scheme which quarantees that network managers won't make mistakes, and give two hosts the same ID? I don't see the IEEE ID space as being more prone to errors than a new scheme that we might be able to design, but which is based on an administrative procedure which we have not yet begun to design. Clearly, based on the results of this discussion, plus a bunch of protocol design details still to be worked out, the use of IEEE IDs might or might not turn out to be a useful way to administer globally unique IDs. However, I doubt that the possibility of errors in ID administration will turn out to be an overwhelming reason to design our own ID administration proceedure, rather than use an existing procedure. > This essay (I was going to say "note" but its grown way beyond that) is > too long already, I'll leave it here for now, but please do continue to > discuss just what is an EID, what its used for, and how it needs to be > constructed to be useable for its intended purposes - its a critical > thing to get right now, as other protocols are going to depend on > this. If they're to be ready for November, the EID question better be > resolved this month, at the latest (should have really been last month, > or the month before...) I certainly agree that the ID space issue is much more complex than might appear to the casual observer, and is something that we really should try to get right. I hope we are not boring anyone out there. Ross From owner-Big-Internet@munnari.oz.au Sat Sep 19 06:56:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12436; Sat, 19 Sep 1992 06:56:44 +1000 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12433; Sat, 19 Sep 1992 06:56:38 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA22255 (5.65/1.23); Fri, 18 Sep 92 16:56:25 -0400 Date: Fri, 18 Sep 92 16:56:25 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9209182056.AA22255@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Z.Wang@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: identifiers (LONG) In-Reply-To: <9209181616.AA01374@ginger.lcs.mit.edu> References: <9209181616.AA01374@ginger.lcs.mit.edu> <[quoting Zheng, I think] > Encoding IDs to identify a permanent location may be a reasonable > approach. >Why do people persist in trying to use a hammer to drive >screws? If it encodes the location, it is not an identifier, but an >address, unless both your addresses and your identifiers encode >location. As I think Noel will respond to me, no, no, no, NO! Here is the model that I have been thinking about for dealing with ID's and addresses; this was thought out in the context of PIP, but it should work with any separate-ID scheme... First of all, I don't share Noel's view that ID-->anything mappings in the distributed database will be infrequent; it's clear that we do a lot of them in IP4, and I don't see any reason why this will be different in IP7. (Note that I am ignoring the issue of whether this is a good thing; that's not relevant unless you have the means to replace current practice with something better.) We need to think about what an ID really *is*, in the sense of someone who is trying to look one up. I think I can explain best by example; there is a machine called tsornin.emba.uvm.edu (whose IP4 address is 132.198.4.xxx). Whatever his ID is, that ID can (and must, to my way of thinking) represent `tsornin.emba.uvm.edu', and *not* `AT&T 6386E/20 WGS serial 1234567'. If I were to replace tsornin with some other machine, in such a way as to be transparent to network programs accessing it, his ID should *not* change! (Never mind that I can't actually do this right now; there exist machines where one could, at least in theory, do so.) In other words, I believe that an ID must represent a logical entity, not a particular physical device. (Other than that, Noel's definition is OK for me.) This is one of the reasons why I've been so strongly against using a namespace like IEEE 802 numbers as a component of the ID... Now, given this, I believe that we will see the following: - hostname -> ID lookups are very frequent (1.0) - ID -> address lookups are even more frequent (1.5?) - ID -> hostname lookups are somewhat less frequent (0.3?) - address -> ID lookups don't really make sense(*) So, say you wanted to talk to my machine. You would use the DNS to find out that the ID of `tsornin.emba.uvm.edu' is xxx.yyy.zzz.aaa.bbb.ccc.ddd.eee; you then use a specific address lookup mechanism to find that that ID corresponds to some address; this may or may not (depending on the value of `IPv7') also include some form of dynamic route generation and lookup. (In PIP, you can design an addressing scheme so that the routing simply falls out of the structure; I can't say about the others.) In actual implementation, what I expect is that gethostbyname() will return the ID *only*; socket operations (bind, connect, sendto, recvfrom, etc.) will reference IDs only, and internally (either inside the kernel or as a part of the run-time library), some call will be made to the address lookup mechanism to tell the system the address that belongs to that ID. I believe that, with the appropriate address lookup mechanism, this solves the problem of mobile and portable hosts as well. ---- (*)How did you even get the address without the ID, anyway? If this is really a problem---and I don't think it is---then it's a trivial hack with ECHO messages to find out the remote machine's ID. ---- Now, with such a structure, I would say that ID's should be (WARNING, value judgment ahead) *administratively* hierarchical, but *topologically* flat. That is to say, they should be hierarchical in a way which makes it easy to administer for the `owning' organization, but is not necessarily related to the actual network topology. Of course, none of the software should be really ``aware'' of the structure of an ID; but I believe that it is important from an administrative point of view to have some structure to them. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Sat Sep 19 08:40:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16038; Sat, 19 Sep 1992 08:40:27 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209182240.16038@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16033; Sat, 19 Sep 1992 08:40:19 +1000 (from jcurran@nic.near.net) To: Robert Elz Cc: Big-Internet@munnari.oz.au Subject: Re: Identifiers, motion, and the DNS In-Reply-To: Your message of Sat, 19 Sep 92 03:54:54 +1000. <3761.716838894@munnari.oz.au> Date: Fri, 18 Sep 92 18:40:09 -0400 From: John Curran -------- From: Robert Elz Subject: Identifiers, motion, and the DNS Date: Sat, 19 Sep 92 03:54:54 +1000 ... This gets farcical very quickly - the EID's really need to be arranged so that registration can be done effeciently and reasonably, ie: the EID's need to be registered locally. That almost certainly means they need to be allocated locally. Yes. "locally" means under your administrative control, not necessarily close via network topology. ... For hosts that move what happens depends on the kind of motion involved. If we're considering some host in a caravan (== "trailer" to those in North America) raoming the country, keeping its connectins open as it moves, or one in use on a plane as you fly around the globe, then the EID simly wants to remain fixed - in fact needs to so connections stay open. This is not any kind of problem, that the host is not near the directory where it was registered doesn't matter at all, nothing is changing in that registry (the EID->name one) nothing needs to be altered, and lookups will work as always. ... Right. Now I think I can conclude by saying that I don't believe that IEEE addresses have any place as EID's at all - their sole reason for even being put forward in this role seems to be that they're of more or less adequate size (46 bits padded to 48) and are already allocated by someone or other, so by using them we get to piggy back on someone else's work which is always a great way to solve problems. (That they come delivered with the host is just another way of saying "allocated already"). Unfortunately their disadvantage - totally meaningless collections of bits - outweighs this I think, the directory maintenance problem is too important to simply shove aside till some other day - it simply won't work with IEEE numbers. IEEE numbers certainly do not have the necessary characteristics for directory lookup. It *is* possible to build a flooding protocol to perform the lookup, but that may or may not scale (we may need to see how wide-area IP multicasting fares before knowing) Now I know that there are some who believe that the IEEE number will be qualified by the address, and locality of directory lookups will be obtained that way (this seems to arise in TUBA, where the idea is to put the EID in the address, and not assume the EID is globally unique, even if it happens to be in practice). Personally I think this is simply idiotic - the addresses have to be variable things, that can change quickly as a host moves, and even perhaps for random other topology changes (you switch from one net provider to another, plug in a line to your new provider, and unplug your old one once the first works - but there's no reason that you should have to break existing connections to make this work, yet that would be required if the address were part of the EID that TCP uses.) which is why EID's should have a administrative prefix (not *address prefix*) and the directory services should organized via that administration token. This is unpopular (more octets in headers) but provides EID's which have the desired characteristics you mention. When you move from one network attachment location to another, the address (accessed via EID) is changed. The EID remains unaffected. In fact, about the only reason for changing EIDs is if an organization splits in two, and then (by definition) you would need to establish two distinct admin prefixes to insure separate directory administration. (Two organizations combining do not pose the same problem; both sets of EIDs remain valid.) /John From owner-Big-Internet@munnari.oz.au Sat Sep 19 10:35:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20020; Sat, 19 Sep 1992 10:35:19 +1000 (from owner-Big-Internet) Return-Path: Received: from CSEIC.SAIC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20007; Sat, 19 Sep 1992 10:35:06 +1000 (from carlberg@cseic.saic.com) Received: from caspian.cseic.saic.com by cseic.saic.com (4.1/SMI-4.1-woody-MX-1.0) id AA01887; Fri, 18 Sep 92 20:31:48 EDT Date: Fri, 18 Sep 92 20:31:48 EDT From: carlberg@cseic.saic.com (Kenneth Carlberg) Message-Id: <9209190031.AA01887@cseic.saic.com> To: callon@bigfut.enet.dec.com Subject: dynamic servers (was something else...) Cc: big-internet@munnari.oz.au Ross, > Again, my point here is that you need to decide whether to tell the > directory service that you have moved. If I go up to New Hampshire > for a week vacation, I don't tell NYNEX to change their directory > service. On the other hand, if I accept a job in Hawaii and move > permanently, then I do get the directory service updated... The above refers to portability. The following will expand on why this distinction is important. > ...My feeling is that we should think about how to try to get DNS to > accept changes more gracefully and quickly, but we cannot expect a > global directory service to change instantly and frequently Well...., yes, but I think this depends on how the DNS (or some other server) would be used and the criteria for its update. I don't think one is always going to have the luxury knowing *when* the host moves and (believe it or not) *where* the host is as it moves - if one is using mobility as a reference model. The following hypothetical example should help clarify my statement. Note: I'm assuming that the movement of a host is transparant to the upper layers (including the end-user ;-). Lets assume a number of wireless LANs are resident in a facility that contains several labs (software, hardware, etc.). Furthermore, groups of labs are configured as separate Areas, ala OSPF, within a domain. If I had a laptop with a built-in packet radio, started an application (like Talk and/or Telnet) in one lab, then I took the laptop to the next lab, I (the end-user) would have no idea that I still reside in the same Area or in a different routing location. Hence, neither the application nor the end-user is able to "inform" another entity, be it DNS or a some type of "mobility server", about the new location of the machine. Now I don't think the above example is unreasonable, although I do make a number of assumptions. However, the point that I want to make is that if mobility, as opposed to portability, is to be supported by the next routing architecture, then some type of dynamic/responsive server (DNS or otherwise) should be included in the equation. -ken From owner-Big-Internet@munnari.oz.au Sat Sep 19 11:51:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22346; Sat, 19 Sep 1992 11:51:24 +1000 (from owner-Big-Internet) Return-Path: Received: from cs.columbia.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22342; Sat, 19 Sep 1992 11:51:16 +1000 (from ji@close.cs.columbia.edu) Received: from close.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA13574; Fri, 18 Sep 1992 21:51:06 -0400 Message-Id: <199209190151.AA13574@cs.columbia.edu> Received: by close.cs.columbia.edu (15.11/15.6) id AA23498; Fri, 18 Sep 92 21:50:13 edt Date: Fri, 18 Sep 92 21:50:13 edt From: John Ioannidis To: big-internet@munnari.oz.au Subject: re: routing to mobile/portable hosts > If so, the key question IMHO isn't how you find out where the host is > now, but how you purge stale route information that is cached in the > lower levels of your hierarchy, without unduly burdening the network > with update messages. You cache the entries that you have used recently; so long as you keep using them, you refresh a timer in your cache; if a host moves, you back-propagate forwarding pointers, but only as the need arises (that is, only if there is traffic that needs that route). Otherwise, let the routing information time itself out of existence. If you really need to talk tot hat host again, you reinitiate the search procedure. The tricky part is balancing that timeout! /ji From owner-Big-Internet@munnari.oz.au Sat Sep 19 14:35:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28109; Sat, 19 Sep 1992 14:35:45 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28106; Sat, 19 Sep 1992 14:35:33 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Sat, 19 Sep 92 00:35:25 EDT Received: by chiya.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Sat, 19 Sep 92 00:35:24 EDT Date: Sat, 19 Sep 92 00:35:24 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9209190435.AA28781@chiya.bellcore.com> To: Big-Internet@munnari.oz.au Subject: pip IDs........ I just put this out on the Pip list, but since IDs seems to be a big topic of discussion on this list, I thought I'd post the draft internet-draft on the definition of Pip IDs to this list...... It's available via anon ftp at: thumper.bellcore.com:pub/tsuchiya/pipId.txt PX Network Working Group P. Tsuchiya INTERNET-DRAFT Bellcore September 1992 Pip Identifiers Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract Pip is an internet protocol intended as the replacement for IP version 4. The Pip header defines source and destination ID fields whose function it is to only identify the source and destination of a Pip packet--they have no routing significance. While Pip systems treat the IDs as flat for the purpose of identification, it is useful to have hierarchical structure in the ID for other purposes, such as for doing a reverse DNS lookup on the ID. This internet-draft defines the structure of Pip IDs. Acknowledgements I want to thank John Curren and Bob Smart for their observations on the need for administrative structure in Pip IDs that led to this draft. Introduction Pip is an internet protocol intended as the replacement for IP version 4. The Pip header defines source and destination ID fields whose function, in the context of processing Pip headers, is to only identify the source and destination of a Pip packet--they have no routing significance. While Pip systems treat the IDs as flat for the purpose of identification, it is useful to have hierarchical structure in the ID for other purposes, such as for doing a reverse Pip WG, Expires March. 1, 1993 [Page 1] INTERNET-DRAFT Pip Identifiers September 1992 DNS lookup on the ID. This internet-draft defines the structure of Pip IDs. Pip IDs have the following characteristics: 1. They are globally unique binary strings 8 octets in length. 2. They are hierarchically structured. 3. Each component of the hierarchy is contiguous, and each hierarchical component is adjacent to its parent and child com- ponents. 4. The hierarchical structure is self-describing. That is, the hierarchical structure can be determined by examination of the ID alone. 5. Pip IDs may be used for group identification, but such a Pip ID is not self-describing as being a group Pip ID. 6. Certain Pip IDs are well-known and have local meaning, such as "all routers on the subnet" and "this host". Pip IDs are formed by a hierarchy of number authorities, each of which is responsible for assigning the next lower level of the hierarchy. While it is the intent that the hierarchical structure of Pip IDs follow administrative hierarchy (versus, for instance, topo- logical hierarchy), it is up to each number authority to determine how the next level is assigned. The top-level number authority for Pip IDs is the Internet Assigned Number Authority (IANA). Pip ID structure Semantically, the Pip ID is a series of integers, with each integer being hierarchically above the following one. For instance, the Pip ID 12.96.4993.5 has four levels of hierarchy. The IANA assigned the top-level (12). The number authority represented by the top-level number 12 assigned the following level (96), and so on. The encoding of a Pip ID is similar to (but not the same as) that of the Object Identifier encoding in ASN.1. That is, it is encoded as a series of (eight) octets, with the first bit of each octet indicating whether the next octet is part of the same integer or a new integer. If the first bit of the octet is 0, then it is the last octet of the integer. If the first bit of the octet is 1, then the following octet is part of the same integer. For instance, the integer 127 is encoded as 01111111. The integer 128, however, is encoded as 10000001 00000000. The leading 1 in the first octet indicates that the next octet is part of the same Pip WG, Expires March. 1, 1993 [Page 2] INTERNET-DRAFT Pip Identifiers September 1992 integer. The leading 0 is the second octet indicates that it is the final octet of the integer. The value 128 comes from concatinating the seven least significant bits from each of the two octets. In encoded form, all Pip IDs are "padded" out to the full 8 octets. This is done in such a way that all but the last integer is in its most compact form, and the last integer extends out to fill the 8 octets. For instance, if the last integer is 127, and there are 3 octets remaining (that is, not taken up by the previous integers), then the 127 is encoded as 10000000 10000000 01111111. This is how the Pip ID encoding differs from the ASN.1 Object Identifier encod- ing. In the ASN.1 encoding, an octet of 1000 0000 is illegal, because it represents a "wasted" octet in the case where the string of octets is variable length. As another example, consider the Pip ID 12.96.4993.5. It is encoded as: 12 00001100 96 01100000 4993 10100111 00000001 5 10000000 10000000 10000000 00000101 The 12 and 96 take up one octet each. The 4993 is greater than 127 (largest 7-bit integer), but smaller than 16383 (largest 14-bit integer), so it requires 2 octets. The 5 is the final digit, so it is extended out to the last octet with 3 octets of value 10000000. Pip ID Assignments The following Pip ID assignments exist: IP Address An IP address can be used to create a Pip ID. Thus, anybody with an IP address can use it to form a globally unique Pip ID. The three formats for a Pip ID formed from an IP address are: 1.net.subnet.host.x 1.net.subnetHost.x 1.netSubnetHost.x where the lowest level (x) is optional. All three formats have a top-level (IANA-assigned) integer of value 1. This is followed by the three ways shown above to transform the IP address into the Pip ID. After this comes any additional levels of hierarchy that the number authority represented by the IP address wishes to append. The first format (1.net.subnet.host) has at least four levels of hierarchy. The network number, subnetwork number, and host number take up the following three levels. The second format has at least 3 hierarchy levels. The network number is the second, and the subnet and host field combined (what was originally called the Host field, Pip WG, Expires March. 1, 1993 [Page 3] INTERNET-DRAFT Pip Identifiers September 1992 before subnetting was invented) is the last level. The third format has at least 2 hierarchy levels. The second level is a single integer formed from the 32-bit IP address. Thus, the IP address 129.47.233.181, with subnet mask 255.255.255.192 can form at least the following three Pip IDs: Decimal dot notation Pip ID encoding (hex) -------------------- --------------- 1.33071.934.53 01 82 82 2f 87 26 80 35 1.33071.59829 01 82 82 2f 80 83 d3 35 1.2167400885 01 80 80 88 89 bf d3 b5 Each of these IP-generated Pip IDs represents a different Pip ID. The first Pip ID (1.33071.934.53) has one octet of "padding" (the second to the last octet, x80). Thus, the owner of this IP address could append one additional level of hierarchy to form up to 127 additional Pip IDs (1.33071.934.53.0 through 1.33071.934.53.127). Note that the Pip ID 1.33071.934.53.0 is different from the Pip ID 1.33071.934.53. The former has encoding 01 82 82 2f 87 26 80 35 while the latter has encoding 01 82 82 2f 87 26 35 00. IEEE 802 Address An IEEE 802 address can be used to create a Pip ID. Thus, anybody with an IEEE 802 address can use it to form a globally unique Pip ID. The format for an IEEE 802 Pip ID is: 2.IEEE802address The top-level integer is value "2". The remainder of the Pip ID is a single IEEE 802 address. Since the IEEE 802 address is 48 bits in length, and since the remaining 7 octets only encode 49 bits, there is no room for a third level of hierarchy. Flat Well-Known IDs There are any number of uses for identifying systems of a certain type, rather than specific systems. For instance, an ID for "all routers on the LAN" is useful for router discovery. This specifica- tion defines the following well-known Pip IDs. These well-known Pip IDs consist of a single hierarchy level (the top-level), but are so large that only one level of hierarchy is possible. Any Router Decimal dot notation = 2^56-1 Pip ID encoding = ff ff ff ff ff ff ff fe Any Host Decimal dot notation = 2^56-2 Pip ID encoding = ff ff ff ff ff ff ff fd Pip WG, Expires March. 1, 1993 [Page 4] INTERNET-DRAFT Pip Identifiers September 1992 Any System Decimal dot notation = 2^56-3 Pip ID encoding = ff ff ff ff ff ff ff fc The above three well-known Pip IDs serve for functions such as "all routers on a subnet", for instance in configuration algorithms such as router discovery. Other well-known Pip IDs are expected to be defined in the future. Country Codes While it is probably adequate to assign top-level Pip ID numbers directly to organizations, there may be good reasons to assign them to countries. One reason is that it reduces the administrative bur- den on IANA for assigning top-level numbers to every possible organi- zation. Another reason is that the number of organizations in the world may be large enough that a layer of hierarchy above the organi- zation is needed for such purposes as ID-to-name directory service lookups. Therefore, the country codes listed below are defined. A considera- tion in choosing these numbers is whether the number takes up one octet or two octets. A one octet number leaves more room for further assignment, and is therefore more desirable. However, there are enough countries that not all of them can have a one-octet top-level number. One octet numbers are assigned to all countries that currently have a 1 or 2 digit CCITT country code, and two octet numbers are assigned to all countries that currently have a 3 digit CCITT country code. (As of this writing, a number of countries are missing.) The following assignments have been made: One octet assignments: Andorra 80 Argentina 81 Australia 82 Austria 83 Belgium 84 Brazil 85 Chile 86 Colombia 87 Czechoslovakia 88 Denmark 89 Egypt 90 France 91 Germany 92 Greece 93 Guantanamo Bay 94 Hungary 95 India 96 Pip WG, Expires March. 1, 1993 [Page 5] INTERNET-DRAFT Pip Identifiers September 1992 Indonesia 97 Iran 98 Italy 99 Japan 100 Korea 101 Liechtenstein 102 Malaysia 103 Mexico 104 Monaco 105 Netherlands 106 New Zealand 107 Norway 108 Pakistan 109 Peru 110 Philippines 111 Poland 112 Romania 113 San Marino 114 Singapore 115 South Africa 116 Spain 117 Sri Lanka 118 Sweden 119 Switzerland 120 Thailand 121 Turkey 122 United Kingdom 123 USA 124 Vatican City 125 Venezuela 126 Yugoslavia 127 Two octet assignments: Algeria 128 American Samoa 129 Bahrain 130 Belize 131 Bolivia 132 Cameroon 133 Costa Rica 134 Cyprus 135 Ecuador 136 El Salvador 137 Ethiopia 138 Fiji Islands 139 Finland 140 French Antilles 141 French Polynesia 142 Gabon 143 Guam 144 Guatemala 145 Guyana 146 Pip WG, Expires March. 1, 1993 [Page 6] INTERNET-DRAFT Pip Identifiers September 1992 Haiti 147 Honduras 148 Hong Kong 149 Iceland 150 Iraq 151 Ireland 152 Israel 153 Ivory Coast 154 Jordan 155 Kenya 156 Kuwait 157 Liberia 158 Libya 159 Luxembourg 160 Malawi 161 Morocco 162 Namibia 163 Netherlands Antilles 164 New Caledonia 165 Nicaragua 166 Nigeria 167 Oman 168 Panama 169 Papua New Guinea 170 Paraguay 171 Portugal 172 Qatar 173 Saipan 174 Saudi Arabia 175 Senegal 176 Suriname 177 Taiwan 178 Tunisia 179 United Arab Emirates 180 Uruguay 181 Yemen Arab Republic 182 CCITT and ISO assignments The following top-level numbers are assigned to CCITT and ISO: CCITT 10 ISO 11 Joint CCITT/ISO 12 Summary of Top-Level Pip ID Numbers 0 Reserved 1 IP 2 IEEE 802 3 to 9 Reserved 10 CCITT Pip WG, Expires March. 1, 1993 [Page 7] INTERNET-DRAFT Pip Identifiers September 1992 11 ISO 12 Joint CCITT/ISO 13 to 79 Reserved 80 to 182 Country Codes 183 to 2^56-4 Reserved 2^56-3 to 2^56-1 Well-known IDs Pip WG, Expires March. 1, 1993 [Page 8] From owner-Big-Internet@munnari.oz.au Sat Sep 19 23:29:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14085; Sat, 19 Sep 1992 23:29:49 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14077; Sat, 19 Sep 1992 23:29:41 +1000 (from chris@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA03152; Sat, 19 Sep 92 09:29:35 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA03690; Sat, 19 Sep 92 09:29:26 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209191329.AA03690@cannibal.gandalf.ca> Subject: Re: pip IDs........ To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Date: Sat, 19 Sep 92 9:29:25 EDT Cc: Big-Internet@munnari.oz.au In-Reply-To: <9209190435.AA28781@chiya.bellcore.com>; from "Paul Tsuchiya" at Sep 19, 92 12:35 am X-Mailer: ELM [version 2.3 PL11] I find it funny to hear folks complain about the size of NSAPs and then to find Pip is proposing 16 octets of IDs. Got the Sirpent paper yesterday; thanks for the pointer... -Chris Sullivan Gandalf Data Ltd. From owner-Big-Internet@munnari.oz.au Sun Sep 20 02:22:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25767; Sun, 20 Sep 1992 02:25:55 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25658; Sun, 20 Sep 1992 02:22:31 +1000 (from kre) To: Ross Callon Cc: dennis@ans.net, big-internet@munnari.oz.au Subject: Re: identifiers In-Reply-To: Your message of Fri, 18 Sep 92 16:00:20 -0400. <9209182000.AA23022@us1rmc.bb.dec.com> Date: Sun, 20 Sep 92 02:22:27 +1000 Message-Id: <4078.716919747@munnari.oz.au> From: Robert Elz Date: Fri, 18 Sep 92 16:00:20 EDT From: Ross Callon Message-ID: <9209182000.AA23022@us1rmc.bb.dec.com> There is of course one other option (which seems to be implicit in KRE's recent note, if not explicit): You could just do away with the notion that you can move a system anywhere and keep the same ID. No, I don't think I implied that, either implicitly or explicitly. Or if I did, I didn't mean to. What I said was that when a system moves, you *might* want to change the ID, whether you do or not will depend on circumstances. If I take my host along when I attend an IETF meeting, its name won't change, its ID won't change - its address will for a while - yes, the DNS will need to be updated with the new address and/or some other "redirect packets" mechanism will need to be left around (I'd actually assume "and" here, both change DNS and leave a redirect). What's more it doesn't really matter if I decide to bludge around the US for 6 months or so - that's still the same situation. The organisational ID still holds, I'm still associated with the University of Melbourne even if I'm away several months - so is my host, even if its relocated for several months or years. On the other hand, if I were go go and work with Bob Smart (he's just about 3 minutes walk down the road) and I was taking my host along with me, then it would almost certainly get a new name, a new ID, and probably a new address - regardless of the fact that its (close enough to being) still on the same ethernet (there's an FDDI ring between - its not bridged, for IP, but it could be for CLNP). The most likely thing to stay unchanged would be the address... The ID is the short format thing (suitable for packet headers) that descibes what the host IS - its almost a short(ish) binary equivalent of the domain name. While its not required, I'd tend to guess that names and ID's would either change together or not change at all. kre From owner-Big-Internet@munnari.oz.au Sun Sep 20 02:57:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26884; Sun, 20 Sep 1992 03:00:31 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26837; Sun, 20 Sep 1992 02:57:13 +1000 (from kre) To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: Identifiers, motion, and the DNS In-Reply-To: Your message of Fri, 18 Sep 92 16:42:57 -0400. <9209182042.AA24506@us1rmc.bb.dec.com> Date: Sun, 20 Sep 92 02:57:07 +1000 Message-Id: <4103.716921827@munnari.oz.au> From: Robert Elz Date: Fri, 18 Sep 92 16:42:57 EDT From: Ross Callon Message-ID: <9209182042.AA24506@us1rmc.bb.dec.com> Local allocation has two implications: Some human has to manually configure a system when its EID is assigned. Depending upon what you mean by "locally", the EID will need to change when the system moves. No no no - neither of those is necessarily true. Manual configuration is necessary only as long as we don't invent a protocol to do it. We already have ways to more or less automatically assign IP addresses to hosts when they boot, and that's a much more difficult problem than assigning EID's, as IP addresses have all these topological constraints built in - to assign an EID all the server needs to do is allocate the next available number, and then remember it in case the client asks again. I think the question of movement has been covered already, but I think I see a misconception creeping it - we want the EID assigned locally so the administration of the directory can be done easily. After that, if the directory doesn't need to be changed (manually at least) then it doesn't matter where the system moves, the administration is done - how far the system moves away from its directory then no longer matters at all - its all to ease the human workload, not save a few hops in packets in the occasional lookups. The only thing intrinsically more difficult in local EID assignment is that the local site needs to obtain (from somewhere) a range of EIDs that it can assign - just as it needs to obtain a domain name, and an NSAP prefix, etc. True, if the EID is stamped in the hardware then there is one less thing needed to get started - but this small disadvantage I'm willing to live with. Now I don't fully understand what you are proposing. You say that EIDs are assigned locally, but that they don't change with much frequency. When do they change, and when do they stay the same? I think I answered this one in my previous message, if not, pelase ask again. Well, the directory maintenance problem is indeed made worse if you rely on using the EID as the directory lookup (rather than the full address), and if you use an ID which hardly ever changes (so that systems move much more quickly than IDs change, implying that most systems' ID has no relationship with its present location). However, note that this complication of the ID to name lookup is caused by the slowness of the change in ID, not by the fact that one might use IEEE IDs rather than some other pretty much permanent ID. I think you're confusing yourself here - in the latter part you're talking about the lookup, which truly is more complicated if the directory isn't local (well, its likely to be slower, use more net resources, etc). But this is close to immaterial - there's probably not likely to be much reason that my host will ever want to be looking up its EID (how often do your hosts look up their own IN-ADDR.ARPA records??) Its other hosts, typically ones I am communicating with that will be doing this lookup, and they are likely to be located anywhere, there's no reason to assume that it will be any easier or harder for them to lookup in a directory topologically near where my EID was originally assigned rather than near where the EID is currently located. About the only complication will be if the EID directory is cut off from the rest of the net, which includes both the location of the EID itself, and its communications peer who is attempting to lookup the EID. This will mean having off site repositories of the EID directory will be more important than off site IN-ADDR.ARPA DNS servers, but I don't think that's a big deal. The first part of your paragraph mentions "maintenance", which is truly the real problem, the one that involves humans, and so is the one that needs real work to keep it simple and easy, or it will certainly come back to haunt us - but after installation, maintenance should only be necessary when the EID or name changes - if iether of those happens, then the EID can be changed (even if the original intent was only to change the name) so that its located in whatever directory happens to be convenient for maintenance purposes. Also, this paragraph makes it clear that you don't understand the TUBA proposal. We explicitly are planning that the TCP connection does not break when the address changes (why else would be be doing all this discussion about globally unique IDs??). I think I do understand - perhaps I was being overly heavy, but in some discussions on the other list (TUBA) I got the impression that some people didn't really understand what the ID should do, in fact, even why it should exist - I was just pointing out the obvious. Others clearly did understand. Why does the EID that TCP uses for identifying connections have to be identical to the thing (address or name) which is used for "incoming network packet to name" lookup? Couldn't we use the complete address to lookup the name, but only use the ID to identify the TCP connection? Yes, you could, but do you really want to. Remember addresses of some hosts are going to be changing by the minute, so you really want to have to update an address -> name mapping that frequently (the name -> address mapping only really needs to change for major address changes, minor ones can easily be handled by some kind packet redirectors in the routers). I wouldn't even have an address->name (or address->anything) mapping, I don't see the point, all the address is for is to get your packets through the net to their destination, depending on how policy is implemented, there may even be hundreds of concurrently applicable, yet different addresses for the same host (same service on the same host) that implement different routes through the nets based on some policy constraint chosen by the user (eg: sensitive data, use secure nets, even if that means a slower path). If the EID is in the packet somewhere, either imbedded in the address, or elsewhere in the headers, I'd just use it, there are likely to be less EID's than addresses (so the directory will be smaller) and they're likely to be stable considerably longer. As I mentioned above, figuring out details like this is why I consider this discussion of IDs to be worthwhile. I agree completely. This is certainly true. Mistakes do happen. However, is there another scheme which quarantees that network managers won't make mistakes, and give two hosts the same ID? I doubt it, if there is I don't know it. What matters however is how you resolve the problem when you discover it. If EID's are locally assigned, you just assign a new one to one of those with the conflict (perhaps both) - simple, easy, and fixes the problem in no time at all. On the other hand what do you do if you discover that some toaster made in Japan has been given the same IEEE number as my toaster - that one was sold in Chad, 10 years ago, and only just finally connected onto the net - in the meantime the manufacturer has decided that toasters are a lousy product, and has moved onto selling junk bonds instead, and no longer has any employees that know anything about IEEE ID's in order to fix things - to whom do you turn to get an isolated new IEEE ID? I also hope that we're not boring anyone - if you're reading all this and feeling bored, I would suggest that perhaps you take the time to think about the issue a little, its not as simple as it might seem, and it is important. This is particularly if you're an administrator type of person, rather than a designer, because its the admins who are going to have to deal with whatever mess the designers land on us all... kre From owner-Big-Internet@munnari.oz.au Sun Sep 20 03:12:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27149; Sun, 20 Sep 1992 03:13:07 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27141; Sun, 20 Sep 1992 03:12:53 +1000 (from kre) To: John Curran Cc: Big-Internet@munnari.oz.au Subject: Re: Identifiers, motion, and the DNS In-Reply-To: Your message of Fri, 18 Sep 92 18:40:09 -0400. Date: Sun, 20 Sep 92 03:12:48 +1000 Message-Id: <4155.716922768@munnari.oz.au> From: Robert Elz Date: Fri, 18 Sep 92 18:40:09 -0400 From: John Curran I agree with everything you say, except... IEEE numbers certainly do not have the necessary characteristics for directory lookup. this isn't true, IEEE numbers are no harder to lookup than IPv4 addresses. the server you end up using may be located anywhere, but its not intrincically harder to fine 11.20.07.20.00.08.ieee.arpa than an in-addr.arpa domain. What's hard is figuring out just who I should ask to register my workstation in that directory, its certainly not likely to be located anywhere near where I am. kre From owner-Big-Internet@munnari.oz.au Sun Sep 20 04:06:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29268; Sun, 20 Sep 1992 04:09:26 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29160; Sun, 20 Sep 1992 04:06:20 +1000 (from kre) To: Ross Callon , dennis@ans.net, big-internet@munnari.oz.au Subject: Re: identifiers In-Reply-To: Your message of Sun, 20 Sep 92 02:22:27 +1000. <4078.716919747@munnari.oz.au> Date: Sun, 20 Sep 92 04:06:15 +1000 Message-Id: <4309.716925975@munnari.oz.au> From: Robert Elz I sad, without really thinking ... The ID is the short format thing (suitable for packet headers) that descibes what the host IS and if I don't correct that quickly I'm pretty sure Noel is going to jump all over me (and correctly). An ID doesn't necessarily represent a host, its a conversation endpoint, of which there may be many in a host, and conversely, its even possible that an EID could move from one host to another, or represent several "hosts" (all the time keeping open connectins open). Still, thinking of it as representing a host does make it a bit easier for most purposes... kre From owner-big-internet@munnari.oz.au Sun Sep 20 04:15:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29509; Sun, 20 Sep 1992 04:15:10 +1000 (from owner-big-internet) Return-Path: Message-Id: <9209191815.29509@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27858; Sun, 20 Sep 1992 03:38:51 +1000 (from jcurran@nic.near.net) To: Robert Elz Cc: Big-Internet@munnari.oz.au Subject: Re: Identifiers, motion, and the DNS In-Reply-To: Your message of Sun, 20 Sep 92 03:12:48 +1000. <4155.716922768@munnari.oz.au> Date: Sat, 19 Sep 92 13:38:44 -0400 From: John Curran -------- ] From: Robert Elz ] Subject: Re: Identifiers, motion, and the DNS ] Date: Sun, 20 Sep 92 03:12:48 +1000 ] ] Date: Fri, 18 Sep 92 18:40:09 -0400 ] From: John Curran ] ] I agree with everything you say, except... ] ] IEEE numbers certainly do not have the necessary characteristics for ] directory lookup. ] ] this isn't true, IEEE numbers are no harder to lookup than IPv4 addresses. ] the server you end up using may be located anywhere, but its not ] intrincically harder to fine 11.20.07.20.00.08.ieee.arpa than an ] in-addr.arpa domain. Yep. ] What's hard is figuring out just who I should ask to register my workstation ] in that directory, its certainly not likely to be located anywhere near ] where I am. Thanks for pointing this out. Stamp out ambiguity whenever possible. Here is obviously what I should have said: IEEE numbers certainly do not provide an administrative hierarchy which supports convenient registration in a distributed directory. Not only do you have to find the right registration authority, but said authority will be hard pressed to perform any form of authentication on your request. /John From owner-Big-Internet@munnari.oz.au Sun Sep 20 04:30:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00150; Sun, 20 Sep 1992 04:33:43 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29980; Sun, 20 Sep 1992 04:30:27 +1000 (from kre) To: carlberg@cseic.saic.com (Kenneth Carlberg) Cc: callon@bigfut.enet.dec.com, big-internet@munnari.oz.au Subject: Re: dynamic servers (was something else...) In-Reply-To: Your message of Fri, 18 Sep 92 20:31:48 -0400. <9209190031.AA01887@cseic.saic.com> Date: Sun, 20 Sep 92 04:30:20 +1000 Message-Id: <4354.716927420@munnari.oz.au> From: Robert Elz Date: Fri, 18 Sep 92 20:31:48 EDT From: carlberg@cseic.saic.com (Kenneth Carlberg) Message-ID: <9209190031.AA01887@cseic.saic.com> I'm not sure that we actually need to solve the problem of mobile hosts right now, or at least not in the context of solving the address space and routing problems - what we do need to do is make sure that we realise that mobile hosts do exist, and will become more common, and that we leave in place mechanisms by which they can be supported (which sholdn't be too hard if they can be handled in IPv4 - but we shoudl be able to do better than that.) Lets assume a number of wireless LANs are resident in a facility that contains several labs (software, hardware, etc.). Furthermore, groups of labs are configured as separate Areas, ala OSPF, within a domain. However ... I think we're going to need several different mechanisms, not just one, which will work together to make mobile hosts work well. That's because there are different kinds of mobility - and the optimal solutions to deal with the different kinds are not going to be all the same. The situation you described is one of very localised motion, in that case I certainly wouldn't be doing anything to the DNS at all, you're just as likely to move back to your original lab in a few minutes. That kind of motion almost certainly wants to be handled by protocols between the controllers/routers/whatever that are managing traffic between te labs - they simply keep track of which address is on which net (in which lab), and route the packets between themselves so that they eventally arrive at the host, wherever the sender thought the host may have been located. This is just the same as is done with cellular phones when you move from one cell to another. On the other hand, long distance motion is another thing entirely, and while we almost certainly want some way to redirect packets from the host's old location(s) to its current one, there we will want to do DNS changes so future conversations use a new address. But this kind of motion happens much less frequently, and then takes longer to occur when it does happen - far fewer hosts will be moving from one side of the country or world to the other than will be moving around in a building, or travelling from the office to home, and they will take considerably longer to actually move (hours at least, rather that perhaps just seconds). The procedures to be adopted can vary. What's more, we also can catergorise based on random or predictable movements - many hosts are likely to move predictably (from work to home and back, over and over, or around inside a building), than move unpredictably (just turn up at some random point and start transmitting). Its reasonable that we may have different mechanisms to handle those two cases, there may be something we can do to cause predictable movement to be handled much more effeciently than unpredictable, perhaps by using a (locally) well known address class for such hosts so the routers would know that this address is one that might be in one of several well known places. At this stage, just make sure that we don't do anything to prevent mobile hosts working, and then leave it to the people with a real interest in this area to work out just how they really want to make it work. kre From owner-Big-Internet@munnari.oz.au Sun Sep 20 06:45:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04558; Sun, 20 Sep 1992 06:45:11 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04553; Sun, 20 Sep 1992 06:45:02 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA01924; Sat, 19 Sep 92 13:44:42 -0700 Date: Sat, 19 Sep 92 10:40:26 EDT From: "William Allen Simpson" Message-Id: <732.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: identifier mapping I hereby call for a complete elimination of the term "address" from our vocabulary. We keep getting confused about semantics. I assert that everyone is now in agreement that we need three methods of identifying an entity participating in a communication, having seen no evidence to the contrary in the past month. Here is a snapshot of my thoughts on the problem of mapping the end-point-identifier to domain-name and routing-locator. 1) In order to be mappable, the end-point-identifier must be able to be found. Therefore, it needs: a) a primary server where it is maintained. b) internal structure which indicates the primary server location. This should be relatively easy to do, since the distribution and lookup mechanism already exists. 2) In order to be "mobile" (move without breaking current connections), the EPI to routing-locator need not be changed at the server. The router indicated by the routing-locator must issue "redirects", but only to the originating system and other routers in the path. This is not such a hard problem, since there already exist "trust" mechanisms within an administrative domain. However, mobility across ADs is problematic. But it is solvable, since the system is "known" to the routing area it is currently inhabiting, so there is limited ability to "spoof" movement. 3) In order to be "portable" (appear with no current connection), the EPI to routing-locator probably should be updated at the server. The routers within the original domain also need to be updated concurrently, so that new connections opened for the old location during the "update window" can be redirected. This is a tough problem, beyond the scope of currently deployed routing protocols. The mechanism needs a considerable degree of authentication, otherwise someone may easily "spoof" the system. There would need to be dynamic cooperation between routing protocols and the server. I suggest that we concentrate on problems 1 & 2. If we don't need dynamic updates of the mapping server, current protocol mechanisms should suffice. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Sun Sep 20 08:52:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08078; Sun, 20 Sep 1992 08:52:21 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08075; Sun, 20 Sep 1992 08:52:16 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Sat, 19 Sep 92 18:51:09 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Sat, 19 Sep 92 18:51:08 EDT Date: Sat, 19 Sep 92 18:51:08 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9209192251.AA29441@chiya.bellcore.com> To: chris@gandalf.ca, tsuchiya@thumper.bellcore.com Subject: Re: pip IDs........ Cc: Big-Internet@munnari.oz.au > > I find it funny to hear folks complain about the size of NSAPs and then to > find Pip is proposing 16 octets of IDs. > Yep, Pip is getting up there......the "fixed" part is now 36 octets. A typical FTIF Chain is likely to be another 4 octets for intra-LAN traffic, and another 16 octets for inter-domain traffic.........total 52 octets for inter-domain traffic. What is the "fixed" header of CLNP (at least 40 octets--for the addresses.....)? PX From owner-Big-Internet@munnari.oz.au Sun Sep 20 21:41:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03759; Sun, 20 Sep 1992 21:41:20 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03756; Sun, 20 Sep 1992 21:41:14 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA19104 (5.65b/CWI-2.176); Sun, 20 Sep 1992 13:41:08 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA19065; Sun, 20 Sep 92 13:41:34 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA17247; Sun, 20 Sep 92 13:41:04 +0200 Message-Id: <9209201141.AA17247@dxcern.cern.ch> Subject: Re: identifiers To: big-internet@munnari.oz.au Date: Sun, 20 Sep 92 13:41:03 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <4309.716925975@munnari.oz.au>; from "Robert Elz" at Sep 20, 92 4:06 am X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Robert Elz follows: > An ID doesn't necessarily represent a host, its a conversation endpoint, > of which there may be many in a host, and conversely, its even possible > that an EID could move from one host to another, or represent several > "hosts" (all the time keeping open connectins open). > Well lots of people will shout at me but since I will be away for a week here goes: Isn't the above an almost exact functional description of an OSI NSAP, at least as intended by its designers? Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | From owner-Big-Internet@munnari.oz.au Mon Sep 21 00:00:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08101; Mon, 21 Sep 1992 00:00:25 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08051; Mon, 21 Sep 1992 00:00:11 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA92204 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 20 Sep 1992 09:59:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 20 Sep 1992 09:59:37 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 20 Sep 1992 09:59:37 -0400 From: Dennis Ferguson Message-Id: <199209201357.AA62926@foo.ans.net> To: Brian Carpenter CERN-CN Cc: big-internet@munnari.oz.au Subject: Re: identifiers In-Reply-To: (Your message of Sun, 20 Sep 92 12:41:03 GMT.) <9209201141.AA17247@dxcern.cern.ch.ans-relay> Date: Sun, 20 Sep 92 09:57:41 -0500 Brian, >> An ID doesn't necessarily represent a host, its a conversation endpoint, >> of which there may be many in a host, and conversely, its even possible >> that an EID could move from one host to another, or represent several >> "hosts" (all the time keeping open connectins open). >> > Well lots of people will shout at me but since I will be away for > a week here goes: > > Isn't the above an almost exact functional description of > an OSI NSAP, at least as intended by its designers? Yes. In fact, wasn't the design principle that "NSAP addressing should be independent of network topology" (I would give you the exact chapter-and-verse if my ISO library wasn't 500 miles west of here, this is almost my favourite quote)? The problem with this is that the designers failed (miserably) to follow through and give us routing technology which would allow one to maintain routing for NSAPs which were "independent of network topology" on anything near the scale of the Internet. In fact we know that if we are to avoid severe limitations on the size to which a ubiquitously connected CLNP Internet can be grown then the contents of NSAPs must be intimately tied to network topology, and must change as network topology changes and/or as you disconnect from one part of the Internet topology and connect to another. Because of this, what you are seeing now is much rushing around to retrofit the protocol with the understanding that you need both end-point identification information (which is the only thing NSAPs were supposed to provide) and topology/routing/how-to-get-there information (which NSAPs were supposed to be free of), and that it is much better to keep these as separate and distinct as possible since this minimizes the disruption when the latter information needs to be changed. So, I think you are right that the ID portion of the NSAP by itself is being given semantics which the designers intended for the entire NSAP. This is being done since the designers (in their infinite wisdom) didn't see fit to provide anywhere to store the information which the rest of the NSAP will, of necessity, be used to carry. It is not difficult to dislike some OSI protocols, to tell the truth. I sometimes have to work hard to avoid doing so. The phrase "obsolete before it was implemented" often comes to mind. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Mon Sep 21 17:23:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16144; Mon, 21 Sep 1992 17:24:17 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16133; Mon, 21 Sep 1992 17:23:57 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA07047; Mon, 21 Sep 1992 09:24:38 +0200 Message-Id: <199209210724.AA07047@mitsou.inria.fr> To: Robert Elz Cc: Big-Internet@munnari.oz.au Subject: Re: Identifiers, motion, and the DNS In-Reply-To: Your message of "Sat, 19 Sep 92 03:54:54 +1000." <3761.716838894@munnari.oz.au> Date: Mon, 21 Sep 92 09:24:38 -0400 From: Christian Huitema X-Mts: smtp Robert, You are absolutely right. DNS (directory?) look-up based on EID is essential. What works with current IP addresses should continue to work with the next generation. One more point. Yes, as Noel mentions, the current IP routing scheme would be difficult to interpolate if the Internet grows 10**6 times bigger. But the fact is that it (almost) work today, at least in limited "realms". I dont see why we should fix what is NOT broken; on the contrary, we should build upon it. So, yes, "routing masks", as in CIDR or BGP, are here to stay. What is not here to stay is the requirement that each and every router in the world knows from some mutant BGP the route to each and every destination in the world. Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Sep 21 17:54:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17338; Mon, 21 Sep 1992 17:54:44 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209210754.17338@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17332; Mon, 21 Sep 1992 17:54:36 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 21 Sep 1992 08:53:59 +0100 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: chris@gandalf.ca, Big-Internet@munnari.oz.au, J.Crowcroft@cs.ucl.ac.uk Subject: Re: pip IDs........ In-Reply-To: Your message of "Sat, 19 Sep 92 18:51:08 EDT." <9209192251.AA29441@chiya.bellcore.com> Date: Mon, 21 Sep 92 08:53:59 +0100 From: Jon Crowcroft >> I find it funny to hear folks complain about the size of NSAPs and then to >> find Pip is proposing 16 octets of IDs. >Yep, Pip is getting up there......the "fixed" part is now >36 octets. A typical FTIF Chain is likely to be another >4 octets for intra-LAN traffic, and another 16 octets >for inter-domain traffic.........total 52 octets for >inter-domain traffic. What is the "fixed" header of >CLNP (at least 40 octets--for the addresses.....)? yeah - but the PIP header is all useful, whereas 15 bytes of each source & dest nsap are pre-allocated in most assignment schemes:-) jon From owner-Big-Internet@munnari.oz.au Mon Sep 21 21:58:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25039; Mon, 21 Sep 1992 21:58:45 +1000 (from owner-Big-Internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25036; Mon, 21 Sep 1992 21:58:38 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA21098; Mon, 21 Sep 92 05:58:31 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA13051; Mon, 21 Sep 92 05:58:30 MDT Message-Id: <9209211158.AA13051@goshawk.lanl.gov> To: Dennis Ferguson Cc: Ross Callon , big-internet@munnari.oz.au Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: Your message of Thu, 17 Sep 92 13:18:48 -0500. <199209171718.AA50013@foo.ans.net> Date: Mon, 21 Sep 92 05:58:30 MST From: peter@goshawk.lanl.gov >>> But what if your service contract is swap, instead of repair? Then you >>> shouldn't manually configure anything, since the next owner of your portable >>> may end up using the same ID. With our old Sun maintenance, the official policy (by the book) was to pull the ethernet ID chip out of the original motherboard during a swapout, which had the nice property of not invalidating the distributed yellow page (yuk) map between ether-addrs and IP address for rarping. In the future one can imagine that I will keep my N-bit unique IDs on a smart card which I then push into any machine, including the followons to the ATT Public Phone 2000s. cheers, peter From owner-big-internet@munnari.oz.au Tue Sep 22 00:11:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00322; Tue, 22 Sep 1992 00:11:59 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27607; Mon, 21 Sep 1992 23:32:37 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA27558; Mon, 21 Sep 92 06:32:21 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA03740; Mon, 21 Sep 1992 09:32:16 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: <9209181504.AA00238@ginger.lcs.mit.edu> References: <9209181504.AA00238@ginger.lcs.mit.edu> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: David R. Oran Date: Mon, 21 Sep 92 09:32:15 -0400 Message-Id: <920921093215.226@sneezy.lkg.dec.com> Encoding: 23 TEXT, 6 TEXT SIGNATURE > > Yes, but then again, security in the network is pretty much a swiss cheese > anyway. We need to securely relate something like a private key to each > identifier. Hmm, maybe the thing to do is make the locally allocated part of > the identifier a private key... (Aiieeeee, 128 bit Identifiers :-). > Noel, I think you meant to say something different from what you actually said. If you make the locally allocated part of the id a private key, and then put the id in the packets unencrypted, it isn't private anymore, now is it? If you put it in the packet encrypted, what key do you use to decrypt the pacekt to get the (redundant?) private key? Did you mean PUBLIC key? If so, we're talking about 512-1024 bits, not 128. I don't think any of this is necessary. There are well-understood ways to do crypto demultiplexing with multiple identifiers and multiple keys. Most of them use key-id's of some sort which are short and bound to the real keys. If the rest of the identifier is long enough to be unambiguous, this works fine. If you need to actually recover the private key from the packet, there's a clever technique of recursive key encapsulation which works great if your crypto hardware can switch keys in a few byte times. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Tue Sep 22 00:54:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01479; Tue, 22 Sep 1992 00:54:28 +1000 (from owner-big-internet) Return-Path: Received: from [140.185.30.10] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28693; Tue, 22 Sep 1992 00:00:41 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA06169; Mon, 21 Sep 92 08:43:45 CDT From: Matt Jonson Message-Id: <9209211343.AA06169@server.af.mil> Subject: Re: Identifiers, motion, and the DNS To: kre@munnari.oz.au (Robert Elz) Date: Mon, 21 Sep 92 8:43:39 CDT Cc: callon@bigfut.enet.dec.com, big-internet@munnari.oz.au In-Reply-To: <4103.716921827@munnari.oz.au>; from "Robert Elz" at Sep 20, 92 2:57 am X-Mailer: ELM [version 2.3 PL11] > Subject: Re: Identifiers, motion, and the DNS > a slower path). If the EID is in the packet somewhere, either imbedded > in the address, or elsewhere in the headers, I'd just use it, there are > likely to be less EID's than addresses (so the directory will be smaller) > and they're likely to be stable considerably longer. [...] > you resolve the problem when you discover it. If EID's are locally > assigned, you just assign a new one to one of those with the conflict > (perhaps both) - simple, easy, and fixes the problem in no time at all. Pretty soon your EID is no longer a short-cut, but to allow for necessary assignment hierarchy (to permit truly local assignments), it is the size of the NSAP, which perhaps isn't feasible to imbed inside an "address" that also has to contain heierarchical routing information. If we accept this as necessary, then we probably must accept a separate routing information field in the packet header, or come up with a way to fit both into a reasonable number of octets, while still providing that sort of administration and a necessary amount of routing detail... It seems to me that maybe EIDs should be locally assigned while routing information is globally "discovered" and treated entirely separately. /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 From owner-Big-Internet@munnari.oz.au Tue Sep 22 01:13:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02135; Tue, 22 Sep 1992 01:13:58 +1000 (from owner-Big-Internet) Return-Path: Received: from ub4b.buug.be by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02132; Tue, 22 Sep 1992 01:13:38 +1000 (from alcbel!alcbel.be!dach) Received: from alcbel.UUCP by ub4b.buug.be (5.65c/ub4b_02) id AA19075; Mon, 21 Sep 1992 17:13:31 +0200 Received: by alcbel.be (4.1/SMI-4.1) id AA10248; Mon, 21 Sep 92 14:03:20 +0200 Date: Mon, 21 Sep 92 14:03:20 +0200 From: dach@alcbel.be (Dirk Van Achter) Message-Id: <9209211203.AA10248@alcbel.be> To: big-internet@munnari.oz.au Subject: Request for subscription & archive Could I please be added to the big-internet mailing list ? Could you direct me to a site where this mailing list is being archived (preferably with mail-access ), in order not to have to ask questions which have been posed before ? Thank you. Dirk Van Achter Research Center RC1 e-mail : dach@alcbel.be Alcatel-Bell phone : +32 3 240 9058 Francis Wellesplein 1 fax : +32 3 240 9932 B-2018 Antwerpen (Belgium) From owner-Big-Internet@munnari.oz.au Tue Sep 22 01:43:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03251; Tue, 22 Sep 1992 01:43:42 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209211543.3251@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03245; Tue, 22 Sep 1992 01:43:34 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 21 Sep 1992 16:43:20 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: why to encode location info into IDs In-Reply-To: Your message of "Fri, 18 Sep 92 12:16:46 EDT." <9209181616.AA01374@ginger.lcs.mit.edu> Date: Mon, 21 Sep 92 16:43:17 +0100 From: Zheng Wang > Why do people persist in trying to use a hammer to drive screws? If it >encodes the location, it is not an identifier, but an address, unless both your >addresses and your identifiers encode location. > If so, what's the use of having two things which do much the same > thing? The location info in ID and in address are different. Let me explain using an example (for simplicity, we use letters instead of digits but this should only affect the size of the IDs) Suppose you need an ID for your portable PC. The PC can be assigned a flat ID as "ABCDEFGH". When I want to talk to your PC, I have to find your current location or "address". For flat IDs, we can look up by a number of servers as you have described before, i.e. first look up the root server responsible for digit "A", then the second level server for "AB", and so on until you find the server for "ABCDEFGH". And I find that you are in South Africa. Now if you PC is given an ID as "MIT-NOEL", I can look it up directly from the server at MIT. Note that the ID is not changed even you are in SA. The location info encoded in the ID is used for locating the server more quickly. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Sep 22 06:51:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12982; Tue, 22 Sep 1992 06:51:09 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12979; Tue, 22 Sep 1992 06:51:00 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA24731; Mon, 21 Sep 92 13:50:54 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA04962; Mon, 21 Sep 1992 16:50:53 -0400 To: Jon Crowcroft Subject: Re: pip IDs........ In-Reply-To: <9209210754.17338@munnari.oz.au> References: <9209210754.17338@munnari.oz.au> Cc: tsuchiya@thumper.bellcore.com, Big-Internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: David R. Oran Date: Mon, 21 Sep 92 16:50:52 -0400 Message-Id: <920921165052.226@sneezy.lkg.dec.com> Encoding: 23 TEXT, 6 TEXT SIGNATURE > > >> I find it funny to hear folks complain about the size of NSAPs and then to > >> find Pip is proposing 16 octets of IDs. > >Yep, Pip is getting up there......the "fixed" part is now > >36 octets. A typical FTIF Chain is likely to be another > >4 octets for intra-LAN traffic, and another 16 octets > >for inter-domain traffic.........total 52 octets for > >inter-domain traffic. What is the "fixed" header of > >CLNP (at least 40 octets--for the addresses.....)? > > yeah - but the PIP header is all useful, whereas 15 bytes of each > source & dest nsap are pre-allocated in most assignment schemes:-) > Could you tell me what these 15 bytes are? If you're referring to the high order parts in the E.164 and X.121 formats, I would argue that these are by no means useless administrative overhead, but in fact are extremely useful prefixes for agregating routing information, since they have quite a bit of topological significance. In the case of formats which do *not* carry useful routing information, the size of the administrative part is considerably smaller, on the order of 3-5 bytes. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Tue Sep 22 06:58:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13252; Tue, 22 Sep 1992 06:58:25 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13238; Tue, 22 Sep 1992 06:58:03 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA25182; Mon, 21 Sep 92 13:57:55 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA04965; Mon, 21 Sep 1992 16:57:54 -0400 To: peter@goshawk.lanl.gov Subject: Re: identifiers (was, NSAP AFI for IP) In-Reply-To: <9209211158.AA13051@goshawk.lanl.gov> References: <9209211158.AA13051@goshawk.lanl.gov> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: David R. Oran Date: Mon, 21 Sep 92 16:57:53 -0400 Message-Id: <920921165753.226@sneezy.lkg.dec.com> Encoding: 32 TEXT, 6 TEXT SIGNATURE > > > >>> But what if your service contract is swap, instead of repair? Then you > >>> shouldn't manually configure anything, since the next owner of your portable > >>> may end up using the same ID. > > With our old Sun maintenance, the official policy (by the book) was to pull > the ethernet ID chip out of the original motherboard during a swapout, which > had the nice property of not invalidating the distributed yellow page (yuk) > map between ether-addrs and IP address for rarping. > This is true of DEC boards too. Are there any vendors who do not socket their ID roms and also do "FRU swaps" (field replaceable units)? Only this kind of policy will lead to confusion. > In the future one can imagine that I will keep my N-bit unique IDs > on a smart card which I then push into any machine, including the > followons to the ATT Public Phone 2000s. > This is fine if the ID is supposed to be "Peter Ford". It isn't so great if the ID is supposed to be "Peter Ford's Computer". It wouldn't be nice to have the LANL network management staff dispatched to fix your machine when they see a bunch of error packets only to find out you were faking everybody out on the phone from 2000 miles away. If we're talking about IDs for the purpose of deciding whether the right machine got a packet, it's best to keep these ideas separate from the identification of users, applications, etc. The Appletalk floating address scheme is peachy-keen for the users, but hell for the network managers. Dave. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Tue Sep 22 08:02:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15193; Tue, 22 Sep 1992 08:02:18 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15181; Tue, 22 Sep 1992 08:02:03 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA06073; Mon, 21 Sep 92 15:01:32 -0700 Received: by us1rmc.bb.dec.com; id AA24652; Mon, 21 Sep 92 17:58:53 -0400 Message-Id: <9209212158.AA24652@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Mon, 21 Sep 92 17:58:55 EDT Date: Mon, 21 Sep 92 17:58:55 EDT From: Ross Callon To: oran@sneezy.lkg.dec.com, dennis@ans.net Cc: big-internet@munnari.oz.au Apparently-To: oran@sneezy.lkg.dec.com, dennis@ans.net, big-internet@munnari.oz.au Subject: re: is NSAP addressing independent of routes? >> Yes. In fact, wasn't the design principle that "NSAP addressing should >> be independent of network topology" (I would give you the exact >> chapter-and-verse if my ISO library wasn't 500 miles west of here, this >> is almost my favourite quote)? > > As someone who was there at the time, I can fairly confidently answer your > question with: No. > > The design principle was that NSAP addressing be independent of routes, > which is not exactly the same thing. The reason for the design principle > was a (justifiable) fear by me, Lyman Chapin, Dave Piscitello, Ross Callon, > and others present during that (ignoble?) time that the provider-based > addressing schemes being discussed (X.121 was the major culprit) would be > used as a bludgeon to force routes to go only via those providers. At the time that the NSAP format was first discussed, there was a proposal that NSAP addresses consist of what is essentially source routes (oddly, a similar approach seems to have come up more recently). The consensus was that source routes do not make good addresses. The design principle therefore is as Dave remembers: that addresses are independent of routes. However, the address most certainly does have topological significance. Ross From owner-Big-Internet@munnari.oz.au Tue Sep 22 09:01:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17085; Tue, 22 Sep 1992 09:01:26 +1000 (from owner-Big-Internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17078; Tue, 22 Sep 1992 09:01:17 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA17348; Mon, 21 Sep 92 19:01:48 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9209212301.AA17348@wizard.gsfc.nasa.gov> Subject: Another Scheme for Assigning End-point IDentifiers To: big-internet@munnari.oz.au Date: Mon, 21 Sep 92 19:01:47 EDT X-Mailer: ELM [version 2.3 PL11] How about just doing some kind of direct binary encoding of the DNS name to get the EID? It seems to me both natural and intuitive that both the DNS name and the EID name the same entity. One is just more useful for humans to use directly and the other is more efficient for machines to use. The DNS or some other mechanism could then be used to map the name/EID to an address and/or routing directive, since this is the mapping that is really the most dynamic. Under this scheme, my machine wizard.gsfc.nasa.gov might have an EID something like: gov.nasa.gsfc.wizard 38 .62 .10 .3764 The numbers in my example are somewhat arbitrary but are just meant to represent a binary value for that branch at that point in the DNS tree, i.e. gov=38 would just mean that gov was the 38th name registered in the root directory. You could use the self-defining variable-length encoding suggested by the recent PIP document to minimize the overall length of the EID field. I leave it to someone else to determine the worst case with the present DNS database. Although it might take a few more bits overall, I think it would be a very natural and useful mapping. Note that machines could of course move around and still retain their EID as long as it continued to be registered with the appropriate DNS authority. People could choose to change their ID if they changed their directory service but it wouldn't be required (it might be a function of the charging policies of the directory services provider whether or not a user decided to change their EID in the case of a permanent move). In general, I think the directory services provider would be situated "close" to the end user but everything would still work no matter how far apart they were at any given instant. It would just result in more network overhead to do the various mappings if they happen to be far apart. Comments? -Bill From owner-Big-Internet@munnari.oz.au Tue Sep 22 15:23:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02047; Tue, 22 Sep 1992 15:24:10 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02030; Tue, 22 Sep 1992 15:23:44 +1000 (from kre) To: Matt Jonson Cc: big-internet@munnari.oz.au Subject: Re: Identifiers, motion, and the DNS In-Reply-To: Your message of Mon, 21 Sep 92 08:43:39 -0500. <9209211343.AA06169@server.af.mil> Date: Tue, 22 Sep 92 15:23:39 +1000 Message-Id: <5422.717139419@munnari.oz.au> From: Robert Elz Date: Mon, 21 Sep 92 8:43:39 CDT From: Matt Jonson Message-ID: <9209211343.AA06169@server.af.mil> Pretty soon your EID is no longer a short-cut, but to allow for necessary assignment hierarchy (to permit truly local assignments), it is the size of the NSAP I think this is based on an overly rigid view of what's necessary in the hierarchy. The aim is to minimise human maintenance work in the directory, (both by the directory maintainer, and the person who wants to get them registered, in the cases that they're not the same). That doesn't imply that when I want an EID I hate to go ask my local work group leader, who takes one from his hoard of numbers set aside for the purpose, and which he has obtained from the department head, how has her own (bigger) store of available groups of EID's that she obtained from the campus administrator, which he took from his (even bigger) group of numbers obtained from the university administration, which they obtained from the state education number authority, from the range allocated to them by the overall state co-ordinator, which all came from the country range, which in turn comes from the OSI sub-part of the total number range. That much, and that rigid, kind of hierarchy cause lots of wastage of numbers (every level down the chain has a big enough piece allocated for all they think they'll ever need) and indeed requires large numbers of bits. All that's needed is a couple of levels, perhaps 3 at the most, from the individual needing the EID to the top level of the hierarchy, just enough to get things close. There doesn't need to be any kind of "only xxx types of organisations can get a number from me, you're only a part of that, convince your superiors to request a range of EID's" - even in the case that someone else, higher, lower, or on the same level as me in my organisation has obtained some numbers shouln't stop me getting some directly from the top level hierarchy. The only criterea should be that I need enough numbers that a big enough block can be allocated to me at that level so that directory partitioning will work, and that I will actually use at least most of what I'm given, so that wastage of EID's is not too great. Note: its not even really a requirement that the numbers I am allocated be in a directory that's "local" to me by any definition of what most people would call local - certainly net topology is 100% irrelevant. For me, "local" means I know where to go to get things registered in the directory (ie: I know who is responsible) and I trust them to install the directory entries I request, it doesn't really matter what the physical proximity is like - in fact, temporal proximity could be more useful - it would probably be an advantage to have the directory server people (who probably also allocate the EIDs) be working in the same timezone as I do, which doesn't necessarily have anything whatever to do with where I am located. One (another) of the big problems of any kind of EID that simply comes with the equipment is the lack of knowledge that comes along with it - I get this thing, but "What am I supposed to do with it now?" An advantage of requiring users to take some kind of action is that along with the answer they obtain containing their EID, they can also be told what they should do to get it registered - or backwards, part of obtaining the EID may require supplying the details necessary for installation in the directory, which can then happen automatically as the EID is assigned. I think if we plan this way, 8 bytes would be plenty for all the hierarchy we ever need - 6 bytes almost might be, but probably imposes just a bit too tight of a constraint on wastage. kre From owner-Big-Internet@munnari.oz.au Tue Sep 22 19:18:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11356; Tue, 22 Sep 1992 19:18:26 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209220918.11356@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11353; Tue, 22 Sep 1992 19:18:18 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 22 Sep 1992 10:16:46 +0100 To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: why to encode location info into IDs In-Reply-To: Your message of "Mon, 21 Sep 92 15:48:47 EDT." <9209211948.AA20209@us1rmc.bb.dec.com> Date: Tue, 22 Sep 92 10:16:41 +0100 From: Zheng Wang >I would assume that you would need some sort of global identifier >for MIT (as the high order part of MIT-NOEL). Given that the number >of similar things that you might want to identify worldwide is >probably in the hundreds of millions (assuming that companies would >be on the same level as universities, and not forgetting networks >in people's homes), then you will need a hierarchical structure for >identifying things like MIT, XYZ Corporation, and a neighborhood in >Southern New Jersey. If we encode the location info into the IDs, we can find the server more easily. Otherwise we have to search the server from the root. For example, the high order part of an ID can be the address of the server so you can quickly find out where the server is. This may make the ID a bit longer than that without structure. But we may make it shorter by assigning a special host number for a particular server. Take mobile ip for example, we may assign host number 254 for the mobile server and encode the net number in the high order of the mobile host IDs. For example, a mobile host from net 128.16 will has an ID like 128.16.zwang. If a router receives a packet for mobile host ID=128.16.zwang but does not have any cached forwarding info, it can send it to the server ipaddr=128.16.0.254. If the ID does not have info about its server, you have to find the server from the root. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Sep 22 22:17:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16858; Tue, 22 Sep 1992 22:17:49 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209221217.16858@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16855; Tue, 22 Sep 1992 22:17:13 +1000 (from kre) Date: Tue, 22 Sep 1992 22:17:13 +1000 From: Robert Elz To: Z.Wang@cs.ucl.ac.uk, callon@bigfut.enet.dec.com Subject: Re: why to encode location info into IDs Cc: big-internet@munnari.oz.au Date: Tue, 22 Sep 92 10:16:41 +0100 From: Zheng Wang If we encode the location info into the IDs, we can find the server more easily. For example, the high order part of an ID can be the address of the server No - we really must resist all attempts to make the ID contain any semantic information whatever. It must be totally flat once assigned, just a bunch of meaningless bits. It can have some syntatic structure - by which I mean no more than a method to write it as text in a form where it can be used as a key into the DNS. Similar encodings (as necessary) can be defined for any other directory that happens to come into vogue. Whether this is something simple (like divide at octet boundaries and write as decimal (or hex) humbers separated by periods), or something more complicated like Paul's PIP ID draft doesn't really matter. But processes should assume nothng at all about the meanings of the bits. As soon as we violate that, then what we have will no longer be a pure identifier, and a pure identifier is what we need. As soon as semantics stick their ugly heads in there become reasons why you'd want to change the ID because of what it means, which is absolutely not what's required. Finding servers for mobile hosts could be done by giving them an address which has internal semantics, and which internally identifies a magic server host to query for the current location if that should appeal to those working in this area, but that's the address, not the ID. Note: there is no conflict between totally flat (opaque) identifiers, and allocating them in a structured (hierarchical) way, so that from the identifier those who care can tell who allocated it, these are quite different concepts. kre From owner-Big-Internet@munnari.oz.au Tue Sep 22 23:16:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18803; Tue, 22 Sep 1992 23:16:12 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18788; Tue, 22 Sep 1992 23:16:01 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA21943; Tue, 22 Sep 92 06:15:43 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA05613; Tue, 22 Sep 1992 09:15:40 -0400 Subject: Proposal for a new "Murphy's Law of Network Addressing" To: big-internet@munnari.oz.au Cc: x3s33@merit.edu X-Mailer: Poste 2.0B3 From: David R. Oran Date: Tue, 22 Sep 92 09:15:34 -0400 Message-Id: <920922091534.226@sneezy.lkg.dec.com> Encoding: 18 TEXT, 6 TEXT SIGNATURE Recent discussions on the big-internet and tuba mailing lists about address hierarchies, endpoint ids, etc., have led me to formulate the following new law of network layer addressing: Murphy's law of addressing schemes: For any addressing scheme there exists a large class of topologies for which that addressing scheme produces pathologically bad routing. Correlary 1: Furthermore, without constant vigilance, the most carefully constructed topology will inevitably degenerate into this class. Correlary 2: Furthermore, even with constant vigilance, the most carefully constructed topology will inevitably degenerate into this class. Have a chuckle...Dave. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Wed Sep 23 00:23:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22440; Wed, 23 Sep 1992 00:23:15 +1000 (from owner-Big-Internet) Return-Path: Received: from SERVER.AF.MIL by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22434; Wed, 23 Sep 1992 00:23:04 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA04174; Tue, 22 Sep 92 09:06:04 CDT From: Matt Jonson Message-Id: <9209221406.AA04174@server.af.mil> Subject: Re: Identifiers, motion, and the DNS To: kre@munnari.oz.au (Robert Elz) Date: Tue, 22 Sep 92 9:06:01 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <5422.717139419@munnari.oz.au>; from "Robert Elz" at Sep 22, 92 3:23 pm X-Mailer: ELM [version 2.3 PL11] > > > Pretty soon your EID is no longer a short-cut, but to allow > for necessary assignment hierarchy (to permit truly local > assignments), it is the size of the NSAP > > I think this is based on an overly rigid view of what's > necessary in the hierarchy. Okay, I admit that statement was hyperbolic :-). I just was interested in provoking some comments on what a reasonable size for EID was given the constraint of "local" administration. > The aim is to minimise human maintenance work in the directory, > (both by the directory maintainer, and the person who wants > to get them registered, in the cases that they're not the same). I agree with that, and in fact it would seem that there should be a natural binding between NameService type directory and EIDService directory... > That doesn't imply that when I want an EID I hate to go ask > my local work group leader, who takes one from his hoard of [...] > which all came from the country range, which in turn comes > from the OSI sub-part of the total number range. I agree with your comments about the hierarchy. Actually I was thinking that "Network Service Providers" should be the ones that are at the first tier in the hierarchy. Any company or part of a company that could prove itself to be a service provider would be responsible for EIDs of things on or connected behind the networks they provide. Big corporations (the Government, for instance) probably have bunches of privat network providing agencies. If there is then a limit on the amount of sub-delegation from a block, "local" administration could probably viably fit into a short-cut ID. > I think if we plan this way, 8 bytes would be plenty for all > the hierarchy we ever need - 6 bytes almost might be, but > probably imposes just a bit too tight of a constraint on wastage. Just curious as to how you would allocate the pieces within the 6/8 byte EID scheme. Would you comment? thanks, /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 From owner-Big-Internet@munnari.oz.au Wed Sep 23 00:39:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23133; Wed, 23 Sep 1992 00:39:27 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23119; Wed, 23 Sep 1992 00:39:19 +1000 (from kasten@ftp.com) Received: by ftp.com id AA07215; Tue, 22 Sep 92 10:39:10 -0400 Date: Tue, 22 Sep 92 10:39:10 -0400 Message-Id: <9209221439.AA07215@ftp.com> To: oran@sneezy.lkg.dec.com Subject: Re: Proposal for a new "Murphy's Law of Network Addressing" From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au sorry dave, you've merely rediscovered entropy :-) > Recent discussions on the big-internet and tuba mailing lists about > address hierarchies, endpoint ids, etc., have led me > to formulate the following new law of network layer addressing: > > Murphy's law of addressing schemes: > > For any addressing scheme there exists a large class of topologies > for which that addressing scheme produces pathologically bad routing. > > Correlary 1: > Furthermore, without constant vigilance, the most carefully constructed > topology will inevitably degenerate into this class. > > Correlary 2: > Furthermore, even with constant vigilance, the most carefully constructed > topology will inevitably degenerate into this class. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Wed Sep 23 00:39:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB23123; Wed, 23 Sep 1992 00:39:23 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23111; Wed, 23 Sep 1992 00:39:12 +1000 (from kasten@ftp.com) Received: by ftp.com id AA07211; Tue, 22 Sep 92 10:39:07 -0400 Date: Tue, 22 Sep 92 10:39:07 -0400 Message-Id: <9209221439.AA07211@ftp.com> To: kre@munnari.oz.au, big-internet@munnari.oz.au Subject: Re: Identifiers, motion, and the DNS From: kasten@ftp.com (Frank Kastenholz) hi i've only just caught up with what has been discussed over the past few days... robert elz suggested that eids not be used to identify processes. i think that, while we don't see a need for this now, it is something that can easily be used in the future. i'd suggest that, even though we are not sure about the utility of this function today, we build into the eid architecture the ability to do this. this would imply, e.g., that there is some form of dynamic eid allocation and eid-to-address binding mechanism.......... one possible (half baked) application could be in making network services available. instead of using the eid as a "physical box identifier" it becomes a "really-useful-network-service" identifier. for example, eid 1 could be the end point id of the "root" name server. robert also touched on the reverse-lookup problem (given an eid, how do i get a host name or address). this is a complex problem because of the non-relation between eids (essentially a flat number space) and the administrative or topological hierarchy(ies) in which names and addresses live. if we assume that eids are allocated in ranges to administrative entities then the problem becomes tractable. it would require an extension to dns. right now, dns names things based on a hierarchichal name. an additional naming scheme and server scheme would be needed. i imagine that the naming scheme would be hierarchical based on the numerical ranges of the number. for example, 0-1,000,000 could be allocated to the ".com" server and 100,000-200,000 to the "ftp.com" so, if i had eid 123,456 i would ask the world root server to look it up, which would see that it is in the range 0-1,000,000 so it would ask the ".com" server, which would see that it is in the 100,000-200,000 range and it would ask the "ftp.com" server. voila. this requires block allocation of eids -- but we were considering some block allocation scheme anyway. it does tie the eid to some administrative domain which is a bit of a loss (grumble, grumble) though it is not tied to the network topology -- which is the big win of eids. finally, robert also does not want to use ieee 802 numbers because he does not want to trust that no vendor ever has or will allocate the same number twice. don't worry robert. it has happened. it no doubt will happen again. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Wed Sep 23 01:22:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25641; Wed, 23 Sep 1992 01:22:31 +1000 (from owner-Big-Internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25613; Wed, 23 Sep 1992 01:22:14 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA01861; Tue, 22 Sep 92 08:21:57 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA06018; Tue, 22 Sep 1992 11:21:52 -0400 To: kasten@ftp.com (Frank Kastenholz) Subject: Re: Proposal for a new "Murphy's Law of Network Addressing" In-Reply-To: <9209221439.AA07215@ftp.com> References: <9209221439.AA07215@ftp.com> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: David R. Oran Date: Tue, 22 Sep 92 11:21:51 -0400 Message-Id: <920922112151.226@sneezy.lkg.dec.com> > sorry dave, you've merely rediscovered entropy :-) > I know you meant this to be funny, but actually I don't think the law has to do with entropy. The law is much more pernicious, as is Murphy in general. While entropy would asymptotically approach full randomness in the distribution of addresses, my law would actually produce much worse behavior, in that there would be active anti-entropy to produce the most pessimal mapping of the addressing onto the topology. For example, if you treated the addresees as flat and routed by hashing them, my law would guarantee that all the allocated addresses collided on the same hash value! I would give as evidence of this precise behaviour some of the interesting historical events regarding palidromic Ethernet addresses, or the attempts to map toekn-ring functional addresses onto ethernet multicasts. From owner-Big-Internet@munnari.oz.au Wed Sep 23 05:46:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05330; Wed, 23 Sep 1992 05:47:10 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05318; Wed, 23 Sep 1992 05:46:55 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA24787; Tue, 22 Sep 92 12:46:38 -0700 Received: by us1rmc.bb.dec.com; id AA22806; Tue, 22 Sep 92 15:44:00 -0400 Message-Id: <9209221944.AA22806@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 22 Sep 92 15:44:02 EDT Date: Tue, 22 Sep 92 15:44:02 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 22-Sep-1992 1546" To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: RE: re: Re: identifiers (1) There are more and more machines that are not where you would expect based on the domain name. asylum.sf.ca.us is a computer in Boston, Massachusetts. I believe there are a number of machines called ...mt-fuji...jp that are in Washington, DC. I've been thinking of trying to register a local machine in .aq myself (:-). (2) For diagnostic or investigatory reasons, you will want to be able to map from anything to anything, including ID -> name, address, etc., but it does not have to be particularly efficient. Donald -------------- From: US1RMC::"jnc@ginger.lcs.mit.edu" "Noel Chiappa" 18-SEP-1992 13:01 Subj: re: Re: identifiers However, DNS has a hierarchical structure which implies that the information about my system is located in a data structure which is stored somewhere near my system. Tilt! DNS make *No Such Assumption*. We needed *some* structure to avoid having one giant flat translation table, which would be difficult to manage (no duplicate names), engineer (one giant databese), etc. Almost any hierarchical structure would do; we picked an organizational heirachy for administrative *and* human convenience. It's much easier for me to remember bigfut.enet.dec.com as your machine than it's network topological association, 'cause I know you work for DEC and DEC is a company. This implies that someone in my building, in order to look up my address based on my name, does not need to go outside of this building. Similarly, someone who is located in the next network over, only needs to go a small distance to look up my address. There's no guarantee *whatsoever* that the server(s) which hold the *mappings* for DNS name A.B.C.D is *anywhere* near the host *named* A.B.C.D. It usually is, but the system would work fine even if it wasn't. It's good engineering to put them close together, to minimize traffic, and for fate sharing (who cares if you can't get to the name server for A.B.C.D if you can't get to A.B.C.D itself either), but it's not necessary. The structure in DNS is purely administrative, not topological. From owner-Big-Internet@munnari.oz.au Wed Sep 23 08:03:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09642; Wed, 23 Sep 1992 08:03:46 +1000 (from owner-Big-Internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09639; Wed, 23 Sep 1992 08:03:41 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA18782; Tue, 22 Sep 92 18:04:19 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9209222204.AA18782@wizard.gsfc.nasa.gov> Subject: Re: Another Scheme for Assigning End-point IDentifiers To: VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) Date: Tue, 22 Sep 92 18:04:19 EDT Cc: big-internet@munnari.oz.au In-Reply-To: <920922.132938.EDT.VALDIS@vtvm1.cc.vt.edu>; from "Valdis Kletnieks" at Sep 22, 92 1:29 pm X-Mailer: ELM [version 2.3 PL11] > Date: Tue, 22 Sep 92 13:29:38 EDT > From: Valdis Kletnieks > > On Mon, 21 Sep 92 19:01:47 EDT you said: > >Under this scheme, my machine wizard.gsfc.nasa.gov might have an EID > >something like: > > > > gov.nasa.gsfc.wizard > > > > 38 .62 .10 .3764 > > > >The numbers in my example are somewhat arbitrary but are just meant > >to represent a binary value for that branch at that point in the DNS > >tree, i.e. gov=38 would just mean that gov was the 38th name registered > >in the root directory. You could use the self-defining variable-length > > OK. Where do you keep the history information about the DNS, so that you > know that .gov was the 38th entry? And what happens with domains that > add/move/rename a lot of entries - do you re-use a number, or not? Since the binary values are only constrained to be unique numbers, I don't see any need to keep a history. You could just keep the binary value associated with each DNS name in the DNS entry. A new name could just be assigned the next available number in sequence. Renames would keep the same binary value. Deletions would mean removal from the directory service. Whether or not deleted values get re-used is open to debate. One option would be to not re-use deleted values until you had exhausted the sequence space and wrapped around to the beginning. Also, on further reflection, to limit the size of the EID, it might be useful to combine some of the levels, i.e. the EID for my machine might be: gov .nasa.gsfc .wizard 38 .3060 .3764 With such a scheme, the top level could be two octets, the second level could be three octets, and the third level could be three octets, for a total of 8 octets. I haven't thought through all the details of implementing such a concept in the DNS. I just think it might make more sense to augment the existing DNS which is already well equipped to handle this function than to invent a new EID server mechanism that does essentially the same thing. For ease of network administration, it might be nice to have an optional RARP mechanism at the local level that maps from hardware addresses to EIDs. This could be part of the automatic host configuration process. Once you had registered your system with the appropriate directory services authority (name and hardware address(es)), the system could automatically discover its name/EID without any manual configuration at the host. This probably only makes sense for the most common case when the host is "close" to its DNS/RARP server, but could greatly assist the life of network managers at large sites. > Remember that when using a hash table or similar scheme, there is a good > chance that the "order" of the data is *undefined* - as it is, I've > often done a DNS zone transfer of the same domain twice within 5 minutes, > and gotten data that was radically different in order.... The scheme I've suggested is not order dependent. It simply creates a one-to-one unique mapping between DNS name and EID. -Bill Fink IP Protocol Manager NASA Goddard Space Flight Center From owner-big-internet@munnari.oz.au Wed Sep 23 12:13:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19700; Wed, 23 Sep 1992 12:13:24 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18057; Wed, 23 Sep 1992 11:32:14 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12119>; Tue, 22 Sep 1992 18:31:54 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <10779>; Tue, 22 Sep 1992 18:31:48 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: SIP Date: Tue, 22 Sep 1992 18:31:44 PDT From: Steve Deering Message-Id: <92Sep22.183148pdt.10779@skylark.parc.xerox.com> I'd like to offer another candidate for IPv7. It's called SIP (Simple Internet Protocol), or CLNPv2 :-). One philosophy behind SIP is that the IP model of globally-unique addresses, hierarchically-structured for efficient routing, is fundamentally sound. IP addressing and routing works fine, but the addresses aren't quite long enough and not quite hierarchical enough to scale the Internet up to, say, thousands of internet-addressable devices in every office, every residence, and every vehicle in the world. SIP addresses are 64 bits long, and are sufficient for an internet that big. Another philosophy behind SIP is the RISC philosophy: the SIP header is much simpler than the IP header (not to mention the CLNP header or the Pip header), to facilitate high-performance implementation and to increase the likelihood of correct implementation. Here are some excerpts from the draft SIP specification (currently under construction), that describe the basic features of SIP. Information on how to fetch the current draft are given at the end of this message. ------------------------------------------------------------------------ SIP Header Format ----------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop Limit | Payload Type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hop Limit 8-bit unsigned integer. Decremented by 1 by each system that forwards the packet. Packet is discarded if Hop Limit is decremented to zero. Payload Type 8-bit selector. Identifies the type of payload, e.g., TCP. Payload Length 16-bit unsigned integer. Length of payload, i.e., the data following the SIP header, in octets. Source Address & 64 bits each. See "SIP Addressing" section. Destination Address Notes: - The SIP header is the same size (20 octets) as the IPv4 header without options. - There are no SIP options. Additional information that must be conveyed to routers in special cases, such as security label information, may be inserted between the SIP header and the next-higher-layer header (e.g., TCP), using a distinguished Payload Type value to indicate the presence of the additional information. (As part of the additional information, there must be included another Payload Type field, to identify the next-higher-layer protocol. See the "Source Routing Protocol" section, below, for an example.) - Still undecided: whether or not an additional 32-bit field should be added to the SIP header to achieve 64-bit alignment (as it is, the two address fields can be 64-bit aligned by making sure the packet starts at an odd-word address, where word = 32 bits). The extra 32 bits, if added, would be used for classifying packets deserving of special handling, e.g., non-default quality of service or real-time service. On the other hand, the transport-layer port fields may be adequate for performing any such classification. (One possibility would be simply to remove the port fields from TCP & UDP and put them in the SIP header, like XNS.) Packet Size Issues ------------------ SIP requires that every link in the internet have an MTU of 500 octets or more. On any link that cannot convey a 500-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below SIP. From each link to which a system is directly attached, the system must be able to accept packets as large as that link's MTU. SIP systems are expected to implement Path MTU Discovery [RFC-1191], in order to discover and take advantage of paths with MTU greater than 500 octets. However, a minimal SIP implementation (e.g., in a boot ROM) may simply restrict itself to sending packets no larger than 500 octets, and omit implementation of Path MTU Discovery. Path MTU Discovery requires support both in the SIP layer and in the packetization layers. A system that supports Path MTU Discovery at the SIP layer may serve packetization layers that are unable to adapt to changes of the path MTU. Such packetization layers must limit themselves to sending packets no longer than 500 octets, even when sending to destinations that are on the same subnet. (Note: Those parts of the RFC-1191 procedures that involve use of a table of MTU "plateaus" do not apply to SIP, because the SIP version of the "Datagram Too Big" message always identifies the exact MTU to be used.) SIP Addressing -------------- SIP addresses are 64 bits (8 octets) long. The notation for writing SIP addresses is 16 hexadecimal digits, with a dot after the 4th digit and optional dots after any subsequent digit. Examples: 1234.56789ABCDEF0 1234.56789ABC.DEF0 1234.567.89AB.CDE.F0 There are two classes of address: unicast and multicast. Multicast addresses are identified as such by hex FF in the high-order octet; unicast addresses have values other than hex FF in the high-order octet. Unicast Addresses Unicast addresses are globally unique within a SIP internet, i.e., no two interfaces have the same address. A single interface may have multiple unicast addresses. With each of a system's unicast addresses, the system associates a "subnet mask" that indicates which part of the address is the subnet prefix (those bits with a 1 in the corresponding position in the mask) and which part is the interface identifier within the subnet (those bits with 0 in the corresponding position in the mask). Hosts are ignorant of any further structure in the address. Routers may be aware of shorter prefixes of an address that identify higher-level clusters in the hierarchical addressing plan; that knowledge is in the form of additional masks (with fewer 1 bits), rather than any "wired-in" knowledge of what bit boundaries are significant in the addressing hierarchy. Within any hierarchical component of a unicast address, the value zero is reserved to mean "unspecified". This specification does not further constrain the structure of unicast addresses. Appendix A suggests one possible structure. SIP Source Routing Protocol --------------------------- A Payload Type of 3 in a SIP header indicates the presence of this Source Routing header, immediately following the SIP header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Payload Type | Num Addrs | Next Addr | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[1] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[2] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Address[Num Addrs] + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that this header is not examined until the packet reaches the system identified in the SIP Destination Address field (unlike the IP source route options). The 32-bit Reserved field is present to make the source route addresses have the same 64-bit alignment as the addresses in the SIP header. loose source routing only -- can't enforce strict source routing if subnets are allowed to transparently span multiple links. description to be done Design Rationale ---------------- ... Fields present in IPv4, but absent in SIP: Version Not needed; SIP identified by new link-layer type code. Header Length Not needed; SIP header length is fixed (no options). Precedence & Type of Service Not used; transport-layer Port fields (or perhaps an additional to-be-defined 32-bit field in the SIP header) may be used for classifying packets at a granularity finer than host-to-host, as required for special handling. Identification, Flags, and Fragment Offset Not needed; SIP does not do fragmentation. Time to Live SIP uses Hop Limit instead, to provide protection from routing loops. Transport protocols are expected to provide their own protection against long-lived packets. Header Checksum Not used; transport pseudo-header checksum protects destinations from accepting corrupted packets. ... Transport and Upper-Layer Issues -------------------------------- - bigger addresses - must include the basic SIP header, excluding Hop Limit, in transport-layer checksums - if a source routing header is present, the originating transport layer must use last address in source route, rather than SIP destination address, in its checksum - UDP checksum is no longer optional - transport must do own enforcement of max packet lifetime (or rather, recognize and tolerate very old packets) - must do path-MTU discovery, and be capable of adapting outgoing packet size in response to changes of PMTU (or always send packets <= 500 octets) - change of ICMP error report format - no TOS, Ident, or options to be passed across IP service interface - need new SIP+TCP header compression algorithm - DNS changes: new address type - need a SIP MIB Appendix A - Suggested Unicast Address Structure ------------------------------------------------ The following two hierarchical formats are suggested for SIP unicast addresses: (1) metro-based addresses +-------+-------+-------+-------+-------+-------+-------+-------+ | country + | site ID | intra-site | | metro ID | | part | +-------+-------+-------+-------+-------+-------+-------+-------+ 2 octets 4 octets 2 octets country + Identifies a metropolitan area. Internally metro ID structured into a country part and a metro part, with a varying boundary between those two parts. (Each country gets a power-of-two sized and aligned block of metro IDs, sufficient for the projected number of metro areas in that country.) site ID Flat identifier of a site within or near a metro area, where a "site" may be, for example, a corporate or government site, a campus, or household. A site ID "belongs" to the administrators of a particular site, rather than to a particular SIP service provider, so that it does not change if the site changes its provider, as long as the change is within the same metro area. intra-site part Identifies an interface within a site. Internally structured into a subnet ID and an interface ID, with a varying boundary between those two parts. (Each subnet gets a power-of-two sized and aligned block of interface IDs, sufficient for the projected number of interfaces in that subnet.) Large sites may obtain multiple site IDs, if needed. The subnet mask for a metro-based address has 1 bits covering all positions from the high-order bit of the country ID to the low-order bit of the subnet ID within the intra-site part. The details and consequences of metro-based addressing and routing are described in a separate document. (2) provider-based addresses +-------+-------+-------+-------+-------+-------+-------+-------+ | country + | subscriber ID intra-subscriber | | provider ID | part | +-------+-------+-------+-------+-------+-------+-------+-------+ 2 octets 6 octets country + Identifies a SIP service provider. Internally provider ID structured into a country part and a provider part, with a varying boundary between the two parts. (Each country gets a power-of-two sized and aligned block of provider IDs, sufficient for the projected number of providers in that country.) Trans-national providers obtain a separate provider ID in each country that they serve. subscriber ID Identifies a subscriber of a particular provider. Internally hierarchically structured for efficient routing within the provider's facilities. intra-subscriber Identifies an interface within a subscriber's part facilities. Internally hierarchically structured for efficient routing within the subscriber's facilities. The last two components of the intra-subscriber part are a subnet ID and an interface ID, with a varying boundary between those two parts. (Each subnet gets a power-of-two sized and aligned block of interface IDs, sufficient for the projected number of interfaces in that subnet.) The boundary between the subscriber ID and the intra-subscriber part is a private matter between the provider and the subscriber. The subnet mask for a provider-based address has 1 bits covering all positions from the high-order bit of the country part to the low-order bit of the subnet ID within the intra-subscriber part. Both country + metro IDs and country + provider IDs are assigned from the same 16-bit space, so that both metro-based and provider-based addressing may be supported in the same internet. ------------------------------------------------------------------------ (end of excerpts) The current draft-in-progress may be fetched by anonymous FTP from host parcftp.xerox.com, file pub/net-research/sip-spec. It includes information on: - the format of SIP multicast addresses. - changes required to ICMP and IGMP for SIP. - a scheme for tunneling (encapsulation) in SIP, which is intended to support delivery to mobile hosts and to re-homed domains, among other purposes. Since encapsulation increases the size of a SIP packet, possibly exceeding the path MTU, the tunneling protocol includes a simple fragmentation and reassembly capability. (Be warned that the document does not yet have page numbers, pretty formatting, or much in the way of explanation/justification of the design choices.) Regarding transition from IPv4 to SIP, the technical issues are basically the same as transitioning to CLNP, as described in the TUBA document (RFC-1347). Thus, if the costs of the TUBA approach (adding a new internet layer in parallel with IP on all hosts and routers) does not rule out CLNP as a candidate for IPv7, nor should it rule out SIP. I believe that SIP occupies a significantly different point in the solution space than IPAE, CLNP, PIP, or NAT. (It is somewhat similar to the proposal by R. Ullmann, published as draft-ullmann-ipv7-00.txt in the internet-drafts repositories. For some reason, that proposal has not seen much, if any, discussion on this list.) I would very much appreciate your comments on SIP. Steve Deering From owner-Big-Internet@munnari.oz.au Wed Sep 23 15:10:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26924; Wed, 23 Sep 1992 15:10:39 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26920; Wed, 23 Sep 1992 15:10:29 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA23918; Tue, 22 Sep 92 22:10:06 -0700 Message-Id: <9209230510.AA23918@Mordor.Stanford.EDU> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: SIP Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 22 Sep 92 18:31:44 -0700. <92Sep22.183148pdt.10779@skylark.parc.xerox.com> Date: Tue, 22 Sep 92 22:10:06 -0700 From: Dave Crocker X-Mts: smtp Steve, Glad to see you surface the SIP proposal to the general Internet. Makes it easier for me to make casual reference to it, when listing the current set of options... Two comments: 1. If a field is really identical to one that currently exists in IP, how about using the same name? E.g., if Payload Type really is identical to Protocol-ID, then how about making the name Protocol-ID? Might seem large a trivial issue, but it would make SIP that much friendlier to the installed base of IP-savy folk. 2. I like the idea of puting Port number into the SIP header. David Boggs (co-inventor of Ethernet) convinced me that that was a big win with XNS that IP suffers from not having. (Routers end up looking into Transport level, inorder to do fine-grained policy routing.) Dave From owner-Big-Internet@munnari.oz.au Wed Sep 23 23:29:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13158; Wed, 23 Sep 1992 23:29:33 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13154; Wed, 23 Sep 1992 23:29:21 +1000 (from kasten@ftp.com) Received: by ftp.com id AA22814; Wed, 23 Sep 92 09:28:41 -0400 Date: Wed, 23 Sep 92 09:28:41 -0400 Message-Id: <9209231328.AA22814@ftp.com> To: dcrocker@Mordor.Stanford.EDU Subject: Re: SIP From: kasten@ftp.com (Frank Kastenholz) Cc: deering@parc.xerox.com, big-internet@munnari.oz.au > 2. I like the idea of puting Port number into the SIP header. David > Boggs (co-inventor of Ethernet) convinced me that that was a big win > with XNS that IP suffers from not having. (Routers end up looking > into Transport level, inorder to do fine-grained policy routing.) This sort of "fine-grained policy routing" seems to be TOS-based routing. The router would go through some decision process like "if the packet is a Telnet packet then I want to give this packet quick service so as to minimize latency." In other words, we are saying that this packet gets TOS=low-latency based on the fact that one of its port numbers is Telnet. Now, the router would have to go through this process for every port-number-value of interest. There are probably dozens of these, and the number, no doubt, is growing. This means that the router needs a big table of port-number/policy pairs (or a big switch statement or whatever). This is highly inefficient. Furthermore, by explicitly binding routing policy decisions to specific protocols based on port-numbers it is difficult to extend the policy mechanism to other protocols. For example, if I create the Frank protocol and it gets assigned port number 999 and want to have certain routing policies associated with this protocol, I would have to wait for all routers of the network to get new software that is aware of the Frank protocol, port 999, and the policy associated with it. Even worse, if I find that I screwed this initial policy up and need to change it, all the routers have to get updated again... If we want policy routing, we need a policy field. We may or may not know what "policy routing" means or how to effect it. Saying that the port number is the policy does not really solve the problem. It masks the problem. -- frank kastenholz ch more efficient for the CPU to decrement it, as is needed. I like that the basic header is enough to move packets around in my local area and if more information is needed then it is added by placing additional, in effect optional, hunks of data after the basic header. I think that TOS/policy should be one such additional header (see the note that I posted in response to Dave Crocker's comments on SIP). > Time to Live SIP uses Hop Limit instead, to provide protection > from routing loops. Transport protocols are expected > to provide their own protection against long-lived > packets. Note that TCP relies on the maximum packet lifetime that the TTL field provides (in theory) via its time-based decrementing. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Thu Sep 24 00:16:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15858; Thu, 24 Sep 1992 00:16:08 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15850; Thu, 24 Sep 1992 00:16:02 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA26237; Wed, 23 Sep 92 07:15:49 -0700 Message-Id: <9209231415.AA26237@Mordor.Stanford.EDU> To: kasten@ftp.com (Frank Kastenholz) Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: SIP Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 23 Sep 92 09:28:41 -0400. <9209231328.AA22814@ftp.com> Date: Wed, 23 Sep 92 07:15:48 -0700 From: Dave Crocker X-Mts: smtp Frank, My use of the term "policy routing" walked us down a different path than I intended. In fact, I meant to refer to issues such as congestion control which pertain to managing behavior of the overall transmission system, rather than of providing optimal service for individual users. (That might also be relevant, but wasn't the focus of what I intended.) E.g., when a router starts to congest, it has to start throwing away packets. Whose does it toss? Most current thinking is along the lines of "round robin" which equally distributes the pain. Yet that merely guarantees that everyone suffers. It seems to me that ensuring that all of your customers are equally unhappy is not always the right business decision and that having a fraction of your users be happy is better. Trivial example: 50 users shove 100 packet/second through the system, with routers than can do 1K pkts/second (ignoring queuing issues) so they all get adequate service. Then, 950 more users come along, each wanting 100pkts/second. Round robin guarantees that all 1000 users will get 10pkts/second. All your users will hate you. One "policy-oriented" congestion control technique would observe traffic history and try to maintain throughput for the original set of users and give "whatever is left over" to the rest. In this case, the first 50 users will stay happy and the remaining 950 share the remaining 500pkts/sec of router capacity. The latter group probably _won't_ be happy, but they wouldn't have been in any event. The question is: what is a "user"? With IP-level addressing being all that is formally available, the granularity is at the machine level. With port number available, the granularity is a process, which is a much more meaningful discriminator of "users". Certainly, one cannot argue with your concern about overhead. Paying attention to fine-grained behavior costs. Dave From owner-Big-Internet@munnari.oz.au Thu Sep 24 01:43:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18786; Thu, 24 Sep 1992 01:43:53 +1000 (from owner-Big-Internet) Return-Path: Received: from ctt.ctt.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18773; Thu, 24 Sep 1992 01:43:40 +1000 (from little@ctt.bellcore.com) Received: from wizzard.ctt.bellcore.com (wizard.ctt.bellcore.com) by ctt (4.1/1.34) id AA29201; Wed, 23 Sep 92 11:31:33 EDT Received: from localhost.ctt.bellcore.com by wizzard.ctt.bellcore.com (4.1/SMI-4.0) id AA05116; Wed, 23 Sep 92 11:31:32 EDT Message-Id: <9209231531.AA05116@wizzard.ctt.bellcore.com> To: Steve Deering Cc: big-internet@munnari.oz.au, little@ctt.bellcore.com Subject: Re: SIP In-Reply-To: Your message of "Tue, 22 Sep 92 18:31:44 PDT." <92Sep22.183148pdt.10779@skylark.parc.xerox.com> Date: Wed, 23 Sep 92 11:31:31 -0400 From: little@ctt.bellcore.com Steve, Some quick thoughts to pass on - What is the potential impact/harm of corrupted SIP headers on network behavior (as opposed to data stream integrity)? Both internetwork size and local routing policies have an impact on the packet lifetime required to transit a path from source to destination. Will SIP be providing any new direction in balancing packet lifetime thresholds with path transit needs? Although initially simple, I see complexity with the option headers (SIP subheaders?) in terms of sequencing. Is it possible to have the final SIP header processing result be independent of the processing order (sequence) of the SIP subheaders? I would say SIP header length is deterministic, as opposed to fixed, only because I would include all the optional subheaders as part of the header (yes, this is a nit). Hope you receive the visibility necessary to stir the pot. As you recognize, there is a need in determining the proper balance between 'required' data and optional data. I see the SIP basic header as a good proposal for 'required' data. You may wish to consider adding a subheadder structure which contains a 'typical' collection of option data - TOS, Security/Authentication, and so on - providing something of a standard profile per packet 'class' (the source routed packet can also be consider as one such 'class'). -Mike From owner-Big-Internet@munnari.oz.au Thu Sep 24 02:13:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19816; Thu, 24 Sep 1992 02:14:39 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19792; Thu, 24 Sep 1992 02:13:55 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28457; Wed, 23 Sep 92 12:10:15 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA01908; Wed, 23 Sep 92 09:09:03 PDT Message-Id: <9209231609.AA01908@aland.bbn.com> To: Frank Kastenholz Cc: dcrocker@mordor.stanford.edu, deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of Wed, 23 Sep 92 09:28:41 -0400. <9209231328.AA22814@ftp.com> From: Craig Partridge Date: Wed, 23 Sep 92 09:09:03 -0700 Sender: craig@aland.bbn.com Frank: I strongly agree with your comments about not allowing a port to imply a certain type of service. However, I want to add a small addendum and also suggest that maybe we can use a negotiation scheme that takes advantage of the ports. point out that all routers would need to know that port 999 wants low latency. But if we're also allowing applications to make approximate bandwidth requests, then the protocol for port 999 also must have some rules about the bandwidth it uses. So assume that port 999 is, say, a video multiplexing service, capable of handling multiple different video encodings (which have different bandwidth requirements). How is the router gonna figure out which level of bandwidth one wants for this particular stream to port 999? (Read the datagrams to figure out which video format is being used? NOT!) For these reasons, I think what one wants is some method (and I guess with SIP, it would be done with a special protocol) to tell the router what this stream to port 999 is gonna do. Now the interesting thought I had is that after I tell the router that my stream is behaving in a certain way, I need to have a unique ID to identify my stream to the router. Well, one obvious unique ID is the src port, dst port, protocol id, and src and dst addresses. The advantage to this scheme is that in cases where one knows what type of service a port demands (e.g. a TCP telnet port), you could build that into routers without having to do negotiation. The fly in this ointment is that by building options in as protocols, a source routed SIP TCP segment will *not* have the TCP protocol id. And one does not want a source routed UDP datagram and a source routed TCP segment to get confused. My quick conclusion is that we could use the ports + addrs + protocol ID as a unique ID for recognizing streams with special TOS requirements, except that the SIP protocol ID isn't always the ID of the transport protocol whose port space is being used. Craig From owner-Big-Internet@munnari.oz.au Thu Sep 24 02:41:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20788; Thu, 24 Sep 1992 02:42:22 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20777; Thu, 24 Sep 1992 02:41:46 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA02862; Wed, 23 Sep 1992 18:38:45 +0200 Message-Id: <199209231638.AA02862@mitsou.inria.fr> To: kasten@ftp.com (Frank Kastenholz) Cc: dcrocker@Mordor.Stanford.EDU, deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of "Wed, 23 Sep 92 09:28:41 EDT." <9209231328.AA22814@ftp.com> Date: Wed, 23 Sep 92 18:38:41 -0400 From: Christian Huitema X-Mts: smtp > >If we want policy routing, we need a policy field. We may or may not >know what "policy routing" means or how to effect it. Saying that the >port number is the policy does not really solve the problem. It masks >the problem. > You are right. We need to be able, if needed, to differentiate classes of traffic, e.g. applying Lixia Zhang's model. An identification of the "traffic class" or "traffic stream" is probably needed for that. Problem is, we dont know well what a class, or a policy, is. And we may have to differentiate between two usages: 1) Usage of a policy field to select the routing table, e.g. "commercial" towards X goes through FOO, "research" goes through "BAR". 2) Usage of a class field to implement priorities and ressource reservations, e.g. "real time" goes over "interactive", or "videoconference 12345 on address A, B or C is authorized to use 25% of the transatlantic link #23 between 11am and 2pm". I am not enthusiastic about usage (1). I tend to believe that strict policies can only be implemented by using source directed routing. On the other hand, flagging packets according to the "category of traffic" maybe a useful control mechanism, e.g. "commercial traffic get the worst possible priority on NSFNET" may be a way to actually enforce a policy -- independantly of the choice of routes. I think that usage (2) need more studies. In the short term, it might be reasonable to reserve a 32 bits field for both usages. Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Sep 24 03:15:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21750; Thu, 24 Sep 1992 03:15:23 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21727; Thu, 24 Sep 1992 03:15:03 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA10353; Wed, 23 Sep 92 10:14:54 -0700 Received: by us1rmc.bb.dec.com; id AA13157; Wed, 23 Sep 92 13:12:16 -0400 Message-Id: <9209231712.AA13157@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Wed, 23 Sep 92 13:12:17 EDT Date: Wed, 23 Sep 92 13:12:17 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 23-Sep-1992 1314" To: jcurran@nic.near.net Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jcurran@nic.near.net Subject: RE: Re: Identifiers, motion, and the DNS I certianly don't think IEEE (+ IP4) addresses will be adequate for all needs but I don't see that much problem in using them. The worst problem with IEEE numbers, I think, is that many of them will be bound to hardware which can get swapped out, etc. and/or that people will think of them as bound to hardware. This will occasionally be appropriate but often not. IEEE does have some structure into "manufacturer" and "rest". Some entities assigned a block as a "manufacturer" might want to maintain registries to make their sub-assigned numbers more valuable. If not, others will presumably run registries for a fee. I don't see that it matters that much if it's hard to authenticate that someone was assigned a number. You should be able to check the validity of the "manufacturer" code and if "manufactuer"s maintain registries, it's their problem. Anyway, whoever registers it first has a presumptive right to an identification that some other claimant would have to dislodge. Furthermore, we all know that the future Internet will have ubiquitous security (right? (;-) ) so whoever gets registered first with their public key certificate and all will be the only thing most other entities on the net will be willing to talk to anyway. Packets from an imposter won't authenticate... Donald -------------- From: US1RMC::"jcurran@nic.near.net" "John Curran" 19-SEP-1992 15:43 To: Robert Elz CC: Big-Internet@munnari.oz.au Subj: Re: Identifiers, motion, and the DNS -------- ] From: Robert Elz ] Subject: Re: Identifiers, motion, and the DNS ] Date: Sun, 20 Sep 92 03:12:48 +1000 ] ] Date: Fri, 18 Sep 92 18:40:09 -0400 ] From: John Curran ]... ] What's hard is figuring out just who I should ask to register my workstation ] in that directory, its certainly not likely to be located anywhere near ] where I am. Thanks for pointing this out. Stamp out ambiguity whenever possible. Here is obviously what I should have said: IEEE numbers certainly do not provide an administrative hierarchy which supports convenient registration in a distributed directory. Not only do you have to find the right registration authority, but said authority will be hard pressed to perform any form of authentication on your request. /John From owner-Big-Internet@munnari.oz.au Thu Sep 24 03:19:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21850; Thu, 24 Sep 1992 03:19:52 +1000 (from owner-Big-Internet) Return-Path: Received: from delirius-exp.cs.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21845; Thu, 24 Sep 1992 03:19:43 +1000 (from zweig@cs.uiuc.edu) Received: from dubius.cs.uiuc.edu by delirius.cs.uiuc.edu with SMTP id AA25952 (5.64+/IDA-1.3.4 for big-internet@munnari.oz.au); Wed, 23 Sep 92 12:19:20 -0500 From: Johnny Zweig Message-Id: <9209231719.AA25952@delirius.cs.uiuc.edu> Subject: SIP's extra 32 bits To: big-internet@munnari.oz.au Date: Wed, 23 Sep 92 12:19:19 CDT X-Mailer: ELM [version 2.3 PL11] Since the payload length field is probably not of interest to routers along the way (their data link layer ought to tell them in most cases), I don't see why the field needs to be a convenient multiple of anything. So why not have 8 bits of TOS and 24 bits of payload length, instead of the 32 bits of payload length Frank Kastenholz suggested? It seems like 256 points in the latency/reliability/expense space is more than most routers would bother dealing with in policy decisions anyway, and adding another 64- or 128 bits of TOS header seems like a lot to pay, especially given that now routers would need to worry about TCP-over-SIP, TCP-over-TOS-over-SIP, etc. (using the payload type field to discriminate seems like it would double the number of defined payload types, since there would be Foo-over-SIP-with-TOS for each protocol Foo). It seems to me router hardware should be happier grabbing 64 bits at the beginning of a SIP packet and masking off the 8 bits of TOS than messing around with a considerably larger number of defined payload types and having to look further back another few hundred bits to get to the TOS information. -Johnny Oddbits From owner-Big-Internet@munnari.oz.au Thu Sep 24 03:38:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22314; Thu, 24 Sep 1992 03:38:34 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22304; Thu, 24 Sep 1992 03:38:23 +1000 (from kasten@ftp.com) Received: by ftp.com id AA05680; Wed, 23 Sep 92 13:37:52 -0400 Date: Wed, 23 Sep 92 13:37:52 -0400 Message-Id: <9209231737.AA05680@ftp.com> To: craig@aland.bbn.com Subject: Re: SIP From: kasten@ftp.com (Frank Kastenholz) Cc: dcrocker@mordor.stanford.edu, deering@parc.xerox.com, big-internet@munnari.oz.au Craig, I really do not like the concept of loading various header fields with multiple meanings. I believe that it makes things overly complex; it introduces all sorts of special cases; it introduces unforseen limitations. Here's what I mean. You give, as an example, > Now the interesting thought I had is that after I tell the router that > my stream is behaving in a certain way, I need to have a unique ID to > identify my stream to the router. Well, one obvious unique ID is the > src port, dst port, protocol id, and src and dst addresses. > > The advantage to this scheme is that in cases where one knows what type > of service a port demands (e.g. a TCP telnet port), you could build that into > routers without having to do negotiation. Suppose that I am Telnetting to do some task that is critical to the safe, continued, operation of the network. I would want to have some policies associated with this traffic that are indicative of the critical nature of the task. I would either A) need some form of additional policy negotiation to tell the routers that this is not a "normal" Telnet stream and to inform them if its new policies, or B) have to settle for the standard policies associated with Telnet. The later option is unacceptable in my scenario. The former is the desired one. But, this leads to the routers looking at each packet, determining that it is Telnet AND STILL checking the "negotiated policy" table to see if there are any negotiated policies associated with the packet that override the standard ones. A further problem in using port numbers as a part of the stream identification is that it would prevent me from aggregating several different connections under a single policy. I could assign the same identical policy to these connections but that would end up increasing the amount of information that the routers would need to keep. Here is an example of why I might want multiple connections to operate under the same policy. I might be doing an FTP and want the traffic to traverse commercial backbones. The policy that I would need would be "this is commerical traffic -- use commercial backbones". Now, FTP uses two TCP connections. And one of those connections, the DATA connection, is brought up and torn down for each data transfer. If each connection had its own policy, even if the policies are all identical, I would have to re-negotiate the policy for the DATA connection several times. If I can negotiate the policy once and then identify which connections operate under that policy I get a big win. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Thu Sep 24 03:42:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22386; Thu, 24 Sep 1992 03:42:29 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22379; Thu, 24 Sep 1992 03:42:14 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12017>; Wed, 23 Sep 1992 10:41:49 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <10779>; Wed, 23 Sep 1992 10:41:39 -0700 To: Dave Crocker Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP In-Reply-To: Your message of Tue, 22 Sep 92 22:10:06 -0700. <9209230510.AA23918@Mordor.Stanford.EDU> Date: Wed, 23 Sep 1992 10:41:27 PDT From: Steve Deering Message-Id: <92Sep23.104139pdt.10779@skylark.parc.xerox.com> > 1. If a field is really identical to one that currently exists in > IP, how about using the same name? E.g., if Payload Type really > is identical to Protocol-ID, then how about making the name > Protocol-ID? Might seem large a trivial issue, but it would make > SIP that much friendlier to the installed base of IP-savy folk. Dave, I agree with the general principle, but in this case I intentionally chose a different name than that used by IP. You see, the name of the IP field is not "Protocol-ID", it is "Protocol". The fact that you choose to embellish that field name confirms my feeling that there is a problem with the official name: whenever one talks about "the IP Protocol", there is the potential for confusion -- do you mean IP itself or the protocol running on top of IP? (Yes, I know that the first interpretation requires tolerance of redundancy -- "the Internet Protocol Protocol" -- but such tolerance is quite common, often not even noticed.) I think the name "Payload Type" removes this ambiguity. It also pairs well with "Payload Length". Steve From owner-Big-Internet@munnari.oz.au Thu Sep 24 03:43:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22407; Thu, 24 Sep 1992 03:44:17 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22401; Thu, 24 Sep 1992 03:43:52 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA06569; Wed, 23 Sep 92 13:43:13 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA02710; Wed, 23 Sep 92 10:42:18 PDT Message-Id: <9209231742.AA02710@aland.bbn.com> To: kasten@ftp.com (Frank Kastenholz) Cc: craig@aland.bbn.com, dcrocker@mordor.stanford.edu, deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of Wed, 23 Sep 92 13:37:52 -0400. <9209231737.AA05680@ftp.com> From: Craig Partridge Date: Wed, 23 Sep 92 10:42:18 -0700 Sender: craig@aland.bbn.com Frank: Good points all -- I concede that my attempts to find some way to make just having ports work were misguided. Thanks! Craig From owner-Big-Internet@munnari.oz.au Thu Sep 24 03:49:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22507; Thu, 24 Sep 1992 03:49:40 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22501; Thu, 24 Sep 1992 03:49:23 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA29091; Wed, 23 Sep 92 10:49:12 -0700 Message-Id: <9209231749.AA29091@Mordor.Stanford.EDU> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: SIP Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 23 Sep 92 10:41:27 -0700. <92Sep23.104139pdt.10779@skylark.parc.xerox.com> Date: Wed, 23 Sep 92 10:49:12 -0700 From: Dave Crocker X-Mts: smtp chose a different name than that used by IP. You see, the name of the IP field is not "Protocol-ID", it is "Protocol". The fact that you choose to embellish that field name confirms my feeling that there is a problem with the official name: whenever one talks about Ouch! Point taken. From owner-Big-Internet@munnari.oz.au Thu Sep 24 05:37:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24676; Thu, 24 Sep 1992 05:37:51 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24665; Thu, 24 Sep 1992 05:37:28 +1000 (from kasten@ftp.com) Received: by ftp.com id AA11441; Wed, 23 Sep 92 15:37:15 -0400 Date: Wed, 23 Sep 92 15:37:15 -0400 Message-Id: <9209231937.AA11441@ftp.com> To: deering@parc.xerox.com Subject: Re: SIP From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload Type | Hop Limit | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > My own reasoning for keeping these fields the size I did was: > > - Keeping the Payload Type field 8 bits wide discourages the > undesirable proliferation of transport protocols (and of "options", > given that SIP also uses the Payload Type field for option-like stuff). > > - Keeping the Hop Limit field 8 bits wide discourages the construction > of an internet with diameter greater than 255 hops. In fact, I > think a goal should be to keep the diameter well under 64 hops. I didn't mean to suggest that we make use of this full size. However, we have never built a ubiquitous, World-wide Internet before so can we say for sure that 255 hops is not enough? Though I imagine that it is. Perhaps a MBZ byte, a Payload Type byte, a MBZ byte, a Hop Limit byte. > - Regarding keeping the Payload Length at 16 bits, if a particular > system or subnetwork can't amortize the fixed costs of handling a > packet over 65,000 bytes, then I suggest that that system or > subnetwork needs to be fixed. At a gigabit, the maximum arrival > rate of 64KB packets is one every 500 microseconds. Are you suggesting > that systems or subnetworks capable of operating at a gigabit > shouldn't be deemed capable of handling 2000 packet events per second? > > > 3. Putting the Hop Limit into the low-order (in Network Byte Order) > > part of a 32-bit word makes it much more efficient for the CPU > > to decrement it, as is needed. > > Could you explain this please? I would have thought that, on modern > processors at least, it would be no more expensive to subtract 0x01000000 > from a 32-bit word than to decrement it by one. Aren't both of those > just one ALU operation? Yes, it is one ALU operation. But you also have to take into account memory operations AND you have to test the result to see if the packet should be tossed. Subtracting 0x01000000 probably will require a memory fetch to get the 0x01000000. Subtracting 1 usually does not require this since many processors have some form of decrement instruction. Also, you have to test the resulting value to see if the packet should be tossed or not. Again, some processors have instructions that do 16->32 bit integer conversions. Placing the Hop Limit where I did makes it possible to use these instructions. The alternative is to use an AND instruction to mask off the bits I do not want. But this probably requires a second memory fetch to get the mask to use. I admit that talking about single instructions and memory fetches and so on is really really low-level stuff. But, even though processors are real fast, so are the networks. The number of instructions that are available per packet gets to be very small very fast. Cranking the CPU speed up is not as simple as it sounds since A) the faster CPU costs more money, B) the faster CPU requires that all of the other parts (esp. memory!) are faster, costing even MORE money, C) a faster CPU means higher frequency radio emissions from the box, possibly leading to redesigning the physical enclosure, more powerful filters, etc, etc, D) higher frequency signals on the PC board traces changes their crosstalk and impedence characteristics, possibly requiring that the PC board be redone. All of this costs money and the Router market is becomming more and more of a commodity market -- everyone has OSPF, everyone has SNMP, etc, etc so the only things left, really, are price/performance. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Thu Sep 24 06:04:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25230; Thu, 24 Sep 1992 06:05:17 +1000 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25212; Thu, 24 Sep 1992 06:04:56 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA05853 (5.65/1.23); Wed, 23 Sep 92 16:04:18 -0400 Date: Wed, 23 Sep 92 16:04:18 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9209232004.AA05853@sadye.emba.uvm.edu> To: Johnny Zweig Cc: big-internet@munnari.oz.au Subject: SIP's extra 32 bits In-Reply-To: <9209231719.AA25952@delirius.cs.uiuc.edu> References: <9209231719.AA25952@delirius.cs.uiuc.edu> < said: > Since the payload length field is probably not of interest to routers along the > way (their data link layer ought to tell them in most cases), I don't see why > the field needs to be a convenient multiple of anything. You're the second person to think this in a month. (The first was Paul T.). Remember DIX Ethernet! There is *no* data link layer length field. (There isn't even an LLC layer.) As a practical matter, any protocol which wants to be the successor to IP *must* operate over DIX Ethernet V2.0. Preferably, it would have the same Ether codepoint, and have a four-bit field up front indicating IP version 7. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Thu Sep 24 07:10:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26265; Thu, 24 Sep 1992 07:10:37 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26245; Thu, 24 Sep 1992 07:10:07 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA02612; Wed, 23 Sep 92 14:09:37 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA13371; Wed, 23 Sep 92 17:09:35 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA10400; Wed, 23 Sep 92 17:08:19 EDT Date: Wed, 23 Sep 92 17:08:19 EDT From: Frank T. Solensky Message-Id: <9209232108.AA10400@fenway.andr.UB.com> To: deering@parc.xerox.com, kasten@ftp.com Subject: Re: SIP Cc: big-internet@munnari.oz.au I'll admit that I haven't pulled the draft over yet, so some of what follows may be dismissed as comments from the uninformed. Since that's rarely been known to be much of an impediment for me: >Header Checksum Not used; transport pseudo-header checksum > protects destinations from accepting corrupted > packets. This is more of a meta-question: do we want to assume that the transport layer checksum will be enough of a backup to the link-layer checksum? I still feel basically uncomfortable with the idea of corrupted SIP (, PIP, WHIP {-IP}) packets wandering around until they get to their final destination address. The shortcomings of this were brought up a few weeks ago (on the PIP list, if I remember correctly): the packet corruption may be such that it never gets to the real destination to have the transport layer checksum checked, or may be so hopelessly mangled that it causes routers between here and there to crash. > > Time to Live SIP uses Hop Limit instead, to provide protection > > from routing loops. Transport protocols are expected > > to provide their own protection against long-lived > > packets. > >Note that TCP relies on the maximum packet lifetime that the TTL field >provides (in theory) via its time-based decrementing. > I assume you (Frank) are referring to the 2 MSLs that TCP needs for a socket to be in TIME_WAIT state before the same socket pair can be reused? It seems that this timer is already in place as protection against the failure of this mechanism rather than relying on the TTL field being handled properly. > (It is somewhat similar to the > proposal by R. Ullmann, published as draft-ullmann-ipv7-00.txt in the > internet-drafts repositories. For some reason, that proposal has not > seen much, if any, discussion on this list.) My feeling is that it may have suffered from bad timing: the two submissions he made to the list were sent out during the IETFs that first created and then presented the ROAD working group efforts. Also, there was some comments that it did very little to deal with the problem of routing table explosion (but that may have been directed more at the first submission rather than the second one). From owner-Big-Internet@munnari.oz.au Thu Sep 24 08:04:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27235; Thu, 24 Sep 1992 08:04:23 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27220; Thu, 24 Sep 1992 08:04:03 +1000 (from chris@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA18979; Wed, 23 Sep 92 18:03:48 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA19944; Wed, 23 Sep 92 18:03:28 EDT Date: Wed, 23 Sep 92 18:03:28 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209232203.AA19944@cannibal.gandalf.ca> To: zweig@cs.uiuc.edu, Garrett.Wollman@UVM.EDU Subject: Re: SIP's extra 32 bits Cc: big-internet@munnari.oz.au :-) You're the second person to think this in a month. (The first was :-) Paul T.). Remember DIX Ethernet! There is *no* data link layer :-) length field. (There isn't even an LLC layer.) If padding between the payload end and the packet end is outlawed it should be easy to find its length, given that packets are usually at least delimited by the data links (even SLIP does this). -Chris Sullivan From owner-big-internet@munnari.oz.au Thu Sep 24 08:15:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27532; Thu, 24 Sep 1992 08:15:34 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23134; Thu, 24 Sep 1992 04:22:33 +1000 (from kasten@ftp.com) Received: by ftp.com id AA08002; Wed, 23 Sep 92 14:22:06 -0400 Date: Wed, 23 Sep 92 14:22:06 -0400 Message-Id: <9209231822.AA08002@ftp.com> To: zweig@cs.uiuc.edu Subject: Re: SIP's extra 32 bits From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au > Since the payload length field is probably not of interest to routers along the > way (their data link layer ought to tell them in most cases), I don't see why > the field needs to be a convenient multiple of anything. Suppose that you receive a SIP packet on an ETHERNET (not 802.3) interface and the packet is 20 bytes of header and 20 bytes of payload. ETHERNET will pad this 40 byte packet out to 46 bytes. The ETHERNET interface will not provide you with any way of determining that 6 padding bytes were added. These padding bytes do want to be removed. You could be receiving this packet from your Ethernet and sending them over a 2400 baud dial-up slip-like line. > So why not have 8 bits of TOS and 24 bits of payload length, instead of the 32 > bits of payload length Frank Kastenholz suggested? It seems like 256 points in > the latency/reliability/expense space is more than most routers would bother > dealing with in policy decisions anyway, and adding another 64- or 128 bits of > TOS header seems like a lot to pay, especially given that now routers would > need to worry about TCP-over-SIP, TCP-over-TOS-over-SIP, etc. (using the > payload type field to discriminate seems like it would double the number of > defined payload types, since there would be Foo-over-SIP-with-TOS for each > protocol Foo). When I made my suggestion I thought of this. I rejected the notion since I am not sure that we know enough about TOS/policy to say that this sort of scheme is the right one. However, after having some conversations about streams and so on, and having lunch so that my brain is fueled up, the stream identification could be the concatenation of the two end-point identifiers and this 8-bit number. > It seems to me router hardware should be happier grabbing 64 bits at the > beginning of a SIP packet and masking off the 8 bits of TOS than messing > around with a considerably larger number of defined payload types and having > to look further back another few hundred bits to get to the TOS information. This really depends on the actual CPU the memory architecture in a given router. However, most modern processors have the notion of pipeline fetching and/or caching. The incremental cost of accessing the extra memory word could be, effectively, zero. The pipeline could be fetching word nr. 2 while you process word nr. 1. To go off and fetch some other random word of memory could involve something like a pipeline stall/restart which takes time.... -- frank kastenholz From owner-big-internet@munnari.oz.au Thu Sep 24 08:30:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28337; Thu, 24 Sep 1992 08:30:25 +1000 (from owner-big-internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23901; Thu, 24 Sep 1992 05:04:11 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12060>; Wed, 23 Sep 1992 12:03:54 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <10779>; Wed, 23 Sep 1992 12:03:47 -0700 To: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP In-Reply-To: Your message of Wed, 23 Sep 92 06:28:45 -0700. <9209231328.AA22820@ftp.com> Date: Wed, 23 Sep 1992 12:03:44 PDT From: Steve Deering Message-Id: <92Sep23.120347pdt.10779@skylark.parc.xerox.com> > From: kasten@ftp.com (Frank Kastenholz): > > I think that adding the extra 32 bit field would be a good thing. I > would structure the first 64 bits as follows: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Type | Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ My own reasoning for keeping these fields the size I did was: - Keeping the Payload Type field 8 bits wide discourages the undesirable proliferation of transport protocols (and of "options", given that SIP also uses the Payload Type field for option-like stuff). - Keeping the Hop Limit field 8 bits wide discourages the construction of an internet with diameter greater than 255 hops. In fact, I think a goal should be to keep the diameter well under 64 hops. - Regarding keeping the Payload Length at 16 bits, if a particular system or subnetwork can't amortize the fixed costs of handling a packet over 65,000 bytes, then I suggest that that system or subnetwork needs to be fixed. At a gigabit, the maximum arrival rate of 64KB packets is one every 500 microseconds. Are you suggesting that systems or subnetworks capable of operating at a gigabit shouldn't be deemed capable of handling 2000 packet events per second? > 3. Putting the Hop Limit into the low-order (in Network Byte Order) > part of a 32-bit word makes it much more efficient for the CPU > to decrement it, as is needed. Could you explain this please? I would have thought that, on modern processors at least, it would be no more expensive to subtract 0x01000000 from a 32-bit word than to decrement it by one. Aren't both of those just one ALU operation? > Note that TCP relies on the maximum packet lifetime that the TTL field > provides (in theory) via its time-based decrementing. Yes, but very few, if any, routers perform time-based decrementing. Therefore, I am not introducing any new vulnerability, relative to current practice. I think TCP should be fixed to detect very old packets (and there has been at least one proposal for doing exactly that, using the TCP timestamp option that was introduced for running TCP over long, fat pipes), regardless of what the underlying internet layer claims to guarantee regarding max packet lifetime. Steve From owner-Big-Internet@munnari.oz.au Thu Sep 24 08:40:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28599; Thu, 24 Sep 1992 08:40:52 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28585; Thu, 24 Sep 1992 08:40:15 +1000 (from chris@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA25853; Wed, 23 Sep 92 18:40:01 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA20098; Wed, 23 Sep 92 18:39:40 EDT Date: Wed, 23 Sep 92 18:39:40 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209232239.AA20098@cannibal.gandalf.ca> To: chris@gandalf.ca, Garrett.Wollman@UVM.EDU Subject: Re: SIP's extra 32 bits Cc: big-internet@munnari.oz.au :-) Ummm, are you prepared to ensure that any IPgram that might possibly :-) be sent is guaranteed to have a length greater than 60 bytes? Well, I *said* if you outlawed padding! So, you outlaw Ethernet, simple, no? Either that, or you make the header long enough to meet Ethernet's minimum, in which case you probably have lots of room for a length field! %^} Never mind. A thousand points of light... No new taxis... \ / - . - / \ From owner-big-internet@munnari.oz.au Thu Sep 24 10:38:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02481; Thu, 24 Sep 1992 10:38:55 +1000 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01073; Thu, 24 Sep 1992 10:00:44 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA09754; Wed, 23 Sep 92 20:00:07 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA04543; Wed, 23 Sep 92 16:59:08 PDT Message-Id: <9209232359.AA04543@aland.bbn.com> To: Steve Deering Cc: Frank Kastenholz Cc: big-internet@munnari.oz.au Subject: subtraction on modern processors From: Craig Partridge Date: Wed, 23 Sep 92 16:59:08 -0700 Sender: craig@aland.bbn.com Hi Steve: Well, the DEC Alpha, which claims it is a modern processor (no snide remarks please), only supports immediate operands between 0 and 255. So while subtracting 1 is a single instruction, subtracting 0x01000000 appears to require three instructions (load #1, shift appropriate number of bits over, subtract). More generally, I'd expect the desire to keep instruction sizes fixed means that subtracting large numbers as immediate values suggests the Alpha is a good example of what we should expect from future processors. Craig From owner-Big-Internet@munnari.oz.au Thu Sep 24 10:59:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03191; Thu, 24 Sep 1992 11:00:11 +1000 (from owner-Big-Internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03135; Thu, 24 Sep 1992 10:59:18 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA20347; Wed, 23 Sep 92 20:59:44 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9209240059.AA20347@wizard.gsfc.nasa.gov> Subject: Re: SIP To: deering@parc.xerox.com (Steve Deering) Date: Wed, 23 Sep 92 20:59:43 EDT Cc: big-internet@munnari.oz.au In-Reply-To: <92Sep22.183148pdt.10779@skylark.parc.xerox.com>; from "Steve Deering" at Sep 22, 92 6:31 pm X-Mailer: ELM [version 2.3 PL11] Steve, I think there needs to be a TOS field in the SIP header. All the information needed by a router to do normal forwarding should be at the beginning of the packet at a well known offset. And I think TOS is orthogonal to what port is being used. The same port may want to use different TOS values depending on circumstances. I also believe that it might be highly desirable to put the port info into the header. Among other things, it would be useful to allow routers to do filtering based upon port number (not that I advocate doing this; I don't, but I recognize that others find such a feature useful). I find it quite useful that IP and also TCP (if no IP options which is the predominant case) have all the really important information at well known offsets in the overall packet. It sure makes looking at packet traces for debugging a lot easier. Related to the above, I had a possibly weird idea. What if you did the following with SIP and a New TCP (NTCP)? +----------------------------------------------------------+ | SIP | NTCP | DATA | NTCP OPTIONS | SIP OPTIONS | +----------------------------------------------------------+ Is there some fundamental reason why this would be a bad idea? Would it really mess up the processing of the packet by the host or router? Or would it enable more efficient processing of the packet for the most common case? If the options are used rarely, then it might not be a problem. If the options are used frequently, then maybe they should be in the main header. Just some thoughts off the top of my head on your proposal. -Bill From owner-Big-Internet@munnari.oz.au Thu Sep 24 12:26:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06160; Thu, 24 Sep 1992 12:26:56 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06156; Thu, 24 Sep 1992 12:26:44 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07105; Wed, 23 Sep 92 19:26:14 -0700 Date: Wed, 23 Sep 92 21:16:37 EDT From: "William Allen Simpson" Message-Id: <746.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Reply-To: bsimpson@angband.stanford.edu Subject: Re: SIP How about: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Stream |C| 0 | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Type | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Destination Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Source Address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: Protocol 8 bits, different than IP4 *AND* any ISO NLPIDs. I'm still not convinced that this field isn't useful. Stream 8 bits, unique number for source-destination connection. (surely there will never be more than 256 open pairs). Could be used for setup of resource allocation, and the number could be reused for multiple FTP data connections to save setup time. C our friend, the "Congestion Experienced" bit. 0 more bits, for later. (or the Hop Limit could be a few bits bigger.) And wouldn't it be more logical to have the Destination before the Source? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Thu Sep 24 15:45:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13781; Thu, 24 Sep 1992 15:46:44 +1000 (from owner-Big-Internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13744; Thu, 24 Sep 1992 15:45:34 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA20915; Thu, 24 Sep 92 01:46:04 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9209240546.AA20915@wizard.gsfc.nasa.gov> Subject: Request for Bibliography of IPv7 / Big Internet Documents To: big-internet@munnari.oz.au Date: Thu, 24 Sep 92 1:46:04 EDT X-Mailer: ELM [version 2.3 PL11] If it doesn't already exist (and if it does I haven't been able to find it), could someone create a bibliography of all the relevant documents relating to IP version 7 and Big Internet issues, including the archive machines and file names for the documents? Then, could this file be put in the internet-drafts directory under some obvious name? And finally, could all the relevant documents include a reference to this bibliograpy file and its location? This would greatly assist people like me who are trying to get up to speed on these issues before the November IETF meeting. These are the documents that I know of with some comments thrown in: Acronym Title/Archive Author(s) ------- ------------- --------- ROAD The Internet Routing and Brim, S. Addressing Task Force: Ford, P. Summary Report ? [I have not been able to find this document which is referenced by the next document and I have really searched for it] IPv7 IP Version 7 IAB nnsc.nsf.net:internet-drafts/draft-iab-ipversion7-00.txt C# A Revision to IP Address Solensky, F. Classifications Kastenholz, F. nnsc.nsf.net:internet-drafts/draft-solensky-csharp-00.txt CIDR RFC 1338 Fuller, V. Supernetting: an Address Li, T. Assignment and Aggregation Yu, J. Strategy Varadhan, K. nic.ddn.mil:rfc/rfc1338.txt [Once you translate your search key from CIDR to supernetting, you've got it made to find this] TUBA RFC 1347 Callon, R. TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing nic.ddn.mil:rfc/rfc1347.txt Use of ISO CLNP in TUBA Piscitello, D. Environments nnsc.nsf.net:internet-drafts/draft-piscitello-clnp-00.txt IPAE A Proposal for IP Address Hinden, R. Encapsulation (IPAE): A Crocker, D. Compatible Version of IP with Large Addresses nnsc.nsf.net:internet-drafts/draft-crocker-ip-encaps-00.txt NAT The IP Network Address Tsuchiya, P. Translator (Nat): Preliminary Design nnsc.nsf.net:internet-drafts/draft-tsuchiya-addrtrans-00.txt [Once you translate your search key from NAT to addrtrans, you've got it made to find this. Also made more difficult to find by not being in the 1id-abstracts.txt file] PIP Pip: The `P' Internet Protocol Tsuchiya, P. nnsc.nsf.net:internet-drafts/draft-tsuchiya-pip-00.txt Pip Overview and Examples Tsuchiya, P. nnsc.nsf.net:internet-drafts/draft-tsuchiya-pip-overview-01.txt NIMROD The IP Addressing Issue Chiappa, N. nnsc.nsf.net:internet-drafts/draft-chiappa-ipaddressing-00.txt A New IP Routing and Chiappa, N. Addressing Architecture nnsc.nsf.net:internet-drafts/draft-chiappa-routing-00.txt [I think the above is correct although I didn't find the acronym NIMROD referenced anywhere. This made finding these documents difficult until I put two and two together and linked them via their author, namely Noel Chiappa. I thought NIMROD stood for New Internet Model for Routing and Addressing but that's obviously not quite right. On a similar vein, why is it IPv7? What happened to IPv5 and IPv6?] UNIFIED RFC 1322 Estrin, D. A Unified Approach to Rekhter, Y. Inter-Domain Routing Hotz, S. nic.ddn.mil:rfc/rfc1322.txt SIP SIP: A Simple Internet Deering, S. Protocol parcftp.xerox.com:pub/net-research/sip-spec [This was just announced to the big-internet list and isn't in any on-line index of documents which will make it difficult for others to find] For all the Internet Drafts, I think it would be extremely helpful if the usual acronym for the proposal appeared in the file name of the document so it could be easily found by searching the index file and also in the 1id-abstracts.txt file. Could anyone add to this list of must read documents to prepare for the November IETF? And does anyone know where the ROAD document lives? Also, it might be nice to list any associated mail lists for the above together with the archive site for the mail list. I hope someone else finds all this useful. -Bill From owner-Big-Internet@munnari.oz.au Thu Sep 24 15:56:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14275; Thu, 24 Sep 1992 15:56:54 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14272; Thu, 24 Sep 1992 15:56:39 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12147>; Wed, 23 Sep 1992 22:56:21 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Wed, 23 Sep 1992 22:56:13 -0700 To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP In-Reply-To: Your message of "Wed, 23 Sep 92 18:53:33 PDT." <749.bill.simpson@um.cc.umich.edu> Date: Wed, 23 Sep 1992 22:56:12 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep23.225613pdt.10779@skylark.parc.xerox.com> > From: "William Allen Simpson" > > Why 500? Isn't it true that all current IP4 links will handle 576? And > every link type I know of (except SLIP, which would be obsolete) can > handle 1500. Examples? No, it's not true that all IPv4 links will handle 576 octet packets. That's a common misunderstanding. The minimum link MTU allowed by IPv4 is 68 octets (see the IP spec, RFC-791, page 25). As part of the work in preparing the Path MTU Discovery spec, Jeff Mogul surveyed all of the IP-over-xxx specifications and came up with a list of MTUs for links commonly used in the Internet, some of which are less than 576 (see RFC-1191, page 17). The smallest was 296, which is the MTU often used over SLIP lines using Jacobson header compression. The next smallest was 508, for ARCNET. The small MTU for C-SLIP is to prevent interactive packets from having to wait too long while a big packet occupies a 9600-bps link; I figure that by the time SIP gets widely deployed (if it ever does), everyone with 9600 bps modems will have upgraded to 19.2 Kbps or better, so the MTU over such lines can safely be doubled without increasing the maximum link occupancy time. Given that CLNP requires a minimum MTU of 512, and the next-smallest-to-SLIP MTU in the Internet is 508, I thought 500 would be a safe choice for SIP. Making the SIP minimum MTU be just a little less than exactly 508 is helpful, because then any source that is doing MTU Discovery will end up sending its full-size packets with a length bigger than than the minimum, which can be observed and exploited by the SIP tunneling mechanism described in my draft. The number 576 is the minimum reassembly buffer size required in all IP systems. It has nothing to do with link MTUs. > > SIP addresses are 64 bits (8 octets) long. The notation for writing SIP > > addresses is 16 hexadecimal digits, with a dot after the 4th digit and > > optional dots after any subsequent digit. Examples: > > ... > > Could we use ":" instead of "."? That would help differentiate between > domain.names and addresses (now that hex characters are allowed). Hmm, I hadn't thought of that possible ambiguity. Sure, we could use ":"; I actually prefer "-", myself. Anyone else have an opinion on the notation for SIP addresses? (Please send your opinions to me, not the whole list -- there are more pressing issues to discuss on the list than punctuation.) Thanks for the comments, Bill. Steve From owner-Big-Internet@munnari.oz.au Thu Sep 24 22:05:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26742; Thu, 24 Sep 1992 22:05:54 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209241205.26742@munnari.oz.au> Received: from research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26737; Thu, 24 Sep 1992 22:05:44 +1000 (from hgs@research.att.com) Received: by inet; Thu Sep 24 08:05 EDT 1992 Date: Thu, 24 Sep 92 08:05:32 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: kasten@ftp.com, big-internet@munnari.oz.au Subject: Re: SIP's extra 32 bits Regarding the length field in SIP: since not all data link layers need it, wouldn't it make sense to make it part of the SIP-over-xyz spec so that SIP-over-802.3 would be prefixed by a length field (given the MTU, 16 bit would be sufficient here) but SIP-over-PPP wouldn't (which would help particularly for the typically low bit rates PPP is used for). Omitting the length field has two advantages: a) saves space, b) one less check to worry about (or, if you want, one less opportunity to throw out corrupted packets). Thus, it seems to be in the spirit of a minimalist/RISC header to omit the length field. Regarding header checksum: a router that chokes on corrupted packets shouldn't be in the network anyway. Sooner or later the checksum mechanism will fail and trip the router. We should probably look at exactly what could happen if different fields in the header contain random garbage. One could imagine, for example, that a corrupted stream identifier (whatever form it takes) could force the packet to circulate at highest priority until its TTL is exhausted. This could be a problem, albeit extremely unlikely, if its a MTU-sized packet in terms of performance guarantees to other streams. --- Henning Schulzrinne (hgs@research.att.com) AT&T Bell Laboratories (MH 3D-438) 600 Mountain Ave; Murray Hill, NJ 07974 phone: +1 908 582-2262; fax: +1 908 582-5809 From owner-Big-Internet@munnari.oz.au Thu Sep 24 22:42:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28008; Thu, 24 Sep 1992 22:42:50 +1000 (from owner-Big-Internet) Return-Path: Received: from xap.xyplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28003; Thu, 24 Sep 1992 22:42:39 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Thu, 24 Sep 92 08:40:50 -0500 Received: by mjm.xyplex.com (4.1/SMI-4.1) id AA00690; Thu, 24 Sep 92 08:43:09 EDT Date: Thu, 24 Sep 92 08:43:09 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9209241243.AA00690@mjm.xyplex.com> To: big-internet@munnari.oz.au In-Reply-To: Johnny Zweig's message of Wed, 23 Sep 92 12:19:19 CDT <9209231719.AA25952@delirius.cs.uiuc.edu> Subject: SIP header processing If you're going to be concerned about aligning fields for efficiency, you should do so _after_ including the presence of a datalink layer header. Aligning a 32 bit value on a 32 bit boundary relative to the start of this layer's header does little good to a RISC protocol processor that sees the message in memory preceded by a 14 byte (for one example) datalink header. I suppose that to be "correct" for all cases, a pad area of N bytes would have to be prepended to your SIP header, where N was a function of the particular data link layer the message uses. Regards, Milan J. Merhar milan@eng.xyplex.com Phone:(508)264-9900 330 Codman Hill Rd. Boxborough, MA 01915 Fax:(508)264-9930 From owner-Big-Internet@munnari.oz.au Thu Sep 24 22:51:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28372; Thu, 24 Sep 1992 22:51:50 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28365; Thu, 24 Sep 1992 22:51:39 +1000 (from kasten@ftp.com) Received: by ftp.com id AA00842; Thu, 24 Sep 92 08:50:59 -0400 Date: Thu, 24 Sep 92 08:50:59 -0400 Message-Id: <9209241250.AA00842@ftp.com> To: chris@gandalf.ca Subject: Re: SIP's extra 32 bits From: kasten@ftp.com (Frank Kastenholz) Cc: zweig@cs.uiuc.edu, Garrett.Wollman@UVM.EDU, big-internet@munnari.oz.au > :-) You're the second person to think this in a month. (The first was > :-) Paul T.). Remember DIX Ethernet! There is *no* data link layer > :-) length field. (There isn't even an LLC layer.) > > If padding between the payload end and the packet end is outlawed it should > be easy to find its length, given that packets are usually at least delimited > by the data links (even SLIP does this). > > -Chris Sullivan Chris. Go read the Ethernet/802.3 specs. the minimum size of the data field of these packets is 46 bytes. This is rooted in physics -- the max length of the 802.3/Ethernet cables and the propagation delay of the bits on said wire conspire to make this so. It can not be changed by administrative fiat. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Fri Sep 25 01:06:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03994; Fri, 25 Sep 1992 01:06:09 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03986; Fri, 25 Sep 1992 01:06:02 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07807; Thu, 24 Sep 92 08:05:40 -0700 Date: Thu, 24 Sep 92 10:26:53 EDT From: "William Allen Simpson" Message-Id: <756.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Reply-To: bsimpson@angband.stanford.edu Subject: SIP header alignment > From: Steve Deering > - Still undecided: whether or not an additional 32-bit field should be > added to the SIP header to achieve 64-bit alignment (as it is, the > two address fields can be 64-bit aligned by making sure the packet > starts at an odd-word address, where word = 32 bits). The extra > 32 bits, if added, would be used for classifying packets deserving > of special handling, e.g., non-default quality of service or > real-time service. On the other hand, the transport-layer port > fields may be adequate for performing any such classification. > (One possibility would be simply to remove the port fields from > TCP & UDP and put them in the SIP header, like XNS.) I just realized we don't want to add more fields to the front of the SIP header. Every SIP header will arrive with some DLL header in front. I will use PPP for an example. It was deliberately designed to add a 32-bit header (wasting bytes in some folk's opinion). So the SIP header will follow the PPP header, putting the Source and Destination fields on 64-bit boundaries. Could someone detail how Ethernet and 802.x headers will affect alignment? What about Frame Relay, X.25, etc? Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Fri Sep 25 01:19:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04416; Fri, 25 Sep 1992 01:19:17 +1000 (from owner-big-internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03324; Fri, 25 Sep 1992 00:45:28 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA31453 (5.65c/UK-2.1-920831); Thu, 24 Sep 1992 10:47:14 -0400 From: Gary Scott Malkin Date: Thu, 24 Sep 1992 10:47:14 -0400 Message-Id: <31453.199209241447@atlas.xylogics.com> To: milan@mjm.xyplex.com Cc: big-internet@munnari.oz.au In-Reply-To: Milan Merhar's message of Thu, 24 Sep 92 08:43:09 EDT <9209241243.AA00690@mjm.xyplex.com> Subject: SIP header processing > If you're going to be concerned about aligning fields for efficiency, > you should do so _after_ including the presence of a datalink layer > header. Aligning a 32 bit value on a 32 bit boundary relative to the > start of this layer's header does little good to a RISC protocol > processor that sees the message in memory preceded by a 14 byte > (for one example) datalink header. Many routers already deal with this issue by always reading the packet into a buffer with a datalink dependent offset. The offsets are such that the IP header always starts in the same place in the buffer. This wastes a little space if the router has multiple interfaces with vastly different sized maximum header lengths, but it saves a lot of processing time (the old trade off). ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Fri Sep 25 02:11:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06306; Fri, 25 Sep 1992 02:12:11 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06293; Fri, 25 Sep 1992 02:11:58 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA19896; Thu, 24 Sep 92 09:11:50 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA14104; Thu, 24 Sep 92 12:11:49 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA11396; Thu, 24 Sep 92 12:10:32 EDT Date: Thu, 24 Sep 92 12:10:32 EDT From: Frank T. Solensky Message-Id: <9209241610.AA11396@fenway.andr.UB.com> To: big-internet@munnari.oz.au, hgs@research.att.com, kasten@ftp.com Subject: Header checksum (was Re: SIP's extra 32 bits) >Regarding header checksum: >a router that chokes on corrupted packets shouldn't be in the network >anyway. Sooner or later the checksum mechanism will fail and trip the >router. But that doesn't cover it completely. Say some router scribbles into the middle of a packet either just before or while a frame is queued up on an xmit queue: if the CRC is being done in hardware, it'll be appended to the packet as it's leaving the box -- after the scribble. The CRC will be right, but the frame will be wrong! >One could >imagine, for example, that a corrupted stream identifier (whatever form >it takes) could force the packet to circulate at highest priority until >its TTL is exhausted. Now imagine that the TTL is also corrupted, so that it gets set to a higher value? And if there's a routing loop or the source address also gets munged so that it eventually winds up going back to get corrupted again. You've got "The Packet that Wouldn't Die". Sure, it's an extreme example, but I think having a little extra protection is worth the performance hit. -- Frank Solensky From owner-Big-Internet@munnari.oz.au Fri Sep 25 02:15:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06398; Fri, 25 Sep 1992 02:16:09 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06393; Fri, 25 Sep 1992 02:15:51 +1000 (from kre) To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: big-internet@munnari.oz.au Subject: Re: Request for Bibliography of IPv7 / Big Internet Documents In-Reply-To: Your message of Thu, 24 Sep 92 01:46:04 -0400. <9209240546.AA20915@wizard.gsfc.nasa.gov> Date: Fri, 25 Sep 92 02:15:44 +1000 Message-Id: <6362.717351344@munnari.oz.au> From: Robert Elz Date: Thu, 24 Sep 92 1:46:04 EDT From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-ID: <9209240546.AA20915@wizard.gsfc.nasa.gov> could someone create a bibliography of all the relevant documents relating to IP version 7 and Big Internet issues, This is an excellent idea, and well needed. It would also be nice if someone could contribute a glossary, The B-I stuff is just full of new acronyms... kre From owner-Big-Internet@munnari.oz.au Fri Sep 25 02:24:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06643; Fri, 25 Sep 1992 02:24:48 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06640; Fri, 25 Sep 1992 02:24:40 +1000 (from chris@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA28059; Thu, 24 Sep 92 12:24:20 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA22482; Thu, 24 Sep 92 12:23:57 EDT Date: Thu, 24 Sep 92 12:23:57 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9209241623.AA22482@cannibal.gandalf.ca> To: kasten@ftp.com Subject: Re: SIP's extra 32 bits Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.edu Sorry: I *was* feeling a little air-headed yesterday. However invitations to admit being a fool are only being accepted once per demonstration thereof. Garrett beat you to it. Henning Schulzrinne wrote: > Regarding the length field in SIP: > since not all data link layers need it, wouldn't it make sense to > make it part of the SIP-over-xyz spec so that SIP-over-802.3 would be > prefixed by a length field (given the MTU, 16 bit would be sufficient here) > but SIP-over-PPP wouldn't (which would help particularly for the typically > low bit rates PPP is used for). Omitting the length field has two > advantages: a) saves space, b) one less check to worry about (or, if > you want, one less opportunity to throw out corrupted packets). Bill Simpson replied: > PPP needs the length field, it has arbitrary padding. but he also recently sent out a new document containing a "Self Describing Pad" option the use of which in SIP over PPP would allow the SIP packet to be distinguished from any pad chracters. It effectively puts the info where it belongs: in the pad. -Chris From owner-Big-Internet@munnari.oz.au Fri Sep 25 03:11:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07870; Fri, 25 Sep 1992 03:11:49 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07863; Fri, 25 Sep 1992 03:11:27 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-8) id ; Thu, 24 Sep 1992 10:10:35 -0700 Date: Thu, 24 Sep 1992 10:10:35 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199209241710.AA28812@zephyr.isi.edu> To: deering@parc.xerox.com, kasten@ftp.com, solensky@andr.ub.com Subject: Re: SIP Cc: big-internet@munnari.oz.au > > > >Note that TCP relies on the maximum packet lifetime that the TTL field > >provides (in theory) via its time-based decrementing. > > > > I assume you (Frank) are referring to the 2 MSLs that TCP needs for a socket > to be in TIME_WAIT state before the same socket pair can be reused? It seems > that this timer is already in place as protection against the failure of this > mechanism rather than relying on the TTL field being handled properly. > Frank, No, he is referring to the fundamental mechanism for correct data transmission; at high speeds, there is a danger from old duplicate packets when the 32-bit TCP sequence space wraps. Please see the Proposed Standard TCP extensions in RFC-1323. An aside on SIP: it sounds very nice to say that the transport layer is responsible for enforcing MSL (and many of my friends think it is Just and Righteous to do so), but note that this implies increasing the size of the transport protocol sequence space, either directly or else indirectly with an timestamp. This increases the tranport header size; if you push on the IP layer, it pops up elsewhere! Finally, I think that omitting [space for a] version number from SIP is a bad idea in practice, even if in principle you can expect the link layer to provide the info. Bob Braden From owner-Big-Internet@munnari.oz.au Fri Sep 25 03:40:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08421; Fri, 25 Sep 1992 03:41:35 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08409; Fri, 25 Sep 1992 03:40:49 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-8) id ; Thu, 24 Sep 1992 10:40:34 -0700 Date: Thu, 24 Sep 1992 10:40:34 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199209241740.AA28900@zephyr.isi.edu> To: big-internet@munnari.oz.au Subject: Re: SIP's extra 32 bits Another way to use the extra 32 bits might be as the "connectionless index" or CI that Dave Clark suggested in his July 14, 1992 message to this list. Bob Braden From owner-big-internet@munnari.oz.au Fri Sep 25 06:24:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11815; Fri, 25 Sep 1992 06:24:25 +1000 (from owner-big-internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09739; Fri, 25 Sep 1992 04:54:25 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 3262; Thu, 24 Sep 92 14:53:17 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 4532; Thu, 24 Sep 92 14:53:17 EDT Date: Thu, 24 Sep 92 14:49:57 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: SIP To: William Allen Simpson , Steve Deering , bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au In-Reply-To: <751.bill.simpson@um.cc.umich.edu> Message-Id: <920924.144957.EDT.VALDIS@vtvm1.cc.vt.edu> On Thu, 24 Sep 92 09:44:39 EDT William Allen Simpson said: >One final note on MTU: in the interest of future 64-bit machines, you >might specify 496 instead. Bill: Maybe I should wait till the caffeine takes hold, but... I see where 496 makes a nice neat x'1F0' - but how is this in the interest of 64-bit machines and not also benefit the current crop of 32-bit boxen? Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-big-internet@munnari.oz.au Fri Sep 25 06:43:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12439; Fri, 25 Sep 1992 06:43:59 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10022; Fri, 25 Sep 1992 05:06:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01889; Thu, 24 Sep 92 15:06:17 -0400 Date: Thu, 24 Sep 92 15:06:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209241906.AA01889@ginger.lcs.mit.edu> To: bill@wizard.gsfc.nasa.gov, kre@munnari.oz.au Subject: Re: Request for Bibliography of IPv7 / Big Internet Documents Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu It would also be nice if someone could contribute a glossary, The B-I stuff is just full of new acronyms... It's not so much the acronyms that worry me as much as the technical terms. The amount of time we've wasted on this list becaue of misunderstandings as to what people were saying, due to subtly different interpretations of terms... A definition of the term "address" that we all agree on would be worth, oh, I don't know how much! Noel From owner-Big-Internet@munnari.oz.au Fri Sep 25 08:01:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15214; Fri, 25 Sep 1992 08:01:29 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15211; Fri, 25 Sep 1992 08:01:20 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA08879 (5.65c/UK-2.1-920831); Thu, 24 Sep 1992 18:04:34 -0400 From: Gary Scott Malkin Date: Thu, 24 Sep 1992 18:04:34 -0400 Message-Id: <8879.199209242204@atlas.xylogics.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au In-Reply-To: Noel Chiappa's message of Thu, 24 Sep 92 15:06:17 -0400 <9209241906.AA01889@ginger.lcs.mit.edu> Subject: Request for Bibliography of IPv7 / Big Internet Documents > A definition of the term "address" that we all agree on would be worth, oh, I > don't know how much! Have you ever heard Radia's definitions for Name, Address and Route? I think they're the clearest I've ever seen. "Y" is a name if: "Y" continues to work, even if host Y moves; and "Y" works for any host X, regardless of X's location. "Y" is an address if: "Y" changes if host Y moves; and "Y" works for any host X, regardless of X's location. "Y" is a route if: "Y" changes if host Y moves; and "Y" is different for X's in different locations. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Sat Sep 26 07:00:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13344; Sat, 26 Sep 1992 07:01:05 +1000 (from owner-Big-Internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13330; Sat, 26 Sep 1992 07:00:58 +1000 (from minshall@wc.novell.com) Received: from [130.57.68.19] by wc.novell.com (4.1/smi4.1.1.v91190) id AA03010; Fri, 25 Sep 92 13:58:06 PDT Date: Fri, 25 Sep 92 13:58:05 PDT Message-Id: <9209252058.AA03010@wc.novell.com> To: big-internet@munnari.oz.au From: minshall@wc.novell.com Subject: Re: SIP Just votes: YES on checksum protecting just the header YES for version number YES for a length field YES for a guaranteed MSL From owner-Big-Internet@munnari.oz.au Sat Sep 26 08:50:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17755; Sat, 26 Sep 1992 08:50:46 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17750; Sat, 26 Sep 1992 08:50:38 +1000 (from prue@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-8) id ; Fri, 25 Sep 1992 15:50:19 -0700 Date: Fri, 25 Sep 1992 15:50:19 -0700 From: prue@ISI.EDU (Walter Prue) Message-Id: <199209252250.AA11737@zephyr.isi.edu> To: solensky@andr.ub.com Subject: Re: Header checksum (was Re: SIP's extra 32 bits) Cc: big-internet@munnari.oz.au, hgs@research.att.com, kasten@ftp.com ... >>One could >>imagine, for example, that a corrupted stream identifier (whatever form >>it takes) could force the packet to circulate at highest priority until >>its TTL is exhausted. > >Now imagine that the TTL is also corrupted, so that it gets set to a higher >value? And if there's a routing loop or the source address also gets >munged so that it eventually winds up going back to get corrupted again. >You've got "The Packet that Wouldn't Die". Sure, it's an extreme example, >but I think having a little extra protection is worth the performance hit. > -- Frank Solensky One of the really neat design attributes I see in IP and TCP is that the protocol doesn't stand in the way and penalize performance when things are working without error. While your scenario is not the sort of thing one would want to see happen I would rather take the risk of an occasional corrupted packet stealing some performance than penalize the billions and billions of packets that cross the backbone with more overhead to forward at each hop. Walt Prue From owner-Big-Internet@munnari.oz.au Sat Sep 26 10:04:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20181; Sat, 26 Sep 1992 10:04:35 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20173; Sat, 26 Sep 1992 10:04:16 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11936>; Fri, 25 Sep 1992 17:03:55 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Fri, 25 Sep 1992 17:03:51 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: TOS in SIP Date: Fri, 25 Sep 1992 17:03:36 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep25.170351pdt.10779@skylark.parc.xerox.com> Warning: long-winded message... I am delighted to see all of the discussion of what SIP might need in the way of a type-of-service or flow-ID field. Although there are no fields currently defined in the SIP header for those purposes, I strongly believe that support for non-default type-of-service and for real-time traffic flows is essential in the Internet. (My involvement with the IETF multimedia multicasts has made that very clear! I also denounced the IAB's CLNP decision on the basis that such a major upheaval was not worth suffering, unless it bought us significant new services, such as support for real-time traffic and for mobility.) Now, this topic of TOS/real-time support is currently a hot research area, and no concensus has yet emerged on exactly what is needed in the way of packet header fields to support such services. Over the past month or so, I have talked about SIP to a number of the people most active in this research, and, although they do not yet all agree on what is needed, they may be getting close. So for now, I'm resisting the urge to define the layout or semantics of a service-type/stream-ID/flow-handle/whatever field, and hoping that the experts will soon tell me what is needed. One expert argues that no special fields are needed, that the TCP/UDP ports will work just fine for this purpose, whether or not they are considered to be part of the internet header (let's not be too dogmatically layerist). If routers want to give special treatment to telnet packets, those packets can be identified by a 6 in the Payload Type field and a 23 in either the Source Port or the Destination Port field. If a particular telnet stream is to be given even more special treatment, the tuple (Source Address, Destination Address, Payload Type, Source Port, Destination Port) can be used to identify its packets, and "longest-match" table lookup -- the same as the route lookup, using a patricia-tree or whatever -- can be used to find the connection-specific state, if present, else the service-specific state, else default. The matching fields don't necessarily have to be processed serially: a packet is simply classified by a particular pattern of bits in one or more ranges of bit positions in the leading part of the packet. Additional patterns can be defined to cover the case where other stuff (such as an n-element source route) may be present between the SIP and transport headers. When I first heard this argument, my objections were the same as Frank Kastenholz's. It sounds like an administrative nightmare to have to add a new entry to a table in all the routers in the world whenever, for example, a new interactive protocol on a new port is invented and it is desired that it enjoy the same treatment as telnet. The counter-argument was that the decision to give certain packets special treatment must be left to the administrators of individual domains. Otherwise, if simply setting an "interactive" bit in the header means you'll get preferential service in all the routers, everyone will set that bit in every packet. Just because Frank invents the Frank Protocol and decides that Frank Protocol packets should get the same favorable treatment as telnet packets doesn't oblige any network administrator to provide that favorable treatment. Either Frank has to convince the world that Frank Protocol packets warrant special treatment, enough so that administrators will update the tables in their routers, or else Frank Protocol sessions have to start with a negotiation protocol, in which special handling is requested from the routing domains along the desired path; the request will likely be accompanied by something that convinces the domains to honor the request, such as an offer of money or proof of authority to obtain special treatment. (Frank also has the choice of just adding the functionality of his new protocol to telnet itself, thus helping to reduce the proliferation of interactive protocols.) Regarding this approach, Craig wrote: > My quick conclusion is that we could use the ports + addrs + protocol > ID as a unique ID for recognizing streams with special TOS requirements, > except that the SIP protocol ID isn't always the ID of the transport protocol > whose port space is being used. It's more complicated than that. If the SIP Payload Type says the payload is a source route, not only does the Payload Type not tell you what transport layer is present, the SIP Destination Address is the wrong address to use for identifying the stream, except during the last leg of the trip. (SIP source routing works the same as IP source routing. The Destination Address changes on each leg of the source route. The ultimate destination address, on which the stream identification must be based, rides along in the last element of the source route, until the final leg.) So I think the packet classification mechanism must be able to look at an arbitrary set of bits in the packet header(s) to identify a stream; note however, that all packets of the same stream can be unambiguously identified by looking at the same set of bits, at any single router (but not all routers will necessarily be looking at the same set of bits). Another person working in this area has suggested that the SIP header should have a field in a fixed location that carries a hash value, computed across those fields necessary to classify the packet into a special-handling class. E.g., if the routers are keeping special-handling state for a particular TCP connection, this field would be a hash over the addresses, payload type, and ports. The hash value would be used to quickly lookup the corresponding connection state, avoiding the arbitrary pattern match across a potentially variable-length packet header. However, verification that the hash look-up succeeded still requires an equality test across all of the fields over which the hash was computed, and the jury is still out on whether or not this yields performance significantly better than the best radix-tree algorithms. For now, I have left any TOS/whatever fields out of SIP, in the hope that an approach using just the ports can be properly architected and efficiently implemented. But I'm certainly open to arguments as to why the ports won't work and as to what should be added to the SIP header, instead. Steve From owner-Big-Internet@munnari.oz.au Sat Sep 26 10:23:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20812; Sat, 26 Sep 1992 10:23:49 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20808; Sat, 26 Sep 1992 10:23:43 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA17065; Fri, 25 Sep 92 17:23:32 -0700 Message-Id: <9209260023.AA17065@Mordor.Stanford.EDU> To: Gary Scott Malkin Cc: big-internet@munnari.oz.au Subject: Re: Request for Bibliography of IPv7 / Big Internet Documents Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 24 Sep 92 18:04:34 -0400. <8879.199209242204@atlas.xylogics.com> Date: Fri, 25 Sep 92 17:23:31 -0700 From: Dave Crocker X-Mts: smtp Gary, Nothing to argue about, with Radia's definitions, but... I have been finding it useful to think about address in terms of its requirement that two nodes which are "next" to each other (or "near") each other are required to have some portion of their address be the same. If there are no location-related rules governing the similarity of the strings, then the strings are names, not addresses. One can, of course, endlessly debate definitions for "next" and "near", but that seems a rather different degree of debate than name-vs-address has been. Dave From owner-Big-Internet@munnari.oz.au Sat Sep 26 11:05:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22055; Sat, 26 Sep 1992 11:06:03 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22048; Sat, 26 Sep 1992 11:05:52 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11989>; Fri, 25 Sep 1992 18:05:29 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Fri, 25 Sep 1992 18:05:26 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: SIP Payload Length field Date: Fri, 25 Sep 1992 18:05:23 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep25.180526pdt.10779@skylark.parc.xerox.com> In response to the following from Johnny Zweig: > Since the payload length field is probably not of interest to routers along > the way (their data link layer ought to tell them in most cases), I don't > see why the field needs to be a convenient multiple of anything. Garret Wollman responded: > You're the second person to think this in a month. (The first was > Paul T.). Remember DIX Ethernet! There is *no* data link layer > length field. (There isn't even an LLC layer.) I think the issue may be a bit more subtle than that. Even though DIX Ethernet does not carry a length field, when a router receives a packet from an Ethernet, the device driver reports how big a packet was received. The reported length may include some padding. Johnny may have been suggesting that the router could simply forward the packet, padding and all; the destination host would be responsible for figuring out how long the significant payload is, and ignoring any padding. I actually toyed with the idea of doing that, but it creates a problem for MTU discovery. Suppose you have a router that receives a 1536-byte SIP packet from a link that pads all packets to be a multiple of 48 bytes, to pick a not-so-random number :-), to be forwarded onto an Ethernet with an MTU of 1500 bytes. The router would send a SIPC (the SIP equivalent of ICMP) message to the source, telling the source to reduce its packet size to 1500 bytes. The source would comply, but the packets would still arrive at the router padded out to 1536, still too big to be forwarded. My own preference is to include a length field in the internet layer header, and permit any link-layer to add padding as needed. (I consider the length field in 802.3 to be a crime against interoperability. I was also disapointed that my proposal for an ATM adaptation layer for datagrams acquired a gratuitous length field, on its way to becoming AAL 5.) Although I appreciate the minimalism of prepending the SIP header with a length field only when traversing padding links, as suggested by Henning, I'd rather retain the nice property of IP of having to know as little as possible about the underlying link. Steve From owner-Big-Internet@munnari.oz.au Sat Sep 26 12:09:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23805; Sat, 26 Sep 1992 12:10:15 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23796; Sat, 26 Sep 1992 12:09:49 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA29348; Fri, 25 Sep 92 22:09:28 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA16800; Fri, 25 Sep 92 19:08:31 PDT Message-Id: <9209260208.AA16800@aland.bbn.com> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: TOS in SIP In-Reply-To: Your message of Fri, 25 Sep 92 17:03:36 -0700. <92Sep25.170351pdt.10779@skylark.parc.xerox.com> From: Craig Partridge Date: Fri, 25 Sep 92 19:08:30 -0700 Sender: craig@aland.bbn.com Hi Steve: Not long-winded at all. Certainly more to the point than lots of what we've seen on the list. Hope you don't mind if I throw a few questions back at you :-) > Additional patterns can be defined to cover the case where other > stuff (such as an n-element source route) may be present between the SIP > and transport headers. In general, I don't like arguing about which O(1) algorithm is better than another, but it seems to me that buying into this scheme means that the amount of header I have to pull into registers and do pattern matching on is variable, yes? Would it not be nicer, and simpler, to have an ID in a fixed place? > The counter-argument was that the > decision to give certain packets special treatment must be left to the > administrators of individual domains. Otherwise, if simply setting an > "interactive" bit in the header means you'll get preferential service in all > the routers, everyone will set that bit in every packet. Just because Frank > invents the Frank Protocol and decides that Frank Protocol packets should get > the same favorable treatment as telnet packets doesn't oblige any network > administrator to provide that favorable treatment. I think this is an odd spin on things. If Frank can convince you in person to support the Frank protocol, why can't he do it via a setup request? (Maybe Frank goes to the IETF and gets a signed certificate he includes in the setup request saying "this is OK"). More generally, my concern is about proper number space management. I already argued that the special port space will become huge if we have to give every guaranteed protocol its own port. I'll further suggest that what in fact goes on in such a situation is that the database of special ports is in fact a three part database: each special port is implicitly mapped to a flow spec, which is then mapped to a queueing service. i.e. at some point (maybe when the code was compiled), someone sat down and figured out the flow spec for the port and decided what queueing service it should receive. Would it not be more flexible to just allow the flows to tell you their flow specs and do the mapping in real-time? Mind you, I'm not fixed in my views -- however, I currently feel the port mapping idea has more long-term scaling problems than IDs with setup protocols and flow specs. Craig From owner-Big-Internet@munnari.oz.au Sat Sep 26 12:16:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23956; Sat, 26 Sep 1992 12:17:18 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23891; Sat, 26 Sep 1992 12:16:16 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12021>; Fri, 25 Sep 1992 19:15:53 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Fri, 25 Sep 1992 19:15:44 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: lack of version number field in SIP Date: Fri, 25 Sep 1992 19:15:34 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep25.191544pdt.10779@skylark.parc.xerox.com> Garret Wollman wrote: > As a practical matter, any protocol which wants to be the successor to > IP *must* operate over DIX Ethernet V2.0. Preferably, it would have > the same Ether codepoint, and have a four-bit field up front > indicating IP version 7. SIP does operate over DIX Ethernet. It uses ethertype 86DD, newly acquired for this purpose. Several people have expressed the opinion that SIP should have a version number, identifying it as IP version 7. Now, as far as I can tell, the only function served by the IP version field is to prevent a system from acting on a packet whose syntax it does not understand. There's no "version negotiation" mechanism or anything like that, that would allow systems to do anything intelligent in response to a version mismatch between a sender and a receiver. Since it is already necessary for systems to demultiplex packets based on the link-layer type code, and since that demultiplexing can also serve to separate SIP packets from IP packets, it seems to me an unnecessary waste of cycles to require systems to perform an additional test on a version field. (At least in IP, that test can be combined with a test for the absence of options; in SIP, no such economy of effort is possible, because there aren't any other "virtual constants" in the SIP header.) I'd like to understand precisely why people think a version field in SIP is a good idea. I can think of a couple reasons: (1) administrative: it would avoid the hassle of obtaining a new link-layer type code for every kind of link over which SIP might run; if it had a version field, it could just reuse the codes that identify IP. (Since we already have an ethertype assigned, that covers the majority of types of links in use today, including all 802.x links and anything else using LLC/SNAP encoding.) (2) marketing: people might be more likely to accept SIP if it were seen as a simple upgrade of IP, rather than an entirely new protocol. (Hmm, I wonder if ST has enjoyed any market success as IPv5? :-) ) Enough strawmen. If you favor a version field for SIP, please tell me why. Steve From owner-Big-Internet@munnari.oz.au Sun Sep 27 05:08:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09745; Sun, 27 Sep 1992 05:08:43 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09713; Sun, 27 Sep 1992 05:08:18 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11994>; Sat, 26 Sep 1992 12:07:40 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sat, 26 Sep 1992 12:07:35 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: size and alignment of Hop Limit field in SIP Date: Sat, 26 Sep 1992 12:07:21 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep26.120735pdt.10779@skylark.parc.xerox.com> Thanks to Frank Kastenholz, Jim Thompson, Craig Partridge, and Vernon Schryver for educating me about modern machine architecture. Frank is suggesting that: (1) the Hop Limit field be stored in the low-order end of a word (should it be the end of a 64-bit word, or will any 32-bit word do?) in order to exploit cheap decrementing capability, thus avoiding the fetch of a 32-bit subtrahend, and (2) the Hop Limit field be 16 bits wide, in order to exploit a 16->32 bit conversion instruction, thus avoiding the fetch of a 32-bit mask for the equal-to-zero check. Craig confirmed the relevance of (1). Regarding (2), wouldn't a processor that has a 16->32 bit conversion instruction also have a 8->32 bit conversion instruction? If I understood the private message I got from Jim, and the big-internet message from Vernon, none of this may matter anyway, because of caching effects? Also, the header layout proposed by Frank might help big-endian machines, but wouldn't help little-endian machines. Are most high-performance routers likely to be big-endian? (I can imagine that being the case, since most protocols are big-endian.) (Do these hot new RISC processors by any chance support a double-register shift instruction? If so, with a header in my format, on a big-endian machine you could do the following with the minimal 2 memory accesses: load 32-bit word of packet (Hop Limit + Payload Type + Payload Length) double-register shift left, so Hop Limit appears in a diff. register check Hop Limit register for zero (branch if true) decrement Hop Limit register check Hop Limit register for zero (branch if true) double-register shift right store 32-bit word of packet Do shifts on these machines cost one cycle per bit, or are they constant cost, independent of shift count? Feel free to answer privately, to avoid making the same mistake as I am making: cluttering the big-internet list with such low-level detail.) Steve From owner-Big-Internet@munnari.oz.au Sun Sep 27 06:16:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13402; Sun, 27 Sep 1992 06:16:20 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13393; Sun, 27 Sep 1992 06:16:09 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA02155; Sat, 26 Sep 92 13:15:56 -0700 Date: Sat, 26 Sep 92 14:39:13 EDT From: "William Allen Simpson" Message-Id: <760.bill.simpson@um.cc.umich.edu> To: Steve Deering Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: lack of version number field in SIP My daydream was that the new IP7 could run over old IP4 *and* OSI-style links without interfering with the old packets. That is, IP7 would be a successor to both Internet and OSI CLNP. Just a daydream, though. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Mon Sep 28 04:51:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08617; Mon, 28 Sep 1992 04:51:50 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08614; Mon, 28 Sep 1992 04:51:40 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12063>; Sun, 27 Sep 1992 11:51:19 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 27 Sep 1992 11:51:12 -0700 To: braden@isi.edu (Bob Braden) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP In-Reply-To: Your message of "Thu, 24 Sep 92 10:10:35 PDT." <199209241710.AA28812@zephyr.isi.edu> Date: Sun, 27 Sep 1992 11:51:08 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep27.115112pdt.10779@skylark.parc.xerox.com> > An aside on SIP: it sounds very nice to say that the transport > layer is responsible for enforcing MSL (and many of my friends > think it is Just and Righteous to do so), but note that this > implies increasing the size of the transport protocol sequence > space, either directly or else indirectly with an timestamp. > This increases the tranport header size; if you push on the > IP layer, it pops up elsewhere! Bob, If you insist on correct enforcement of maximum packet lifetime, you have to add bits *somewhere*; simply saying that the routers should do time-based TTL decrementing doesn't suffice, given that the hop between any two routers can have arbitrary and unpredictable delay (be it a hop across an X.25, Frame Relay, or SMDS cloud, another internet like DECnet, a MIME tunnel, or carrier pigeons). At the IP layer, you might add a timestamp to the IP header (or perhaps to a sublayer below IP only when traversing unknown-delay links), to be examined either at each hop or just at the destination. That would require synchronized clocks in all systems that either generate or verify the timestamps (and would require that those systems not forward or accept any traffic -- or at least any TCP traffic -- whenever their clocks are not sufficiently in sync, such as after a reboot). The alternative is to increase the transport protocol sequence space, which solves the problem without requiring synchronized clocks. That sounds preferable to me, especially given that, for TCP, the sequence space is being implicitly increased anyway, by the timestamp option (which does *not* require synchronized clocks). (I suppose the truly Just and Righteous way is to use a transport sequence space large enough to give a long wraparound time, covered by an encrypted checksum computed with keys that are changed at intervals smaller than the wraparound time. I.e., whatever you do to defend against replay attacks will also prevent misinterpretation of long-lived packets.) Steve From owner-Big-Internet@munnari.oz.au Mon Sep 28 07:53:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19275; Mon, 28 Sep 1992 07:53:44 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19270; Mon, 28 Sep 1992 07:53:31 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12077>; Sun, 27 Sep 1992 14:53:00 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 27 Sep 1992 14:52:50 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: lack of checksum field in SIP header Date: Sun, 27 Sep 1992 14:52:40 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep27.145250pdt.10779@skylark.parc.xerox.com> Quite a few people have balked at the notion of omitting an internet-layer header checksum. Here's my rationale for leaving it out of SIP: - Packet corruption ought to be very rare in the modern Internet, because: (a) link-layer CRCs provide stronger protection than the IP checksum against bit damage in transit over links (with the exception of SLIP links, which have no link-layer checksum, but SLIP won't be used for SIP, because SLIP is an IP-only link layer). (b) memories and communication interfaces on modern machines are very reliable (so much so that, for example, we don't feel the need to routinely append a checksum to the end of every file we store on disk). - End systems can protect themselves from acting upon a corrupted packet, if one should arrive, by use of an end-to-end checksum that includes the SIP header fields (excluding Hop Limit). (That is not the only way to it -- a transport protocol might have its own header fields that can be used in lieu of the SIP header fields. For example, a protocol that carries and checksums its own globally-unique transport-layer-entity identifiers does not need to verify the non-corruption of SIP addresses.) - The consequences for the intermediate systems and links of an undetected corruption of a SIP header are not fatal: - a corrupted Hop Limit allows a packet to live longer than desired, but that has no significant effect unless it occurs simultaneously with a non-transient routing loop. The probability of both occuring at the same time ought to be very small. - a corrupted Payload Type may result in (a) delivery of a packet to an incorrect transport layer in the destination system(s), but that would be detected by the transport checksum whose pseudo-header covers the Payload Type, or (b) a spurious "Payload Type Unknown" SIPC (ICMP) message, for a Payload Type that the sender never sent and that would, therefore, be ignored, or (c) the mistaken interpretation of the Payload Type as a router-significant type such as a source route, by an intermediate router, with consequences that depend on the particular type (and that can be defended against, if necessary, by type-specific mechanisms). - a corrupted Payload Length may result in (a) delivery of an incorrect length packet, which would be detected at the destination by the transport checksum, or (b) failure to deliver and the generation of a spurious "Packet Too Long" SIPC message, which would be harmless because it would report a correct MTU. - a corrupted Source Address may result in incomplete delivery of a multicast packet (wrong delivery tree chosen), or in delivery of a returned SIPC error message to the wrong source, neither of which is fatal, given the tolerance of SIP client protocols to packet loss. - a corrupted Destination Address may result in failure to deliver or in delivery to the wrong destination(s). The former is tolerated by SIP client protocols. The latter can be detected at the receiver(s) by the transport checksum; for applications sending sensitive data, end-to-end encryption protects against revealing packet contents to the wrong destination(s). - The cost of verifying and updating a header checksum at each hop is non-trivial, relative to the total number of instructions required for packet forwarding. Walt Prue said it best: "...I would rather take the risk of an occasional corrupted packet stealing some performance than penalize the billions and billions of packets that cross the backbone with more overhead to forward at each hop." Regarding Frank Solensky's concern that "the packet corruption may be such that it never gets to the real destination to have the transport layer checksum checked, or may be so hopelessly mangled that it causes routers between here and there to crash": - it doesn't matter if it never gets to the real destination, because if it did get to the real destination it would just be discarded anyway. - a router must be able to tolerate any pattern of bits in a packet without crashing; a checksum would not protect a router from naughty bits, because a buggy host might put random garbage in a packet and then compute a *correct* checksum across that garbage. Steve From owner-Big-Internet@munnari.oz.au Mon Sep 28 08:34:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20455; Mon, 28 Sep 1992 08:35:03 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20447; Mon, 28 Sep 1992 08:34:51 +1000 (from kre) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of Sun, 27 Sep 92 14:52:40 -0700. <92Sep27.145250pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 08:34:44 +1000 Message-Id: <7231.717633284@munnari.oz.au> From: Robert Elz Date: Sun, 27 Sep 1992 14:52:40 PDT From: Steve Deering Message-ID: <92Sep27.145250pdt.10779@skylark.parc.xerox.com> The only argument against the checksum seems to be ... Walt Prue said it best: "...I would rather take the risk of an occasional corrupted packet stealing some performance than penalize the billions and billions of packets that cross the backbone with more overhead to forward at each hop." The others are all just defences against "its needed because..." arguments. But this is specious - the existance of the checksum doesn't mean that the router has to check it if its convinced that doing so won't add anything useful. It does have to update it when changing header fields, but with a simplistic checksum (all that's needed really - like IPv4's) that's pretty easy to do (costs very very little, even less if you were to put the checksum near the part that is most often updated, so that you may be able to read/write both with one mem reference). On the other hand, if you omit the checksum there's no way that a router can tell a packet has been mangled should it want to (its designers know they have enough cpu time to do this while handling their forwarding at max rate). This means that the router can never generate sane diagnostics in the case of corrupted headers. I also remain unconvinced that the cost of a header checksum is really noticeable in any case, I certainly doubt that its ever going to come close to the cost of doing the rest of packet forwarding, however much that is optimised (even with PIP style headers). Obviously you can code it badly, but I assume that if you care about performance, you won't do that. kre From owner-Big-Internet@munnari.oz.au Mon Sep 28 09:21:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21861; Mon, 28 Sep 1992 09:21:55 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21854; Mon, 28 Sep 1992 09:21:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16801; Sun, 27 Sep 92 19:21:42 -0400 Date: Sun, 27 Sep 92 19:21:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209272321.AA16801@ginger.lcs.mit.edu> To: craig@aland.bbn.com, deering@parc.xerox.com Subject: Re: TOS in SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Not long-winded at all. Certainly more to the point than lots of what we've seen on the list. Gee, you wouldn't by any chance be referring to Noel-grams, would you? :-) I currently feel the port mapping idea has more long-term scaling problems than IDs with setup protocols and flow specs. Absolutely right. If you need some capability, sit down and figure out what it needs to do, design a mechanism to do it, and include it. Don't try and hammer some other thing into doing what you need; that *inevitably* brings engineering nightmares. Noel From owner-Big-Internet@munnari.oz.au Mon Sep 28 09:24:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21946; Mon, 28 Sep 1992 09:24:24 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21918; Mon, 28 Sep 1992 09:24:06 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12079>; Sun, 27 Sep 1992 16:23:47 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 27 Sep 1992 16:23:42 -0700 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of "Sun, 27 Sep 92 15:34:44 PDT." <7231.717633284@munnari.oz.au> Date: Sun, 27 Sep 1992 16:23:29 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep27.162342pdt.10779@skylark.parc.xerox.com> > The only argument against the checksum seems to be ... > ... > The others are all just defences against "its needed because..." > arguments. Thanks for clearing up my fuzzy logic, Robert. Yes, my rationale for omitting the checksum is that it is not needed and it has a cost. Besides the CPU cost mentioned by Walt, there is also a (possibly negligible, from some points-of-view) bandwidth cost of carrying the extra couple bytes in every packet, and there is a "complexity" cost (dismissed by many) of carrying around an inessential field, no matter how few resources it consumes. So the question of whether or not "it's needed" is the primary question, in my mind. I think you are saying that is is needed, for diagnostic purposes. I'm not immediately convinced of that (there may be adequate alternative ways of disgnosing packet corruption problems), but I certainly could be. You also suggest that the checksum should be present, but need not be validated (only updated) at every router. If you do that, the point at which you detect corruption may be far beyond the point at which the corruption occurred, such that the diagnostic function is considerably weakened -- might as well just leave it for the transport checksum to detect at the destination host. I certainly agree with you that the processing cost of only doing an update, not a validation, of an IP checksum is very small. > I also remain unconvinced that the cost of a header checksum > is really noticeable in any case, I certainly doubt that its > ever going to come close to the cost of doing the rest of > packet forwarding, however much that is optimised (even with > PIP style headers). Obviously you can code it badly, but > I assume that if you care about performance, you won't do that. The first time I encountered the notion that it might be OK not to validate the IP header checksum on every hop was in some notes from Van Jacobson for a tutorial on high-speed protocol implementation. His IP forwarding code did exactly what you suggest: it updated the checksum, but it did not bother to validate it. I presume he did that because he considered the cost of validation to be too high, no matter how efficiently it could have been coded. (Or maybe he was just going for the world-record smallest number of instructions to forward IP.) I don't know whether or not he would have omitted the checksum altogether, if that had been possible. Steve From owner-Big-Internet@munnari.oz.au Mon Sep 28 09:31:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22176; Mon, 28 Sep 1992 09:31:48 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22164; Mon, 28 Sep 1992 09:31:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16839; Sun, 27 Sep 92 19:31:35 -0400 Date: Sun, 27 Sep 92 19:31:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209272331.AA16839@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: size and alignment of Hop Limit field in SIP Cc: jnc@ginger.lcs.mit.edu Thanks to ... for educating me about modern machine architecture. That sentence managed to scare the piss right out of me. Do people really *seriously* think that the current round of machine architectures will still be around for the lifetime of the replacment for IP-4? When we did that, the Vax was a gleam in Dec's eye, and the LSI-11 was just starting to come into service as the generic small machine. Well, Vaxes are on their way *out*, LSI-11's are on the scrap heap, and IP-4 is still around. Bet you the replacement lasts longer than that. *Think Long-Term!* The replacement for IP-4 is going to be around for a *minimum* of 20 years.... the Hop Limit field be stored in the low-order end of a word I was too busy (and astonished) to go ballistic about this when the debate as to whether this was wide enough happened, but I was utterly, completely, absolutely and totally dumbfounded to hear a serious proposal to use an 8 bit hop count field. Words fail me.... 16 is *probably* enough, but anything shorter is, well, words fail me... Noel From owner-Big-Internet@munnari.oz.au Mon Sep 28 09:37:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22377; Mon, 28 Sep 1992 09:37:12 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22368; Mon, 28 Sep 1992 09:37:03 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12080>; Sun, 27 Sep 1992 16:36:38 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 27 Sep 1992 16:36:29 -0700 To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP In-Reply-To: Your message of "Wed, 23 Sep 92 18:16:37 PDT." <747.bill.simpson@um.cc.umich.edu> Date: Sun, 27 Sep 1992 16:36:19 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep27.163629pdt.10779@skylark.parc.xerox.com> > And wouldn't it be more logical to have the Destination before the Source? Why? Steve From owner-Big-Internet@munnari.oz.au Mon Sep 28 09:53:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23015; Mon, 28 Sep 1992 09:54:02 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23008; Mon, 28 Sep 1992 09:53:44 +1000 (from kre) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of Sun, 27 Sep 92 16:23:29 -0700. <92Sep27.162342pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 09:53:37 +1000 Message-Id: <7266.717638017@munnari.oz.au> From: Robert Elz Date: Sun, 27 Sep 1992 16:23:29 PDT From: Steve Deering Message-ID: <92Sep27.162342pdt.10779@skylark.parc.xerox.com> So the question of whether or not "it's needed" is the primary question, in my mind. I agree with this, provided that you accept that the answer isn't an absolute - that is, the question is how much its needed, not yes or no. I think you are saying that is is needed, for diagnostic purposes. Not quite that - though while implementations are being developed anything that can help find bugs in others implementations (local implementations only have features) can be useful. What I really meant was that without verification of the header you can get spurious diagnostics generated, which can lead to much wasted effort looking for a problem that doesn't really exist (instead of the real problem). Or, once the possibility of header corruption becomes known as a possible source of problems, there will be the temptation to ignore initial problem reports because they're "probably spurious". I'm not so concerned with where a problem is diagnosed, as that when it is diagnosed a sensible error report is generated. That might mean that routers wouldn't bother verifying the checksum on the normal forwarding path, but would before returning an ICMP equivalent, to make sure that the problem they are diagnosing makes sense. His [VJ's] IP forwarding code did exactly what you suggest: it updated the checksum, but it did not bother to validate it. I presume he did that because he considered the cost of validation to be too high, no matter how efficiently it could have been coded. On the processor on which he was coding it - that may very well have been the case, I believe most of Van's routing has been done on suns (like 3/50's and such originally) where you probably don't want to waste any more time that necessary - the processor always has something else it can be doing when not routing packets. A dedicated router with a modern high speed processor may not have the same problems - its probably going to have enough registers (or implement its forwarding path in hardware or micro code) that it can load the entire header into registers, then run everything from there - the checksum calculation probably won't be a problem (could intersperse the additions while waiting for cache responses to forwarding table lookups or something). The point is that if the field is there, the implementor can decide whether to make use of it or not - if its not, that possibility is denied. The question them becomes more of whether the benefits of the checksum outweigh the cost of including it in the packets (packet length grows), and the bit about complexity, which in the case of the header checksum I don't think does a lot. Personally I think it does. kre From owner-Big-Internet@munnari.oz.au Mon Sep 28 11:02:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25115; Mon, 28 Sep 1992 11:03:07 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25093; Mon, 28 Sep 1992 11:02:44 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12082>; Sun, 27 Sep 1992 18:02:13 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 27 Sep 1992 18:02:02 -0700 To: Craig Partridge Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: TOS in SIP In-Reply-To: Your message of "Fri, 25 Sep 92 19:08:30 PDT." <9209260208.AA16800@aland.bbn.com> Date: Sun, 27 Sep 1992 18:01:48 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep27.180202pdt.10779@skylark.parc.xerox.com> Craig says: > In general, I don't like arguing about which O(1) algorithm is better than > another, but it seems to me that buying into this scheme means that the > amount of header I have to pull into registers and do pattern matching on > is variable, yes? Would it not be nicer, and simpler, to have an ID in > a fixed place? Yes, the amount of header you might have to examine is variable. Yes, it would be nicer and simpler to have an ID in a fixed place. If you can tell me exactly what the format and semantics of that ID should be, and if you can find a critical mass of other experts working on this problem to agree that it's good enough for the next 15 years, or until ATM replaces the Internet, whichever comes first, then I'll gladly add it to the SIP header. Here's a strawman, to show the kind of thing I'm looking for: The following 32 bits are included in the SIP header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Pref. | Flow ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service Preference 8-bit value specifying a desired type of delivery service: 0 - no preference 1 - minimal delay 2 - maximal throughput 3 - minimal packet loss 4 - minimal expense 5-255 - reserved (This is just like Type of Service in IP. The name is changed to "Service Preference" and the words "minimal" and "maximal" are used to discourage the misinterpretation of this field as a "strict TOS".) (It is expected that interactive traffic like telnet and the X Window Protocol will request minimal delay; human-attended file transfers like FTP will request maximal throughput; and non-attended transfers like email and netnews will express no preference. Real-time traffic, like audio and video may request minimal delay, but are also expected to set up a flow reservation, and to use the Flow-ID field to identify a specific flow service descriptor in the routers along the delivery path or tree.) Flow ID 24-bit value that, when appended to the SIP Source Address, identifies a flow service descriptor that should have been previously installed in the routers along this packet's delivery path or tree. Flow ID zero is used for packets that are not associated with any flow service descriptor. When a packet with a non-zero Flow ID arrives at a router that does not have a corresponding flow service descriptor, that event may trigger a flow repair protocol (TBD). The packet is not dropped, however, but is forwarded onward according to its Service Preference. Craig goes on to say: > I think this is an odd spin on things. If Frank can convince you in person > to support the Frank protocol, why can't he do it via a setup request? > (Maybe Frank goes to the IETF and gets a signed certificate he includes in > the setup request saying "this is OK"). First, I should emphasize that it is someone else's spin I was (no doubt inaccurately) reporting. I assume we want to support some kinds of non-default service that do not require a setup request. For example, we might agree that it's a good thing to give telnet preferential queueing, without requiring telnet sessions to be preceded by a setup request. However, we wouldn't agree to let any old packet, such as a Frank Protocol packet, to just say "treat me the same way as telnet packets". *Either* a Frank session would have to be preceded by a setup, *or* Frank convinces lots of network admins to tell their routers to give Frank Protocol packets special treatment without a dynamic setup. Now, I'm not entirely convinced by this argument, myself. The nice thing about the IP TOS field (in contrast to Precedence field, say), is that when a source asks for "minimal delay", it is implicitly indicating that it is willing to get poorer throughput or lower reliability. Thus it is not always a clear win to set the low-delay TOS, and if you assume that the default TOS is the best compromise among the delay/throughput/ reliability performance measures, there is a disincentive to setting the low-delay TOS unless low delay really is your most important service goal, for which you are willing to sacrifice throughput and reliability. So, by this line of argument, it's OK for both telnet and the Frank Protocol to just set the minimal-delay TOS, and there's no need to look at the ports to decide how to treat them. (IP Precedence, on the other hand, doesn't seem to make any sense without a certificate in the same packet, proving that the sender is authorized to be treated according to the specified precedence. Otherwise, everyone would simply specify the highest precedence.) > More generally, my concern is about proper number space management. I > already argued that the special port space will become huge if we have to > give every guaranteed protocol its own port. No, you misunderstood. Well-known ports would not be used to identify service *guarantees*, but rather certain *classes* of service. For example, both port 23 (telnet) and port 999 (Frank) might be mapped to the "interactive" class. The well-known port space will only grow with the actual number of well-known applications, as is currently the case. If a particular telnet session required a service *guarantee*, a setup protocol would first be invoked, creating a mapping from (src addr, dest addr, payload type, src port, dst port) to the appropriate state in all of the routers along the session's path, in order to assure the guarantee. > Mind you, I'm not fixed in my views -- however, I currently feel the > port mapping idea has more long-term scaling problems than IDs with > setup protocols and flow specs. Even if we have IDs with setup protocols and flow specs, I think we still want to be able to provide non-default (but not guaranteed!) quality-of-service to applications that do NOT engage in a setup protocol. If not, aren't you basically suggesting that everything except email and netnews should be preceded by a setup request? Steve From owner-Big-Internet@munnari.oz.au Mon Sep 28 11:15:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25605; Mon, 28 Sep 1992 11:15:45 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25588; Mon, 28 Sep 1992 11:15:21 +1000 (from craig@aland.bbn.com) Received: from port37.sc.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA17073; Sun, 27 Sep 92 21:14:54 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA24959; Sun, 27 Sep 92 18:13:45 PDT Message-Id: <9209280113.AA24959@aland.bbn.com> To: Steve Deering Cc: Craig Partridge , big-internet@munnari.oz.au Subject: Re: TOS in SIP In-Reply-To: Your message of Sun, 27 Sep 92 18:01:48 -0700. <92Sep27.180202pdt.10779@skylark.parc.xerox.com> From: Craig Partridge Date: Sun, 27 Sep 92 18:13:45 -0700 Sender: craig@aland.bbn.com > If not, aren't you basically suggesting that everything > except email and netnews should be preceded by a setup request? Steve: Well, given that nothing gets a setup request now, I'm not sure we need to retrofit them. Let them just use SIP as they use IP now. If you must allow FTP to make bandwidth requests, there are at least two options with an ID scheme: * require them to do a setup (perhaps in parallel with transmitting -- so start sending and negotiate on the side) * have a few generic flow IDs that identify a class. This works well for things like telnet, where the class is 0 bandwidth required but minimize delay if possible and if all telnet datagrams get queued together under these constraints we're happy. It may work for FTP, depending on what type of service you think a request for best possible bandwidth might get handled. Craig From owner-Big-Internet@munnari.oz.au Mon Sep 28 11:34:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26373; Mon, 28 Sep 1992 11:34:35 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26370; Mon, 28 Sep 1992 11:34:25 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12080>; Sun, 27 Sep 1992 18:34:16 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 27 Sep 1992 18:34:07 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Sun, 27 Sep 92 16:31:35 PDT." <9209272331.AA16839@ginger.lcs.mit.edu> Date: Sun, 27 Sep 1992 18:33:55 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep27.183407pdt.10779@skylark.parc.xerox.com> > Thanks to ... for educating me about modern machine architecture. > > That sentence managed to scare the piss right out of me. Do people really > *seriously* think that the current round of machine architectures will still > be around for the lifetime of the replacment for IP-4? Obviously not. But the best we can do is try to avoid doing anything that is problematical on those machines that are being designed now, or on those machines that might be obvious extrapolations of the newest designs. For that, it helps to get educated on the current state of the art. Do you think that understanding of machine architecture is irrelevant for a protocol designer? > I was too busy (and astonished) to go ballistic about this when the debate as > to whether this was wide enough happened, but I was utterly, completely, > absolutely and totally dumbfounded to hear a serious proposal to use an 8 bit > hop count field. Words fail me.... 16 is *probably* enough, ...but anything > shorter is, well, words fail me... Much as I am delighted to see you dumbstruck, I wish you would try to present a non-emotional argument as to why a solar-system-wide Internet ought to have or must have a diameter greater than 255 hops. Bear in mind that packets that start off with a Hop Limit of 65,000 might consume 65,000 times their normal resources whenever they happen to get stuck in a routing loop. Steve From owner-Big-Internet@munnari.oz.au Mon Sep 28 18:15:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12892; Mon, 28 Sep 1992 18:15:51 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209280815.12892@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12889; Mon, 28 Sep 1992 18:15:44 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Sep 1992 09:15:27 +0100 To: Steve Deering Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Sun, 27 Sep 92 18:33:55 PDT." <92Sep27.183407pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 09:15:25 +0100 From: Jon Crowcroft >> *seriously* think that the current round of machine architectures will still >> be around for the lifetime of the replacment for IP-4? >> hop count field. Words fail me.... 16 is *probably* enough, ...but anything >> shorter is, well, words fail me... >Much as I am delighted to see you dumbstruck, I wish you would try to >present a non-emotional argument as to why a solar-system-wide Internet >ought to have or must have a diameter greater than 255 hops. Bear in >mind that packets that start off with a Hop Limit of 65,000 might also note that planning for 64 bit architectures is probably fairly safe in the face of 20 years (order 16 bit was safe for around 20 years, and 32 for 10, but the logistics say that it isnt an expontnetial from 16->32->64->128 in five just doesnt make much sense...here i am sticking my neck out about 7 light seconds:-) jon From owner-Big-Internet@munnari.oz.au Mon Sep 28 18:57:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14337; Mon, 28 Sep 1992 18:57:31 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14326; Mon, 28 Sep 1992 18:57:22 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA04889; Mon, 28 Sep 1992 09:57:27 +0100 Message-Id: <199209280857.AA04889@mitsou.inria.fr> To: Steve Deering Cc: kasten@ftp.com (Frank Kastenholz), big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of "Wed, 23 Sep 92 12:03:44 PDT." <92Sep23.120347pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 09:57:26 -0500 From: Christian Huitema X-Mts: smtp > - Regarding keeping the Payload Length at 16 bits, if a particular > system or subnetwork can't amortize the fixed costs of handling a > packet over 65,000 bytes, then I suggest that that system or > subnetwork needs to be fixed. At a gigabit, the maximum arrival > rate of 64KB packets is one every 500 microseconds. Are you suggesting > that systems or subnetworks capable of operating at a gigabit > shouldn't be deemed capable of handling 2000 packet events per second? There are two candidates now for Gbps nets: ATM and HIPPI. The IP > HIPPI draft specifies a max packet length of 64k. Given the "uncertainty" about ATM quality of service and cell level congestion avoidance, I would not dream of sending a packet that is built of more than 1000 cells. The 64k limit is probably realistic. Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Sep 28 22:39:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22154; Mon, 28 Sep 1992 22:39:36 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22151; Mon, 28 Sep 1992 22:39:26 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA22054 (5.65b/CWI-2.177); Mon, 28 Sep 1992 13:39:14 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA12839; Mon, 28 Sep 92 13:39:36 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA20969; Mon, 28 Sep 92 13:39:03 +0100 Message-Id: <9209281239.AA20969@dxcern.cern.ch> Subject: Re: SIP / 64 k limit To: big-internet@munnari.oz.au Date: Mon, 28 Sep 92 13:39:02 MET From: Brian Carpenter CERN-CN In-Reply-To: <199209280857.AA04889@mitsou.inria.fr>; from "Christian Huitema" at Sep 28, 92 9:57 am X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Christian Huitema follows: > > > - Regarding keeping the Payload Length at 16 bits, if a particular > > system or subnetwork can't amortize the fixed costs of handling a > > packet over 65,000 bytes, then I suggest that that system or > > subnetwork needs to be fixed. At a gigabit, the maximum arrival > > rate of 64KB packets is one every 500 microseconds. Are you suggesting > > that systems or subnetworks capable of operating at a gigabit > > shouldn't be deemed capable of handling 2000 packet events per second? > > There are two candidates now for Gbps nets: ATM and HIPPI. The IP > HIPPI > draft specifies a max packet length of 64k. Given the "uncertainty" about > ATM quality of service and cell level congestion avoidance, I would not > dream of sending a packet that is built of more than 1000 cells. The 64k > limit is probably realistic. > Christian, Fibre Channel is also a Gbit candidate and there will be others. The IP/FC, IP/HIPPI, and IP/ATM drafts share the 64 k limit (in the ATM case because it is imposed by Adaptation Layer 5). I personally strongly deprecate this limit because (if you follow the arguments either of Ultranet or of Dave Clark) the lower layers should not make fragmentation of application PDUs inevitable. It may well be that specific technologies mean that going above 64k is a bad trade-off but this should not be pre-judged by the standardisers. So I think that all the various new IPs should allow for 2**32-1 bytes, whether or not we use it. By the way there is another argument _against_ megapackets: they increase the effective round-trip time (since the real time to transmit the packet over each hop adds to the RTT). This makes the long fat network problem worse. (This was pointed out by Van Jacobson.) And of course where megapackets share a line with real time traffic you have to be sure that the real time doesn't suffer. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.oz.au Mon Sep 28 22:54:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22554; Mon, 28 Sep 1992 22:54:17 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22543; Mon, 28 Sep 1992 22:54:00 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA05100; Mon, 28 Sep 1992 13:54:51 +0100 Message-Id: <199209281254.AA05100@mitsou.inria.fr> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Sun, 27 Sep 92 18:33:55 PDT." <92Sep27.183407pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 13:54:50 -0500 From: Christian Huitema X-Mts: smtp Steve, The experiences we made here with marshalling algorithms (BER, XDR, etc) showed us that simply counting the instructions can be really misleading with RISC machines. The real bottleneck is much more memory accesses -- loading data in the cache -- than actual instructions. I guess that if the header manipulations can be coded with simple shifts and unit increase/decrease instructions, then you are OK. Consider also that "programs" will be in the cache, at least for the switches, has these instructions will be used for several packets. Packets themselve will not. Dont make them any longer than necessary, dont expand a field on several world if it can be encoded in one. Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Sep 28 23:15:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23110; Mon, 28 Sep 1992 23:15:34 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23093; Mon, 28 Sep 1992 23:15:07 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA05130; Mon, 28 Sep 1992 14:14:07 +0100 Message-Id: <199209281314.AA05130@mitsou.inria.fr> To: Craig Partridge Cc: Steve Deering , big-internet@munnari.oz.au Subject: Re: TOS in SIP In-Reply-To: Your message of "Sun, 27 Sep 92 18:13:45 MST." <9209280113.AA24959@aland.bbn.com> Date: Mon, 28 Sep 92 14:14:06 -0500 From: Christian Huitema X-Mts: smtp > * require them to do a setup (perhaps in parallel with transmitting -- > so start sending and negotiate on the side) I have the feeling that in most cases you dont want to do a set up, or at least that you dont want to completely fix the path. What you want to do, e.g. for a videoconference, is to use the "standard" service wherever it is OK, and to make sure that you get enough resources on the bottleneck, e.g. at least 128 kbps on transat link #31. A consequence is that it should be allowed to identify a flow even if no resource has been reserved -- no ICMP "flow-id unknown" packets, please! > * have a few generic flow IDs that identify a class. This works well > for things like telnet, where the class is 0 bandwidth required but > minimize delay if possible and if all telnet datagrams get queued together > under these constraints we're happy. It may work for FTP, depending > on what type of service you think a request for best possible bandwidth > might get handled. There is one thing we may want to do with this class-id, i.e. to identify the congestion control algorithm used by the end-to-end entity. If you suppose a general requirement that hosts implement some form of end to end congestion control, you may come out broadly speaking with 2 big classes: * Those which try to fill up the pipe in order to avoid silences and guarantee the best throughput (e.g. slow start + CA), * Those which try to maintain the pipe "almost empty" in order to avoid the building of queues and guarantee the best response time. When transmitting "real time" signal, one is bound to use the second category of algorithm, e.g. by monitoring the transmission delay or the inter-packet arrival time and tuning the analog-digital codec parameters (frequency, quantization) accordingly. One is also bound to fail miserably if the audio and video packets are placed in the same queue as the FTP packets. On the other hand, it runs pretty smoothly if some amount of resource is admninistratively reserved for "the real time class" + if some level of "fair queuing" is enforced within this class. Christian Huitema From owner-Big-Internet@munnari.oz.au Tue Sep 29 00:38:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25930; Tue, 29 Sep 1992 00:38:42 +1000 (from owner-Big-Internet) Return-Path: Received: from fncent.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25927; Tue, 29 Sep 1992 00:38:35 +1000 (from crawdad@fncent.fnal.gov) Received: from localhost.fnal.gov by fncent.fnal.gov with SMTP id AA00727 (5.65c+/IDA-1.4.4 for big-internet@munnari.oz.au); Mon, 28 Sep 1992 09:35:50 -0500 Message-Id: <199209281435.AA00727@fncent.fnal.gov> To: big-internet@munnari.oz.au Subject: Re: SIP / 64 k limit In-Reply-To: Your message of Mon, 28 Sep 92 13:39:02 +0700. <9209281239.AA20969@dxcern.cern.ch> Date: Mon, 28 Sep 92 09:35:50 -0500 From: Matt Crawford > By the way there is another argument _against_ megapackets: they > increase the effective round-trip time (since the real time > to transmit the packet over each hop adds to the RTT). This makes the > long fat network problem worse. (This was pointed out by Van Jacobson.) This is also an argument in favor of keeping every bit the routers need to look at at the head of the packet, not at the end. That way, on-the-fly switching is not inherently precluded. _________________________________________________________ Matt Crawford crawdad@fncent.fnal.gov Fermilab From owner-Big-Internet@munnari.oz.au Tue Sep 29 01:13:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26999; Tue, 29 Sep 1992 01:13:15 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26996; Tue, 29 Sep 1992 01:13:08 +1000 (from kasten@ftp.com) Received: by ftp.com id AA20193; Mon, 28 Sep 92 11:12:49 -0400 Date: Mon, 28 Sep 92 11:12:49 -0400 Message-Id: <9209281512.AA20193@ftp.com> To: deering@parc.xerox.com Subject: Re: size and alignment of Hop Limit field in SIP From: kasten@ftp.com (Frank Kastenholz) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au > > I was too busy (and astonished) to go ballistic about this when the debate as > > to whether this was wide enough happened, but I was utterly, completely, > > absolutely and totally dumbfounded to hear a serious proposal to use an 8 bit > > hop count field. Words fail me.... 16 is *probably* enough, ...but anything > > shorter is, well, words fail me... > > Much as I am delighted to see you dumbstruck, I wish you would try to > present a non-emotional argument as to why a solar-system-wide Internet > ought to have or must have a diameter greater than 255 hops. Bear in > mind that packets that start off with a Hop Limit of 65,000 might > consume 65,000 times their normal resources whenever they happen to > get stuck in a routing loop. The original IP address had one format -- what we call class A. One byte of network number (there'll never be more than 256 networks in the world) and 3 bytes of host (those networks will all be big huge wan-type arpanet-like networks, directly connecting lots and lots and lots of hosts in a single large mesh). The moral of the story is that we have been remarkably bad at predicting the growth of the Internet. We know it will grow. We do not know how bit it will grow, nor do we know which direction it will grow in nor do we know how it will grow in that direction (nor do we even know what we mean by grow). Those extra 8 bits of network diameter might be real real useful. If we are worried about routing loops with TTL=65k, we could make the 8 bits a MBZ field and allocate the TTL bits out of it as needed or we could administratively say that max TTL must be less than X, where X is some nice number. (I'd prefer the MBZ field because if we assume that we will need TTL bits, we will find out that we will need something else). Not a very objective, technical, non-emotional argument... -- frank kastenholz From owner-Big-Internet@munnari.oz.au Tue Sep 29 02:26:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29825; Tue, 29 Sep 1992 02:26:31 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29819; Tue, 29 Sep 1992 02:26:15 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25599; Mon, 28 Sep 92 12:26:01 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA27812; Mon, 28 Sep 92 09:24:57 PDT Message-Id: <9209281624.AA27812@aland.bbn.com> To: big-internet@munnari.oz.au Subject: SIP: packet sizes Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 28 Sep 92 09:24:57 -0700 Sender: craig@aland.bbn.com Hi folks: I think the list of available technologies for gigabits will be pretty big. We have ATM, HiPPI, and FiberChannel now in the market, with WDM, variable length switches (PLANET and ATOMIC), and datagram rings (ODU ring, FDDI Follow-On) being developed in various research or standards projects. I suspect 64Kbytes is just fine for all of them. A second question is whether moby-grams will affect RTTs and interfere with real-time streams. One way to compute the datagram size at which things are problematic is the following: * determine the maximum number of hops (H) our real-time stream will traverse. (Without much justification, let's say H is 30). * figure out the time sensitivity of our applications. For example, let's assume that we're sensitive to changes greater than 10 ms. * figure out the minimum bandwidth we'll permit each path to have. just for fun, let's try bandwidths of 1 gigabit and 1.5 megabits. Now assume that a real-time packet is traversing a maximum length path, with the minimum acceptable bandwidth, and at each hop, it arrives just as the first bit of a low-priority packet starts going out, and the real-time packet must wait for the low-priority packet to complete sending before the real-time packet may be transmitted. Then the maximum packet size we should permit is approximately the size such that real-time packet gets delayed by the low-priority packets by no more than our time sensitivity. Eg: time delayed = ((max pkt size) * H )/bandwidth or max pkt size = (time delayed * bandwidth)/H At a gigabit, with the 10 ms sensitivity as our time delayed, the max packet size is about 40 Kbytes. At T1, the max packet size is about 60 bytes... These are merely points. One can play with longer delays -- 10 ms is rather low, or more hops (30 may be a bit low). But it suggests that 64 Kbytes is probably plenty large through a gigabit. Terabit networkers may feel we chose a bit small. Craig PS: These same calculations illustrate why many folks feel the ATM cell size is far too conservatively small for high-speed networks, and illustrate (with the T1 rates) that the ATM cell size was chosen, in part, with current, not future bandwidths, in mind. From owner-Big-Internet@munnari.oz.au Tue Sep 29 02:28:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29957; Tue, 29 Sep 1992 02:28:34 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29952; Tue, 29 Sep 1992 02:28:27 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA05518; Mon, 28 Sep 1992 17:29:05 +0100 Message-Id: <199209281629.AA05518@mitsou.inria.fr> To: Brian Carpenter CERN-CN Cc: big-internet@munnari.oz.au Subject: Re: SIP / 64 k limit In-Reply-To: Your message of "Mon, 28 Sep 92 13:39:02 +0700." <9209281239.AA20969@dxcern.cern.ch> Date: Mon, 28 Sep 92 17:29:04 -0500 From: Christian Huitema X-Mts: smtp Brian, We certainly differ on this. Fragmentation of PDU is inevitable if you want to assign an MTU; there has to be some limit. Rationales for the limit are reliability (packet error rate rises exponentially with packet length), response time (the queuing effect you mention, used to justify the 256 limit on SLIP, also used to justify the 48 byte size of ATM by the telephonists), and also memory management (e.g. the 256k, or 100k, or 2 M limits often encountered in mail networks). What is generally considered a bad idea is to have several layers of fragmentation, e.g. fragment both at TCP and IP layers. Indeed, the ATM true believers will push the reasoning to the point that, as ATM "allows" you (in fact, forces you) to fragment at the cell level, then you shall have ATM cells end to end, and no other layers of fragmentation. But the glow of ATM seems to have already started to fade, so I wont insist there. There is one strong point in your argument, though. If we note that the current limit is 64k, today, for FC, HIPPI and ATM, and that we want to build for 20 years, then we may realize that building todays maximum into tomorrows protocol is perhaps not the best possible idea... Christian Huitema From owner-Big-Internet@munnari.oz.au Tue Sep 29 03:06:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01229; Tue, 29 Sep 1992 03:06:06 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01218; Tue, 29 Sep 1992 03:06:00 +1000 (from prue@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-8) id ; Mon, 28 Sep 1992 10:05:15 -0700 Date: Mon, 28 Sep 1992 10:05:15 -0700 From: prue@ISI.EDU (Walter Prue) Message-Id: <199209281705.AA20952@zephyr.isi.edu> To: deering@parc.xerox.com Subject: Re: SIP Cc: big-internet@munnari.oz.au Steve, >> And wouldn't it be more logical to have the Destination before the Source? > >Why? I don't know if anyone does it today but it would be possible between speed matched data links to passthrough route packets as soon as the destination address is received. That is, as soon as you know, to where the packet is destined, start to clock the data out the appropriate data link well before the end of the packet is received. Walt From owner-Big-Internet@munnari.oz.au Tue Sep 29 03:20:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01651; Tue, 29 Sep 1992 03:20:30 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209281720.1651@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01644; Tue, 29 Sep 1992 03:20:20 +1000 (from kwe@BBN.COM) From: "Kent W. England" Subject: Re: Request for Bibliography of IPv7 / Big Internet Documents To: bill@wizard.gsfc.nasa.gov Cc: big-internet@munnari.oz.au, kwe:; Date: Mon, 28 Sep 92 13:18:44 EDT Mail-System-Version: Bill; It doesn't look like ROAD will be published. You could look at the report to the San Diego IETF from Peter Ford and Phill Gross. I think it is the Proceedings of the 23rd IETF (just after Santa Fe). Also refer to the upcoming ID called "IESG Deliberations ..." from Phill Gross that was also sent to big-internet on 17 Jun 92 in draft form. Also see draft-rekhter-ipaddress-guide-0n.txt for guidelines that accompany CIDR. Then there is EIP, 2tier, and Ullmann version 7. I don't know where these are going, or if they will be defended in Nov. EIP; Wang; "The Extended Internet Protocol"; on munnari.oz.au: big-internet/eip.txt 2tier; Wang & Crowcroft; "A Two Tier Address Structure ..."; RFC1335.txt Uv7; Ullmann; "TCP/IP: Internet Version 7"; ID:draft-ullmann-ipv7-00.txt You could also read some background: TTF; Clark; "Toward the Future Internet Architecture"; RFC1287.txt Growth; Lottor; "Internet Growth (1981 - 1991)"; RFC1296.txt IESG; Gross; "IESG Deliberations ..."; soon to be an ID (sez Phill). --Kent From owner-Big-Internet@munnari.oz.au Tue Sep 29 03:23:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01739; Tue, 29 Sep 1992 03:23:54 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01719; Tue, 29 Sep 1992 03:23:29 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA00717; Mon, 28 Sep 92 13:23:00 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA27921; Mon, 28 Sep 92 10:22:00 PDT Message-Id: <9209281722.AA27921@aland.bbn.com> To: big-internet@munnari.oz.au Subject: ISO letter From: Craig Partridge Date: Mon, 28 Sep 92 10:22:00 -0700 Sender: craig@aland.bbn.com Hi folks -- thought this might be of interest. I understand that the original posting was redistributed with Lyman's permission. Craig E-mail: craig@aland.bbn.com or craig@bbn.com ------- Forwarded Message Received: from Sun.COM by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28477; Mon, 28 Sep 92 12:58:17 -0400 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA23617; Mon, 28 Sep 92 09:53:01 PDT Received: from sunroof.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA27481; Mon, 28 Sep 92 09:53:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.Eng.Sun.COM (4.1/SMI-4.1) id AA27710; Mon, 28 Sep 92 09:52:44 PDT Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1/SMI-4.1) id AA28788; Mon, 28 Sep 92 09:52:51 PDT Received: from Mordor.Stanford.EDU by Sun.COM (4.1/SMI-4.1) id AA23534; Mon, 28 Sep 92 09:52:23 PDT Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA28807; Mon, 28 Sep 92 09:52:21 -0700 Message-Id: <9209281652.AA28807@Mordor.Stanford.EDU> To: ip-encaps@sunroof.Eng.Sun.COM Subject: ISO missive Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Mon, 28 Sep 92 09:52:21 -0700 >From: Dave Crocker X-Mts: smtp FYI. Dave - ------- Forwarded Messages Date: Fri, 25 Sep 92 09:35:44 EDT To: iab@venera.isi.edu, iesg@NRI.Reston.VA.US >From: Lyman Chapin Subject: Contribution from ISO This liaison contribution was approved by ISO/IEC JTC1/SC6 (the group that is responsible for lower layer (Transport and below) standards for OSI) at its last meeting (in July 1992). The two attachments (the second editions of CLNP and the Network service definition) are, for the time being, available only on paper (but, because they are attached to this liaison contribution, can be freely distributed by the IAB and its various constituent organizations, such as the IETF). I will mail the paper version, including the two attachments, to the IAB and IESG members after I receive the "official" cover page from the SC6 secretariat. - - - Lyman ========================================================================== Title: Liaison Contribution to the Internet Architecture Board (IAB) Concerning Future Work on ISO/IEC 8473 (CLNP) and Network Layer Addressing Source: ISO/IEC JTC1/SC6 (Telecommunications and Information Exchange Between Systems) Project(s): JTC1.06.32.04 and JTC1.06.32.01.02 Attachment(s): ISO/IEC JTC 1/SC 6/N xxxx, "Protocol for Providing the Connectionless-mode Network Service" (ISO/IEC 8473-1992, second edition) ISO/IEC JTC 1/SC 6/N 7558, "Network Service Definition" (ISO/IEC 8348-1992, second edition) During its meeting in San Diego on 13-24 July 1992, ISO/IEC JTC 1/SC 6 received and reviewed a report of current activities within the purview of the Internet Architecture Board (IAB) and its Internet Engineering Task Force (IETF) concerning the way in which the OSI standard internetwork protocol (ISO/IEC 8473, also referred to as "CLNP") and the corresponding OSI standard Network layer addressing scheme (ISO/IEC 8348 Addendum 2, also referred to as "NSAPs") might be used within the Internet. Recognizing the importance of the Internet to its National Body constituents, and therefore the importance of the IAB and IETF activities with respect to these OSI standards, and considering the desire and intention of JTC1 to establish an effective liaison relationship with the Internet Society through the IAB, SC6 wishes to convey the following information to the IAB, and would welcome suggestions from the IAB of areas in which it believes that active liaison with SC6 would be beneficial. 1. SC6 is aware of and interested in the IAB's work on routing and addressing in the Internet, and on the incorporation of ISO/IEC 8473 (CLNP) into the Internet as part of a multiprotocol Internet architecture. 2. SC6 is also aware of the possibility that the opportunity might arise, during the course of this work, for SC6 to take actions that would facilitate it. 3. SC6 would, in such a circumstance, be prepared to work constructively with the IAB, in a timely fashion, to facilitate its work, and in particular is willing to seriously consider any proposal from the IAB for additions or amendments to the relevant ISO/IEC standards that might be required to permit the effective application of those standards in the Internet environment. - ------- Message 2 Date: Mon, 28 Sep 92 11:01:49 EDT To: Bob.Hinden@eng.sun.com cc: iab@venera.isi.edu, iesg@NRI.Reston.VA.US, Lyman@bbn.com >From: Lyman Chapin Subject: Re: Contribution from ISO >Date: Fri, 25 Sep 92 08:58:08 PDT >From: Bob Hinden >To: Lyman Chapin >Cc: iab@venera.isi.edu, iesg@NRI.Reston.VA.US >Subject: Contribution from ISO > >Lyman, > >I read it twice, but still don't understand what it means. Could you >elaborate? I assume there is more context than I have. > >I agree, with Dave Crockers suggestion that it be given wider >distribution, but given recent events, it will need an introduction. > >Thanks, >Bob Bob, You're right, I should have provided more context for the message containing the ISO contribution. I was wearing one of my other hats (finishing up a list of action items from the ISO meeting in San Diego last July) when I sent it, following a resolution of the SC6 plenary (there is no "special significance" to its appearance now, except to confirm that I have a backlog of action items with respect to my ISO hat as well as my Internet hat...). Although it's wrapped in formal ISO-ese, the gist of the liaison contribution is "if, in the course of trying to use CLNP in the Internet, you find that changing something in the protocol would help, please let us know, and we will try to change the ISO standard for CLNP accordingly". This is not a promise from SC6 to do anything we ask, but it reflects a strong feeling among the SC6 national representatives that the Internet is important, and that anything that impedes the use of CLNP in the Internet is something that should be fixed. We didn't need ISO to tell us that the Internet is important, of course, but the liaison contribution suggests that SC6 is motivated to act on proposals for changing the CLNP standard if doing so would make it easier to use CLNP in the Internet. - - - Lyman - ------- End of Forwarded Messages ------- End of Forwarded Message From owner-Big-Internet@munnari.oz.au Tue Sep 29 04:47:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04074; Tue, 29 Sep 1992 04:47:13 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04062; Tue, 29 Sep 1992 04:47:00 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11618>; Mon, 28 Sep 1992 11:46:35 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 28 Sep 1992 11:46:32 -0700 To: little@ctt.bellcore.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP In-Reply-To: Your message of "Wed, 23 Sep 92 08:31:31 PDT." <9209231531.AA05116@wizzard.ctt.bellcore.com> Date: Mon, 28 Sep 1992 11:46:28 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep28.114632pdt.10779@skylark.parc.xerox.com> Mike Little wrote: > Both internetwork size and local routing policies have an > impact on the packet lifetime required to transit a path from > source to destination. Will SIP be providing any new > direction in balancing packet lifetime thresholds with > path transit needs? SIP separates the issues of max hop count and max packet lifetime. The latter concern is delegated to the transport layer. > Although initially simple, I see complexity with the option > headers (SIP subheaders?) in terms of sequencing. Is it > possible to have the final SIP header processing result be > independent of the processing order (sequence) of the SIP > subheaders? I actually think it is a positive feature of the SIP scheme that there is a single order in which any "options" must be processed; different processing orders may result in different behaviors, so it's important to allow the sender to specify the order (implicitly, by the order of nesting of SIP Payload Types). Steve From owner-Big-Internet@munnari.oz.au Tue Sep 29 05:36:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05503; Tue, 29 Sep 1992 05:36:51 +1000 (from owner-Big-Internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05498; Tue, 29 Sep 1992 05:36:44 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 0239; Mon, 28 Sep 92 15:35:50 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 2877; Mon, 28 Sep 92 15:35:49 EDT Date: Mon, 28 Sep 92 15:32:02 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: SIP To: Steve Deering , bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au In-Reply-To: <92Sep27.163629pdt.10779@skylark.parc.xerox.com> Message-Id: <920928.153202.EDT.VALDIS@vtvm1.cc.vt.edu> On Sun, 27 Sep 1992 16:36:19 PDT you said: >> And wouldn't it be more logical to have the Destination before the Source? > >Why? Steve: Probably to make on-the-fly packet switching a bit more efficient - if you get the destination off the wire first, you can start doing a routing table lookup while the 4/8/20/whatever bytes of source are still coming off the wire. If it's a 56KB link on a fast RISC-based router, you can do a LOT of computation while waiting for 20 more bytes off the wire. (Of course, I'm the guy who forgot that 64-bit RISC processors prefer their data in 8-byte chunks, so.. ;) Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Tue Sep 29 06:09:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06910; Tue, 29 Sep 1992 06:09:59 +1000 (from owner-Big-Internet) Return-Path: Received: from delirius.cs.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06907; Tue, 29 Sep 1992 06:09:52 +1000 (from zweig@cs.uiuc.edu) Received: from dubius.cs.uiuc.edu by delirius.cs.uiuc.edu with SMTP id AA06085 (5.64+/IDA-1.3.4 for big-internet@munnari.oz.au); Mon, 28 Sep 92 15:09:46 -0500 From: Johnny Zweig Message-Id: <9209282009.AA06085@delirius.cs.uiuc.edu> Subject: Re: SIP: packet sizes To: big-internet@munnari.oz.au Date: Mon, 28 Sep 92 15:09:46 CDT In-Reply-To: <9209281624.AA27812@aland.bbn.com>; from "Craig Partridge" at Sep 28, 92 9:24 am X-Mailer: ELM [version 2.3 PL11] Random thought about "64 kilobyte" packets -- with a 16 bit length field, the biggest packet would be (2**16 - 1) minus the length of the SIP header. For applications such as distributed virtual memory, file sharing, and a few multimedia goodies, data comes in chunks of 4KB, 8KB and larger. Thus I will only be able to send 7 8KB chunks in a packet (or send 8 and another packet with the leftover few bytes). It seems like it would be nice to allow 64KB of actual payload (not even 64KB-1). But it's also hard to do with 16 bits. Craig Partridge says: > PS: These same calculations illustrate why many folks feel the ATM cell size > is far too conservatively small for high-speed networks, and illustrate > (with the T1 rates) that the ATM cell size was chosen, in part, with current, > not future bandwidths, in mind. > My understanding is that ATM cells were made small so that when digitizing voice at 64000 samples/second you don't need to spen a lot of time saving up a cell's worth of data. The Europeans begged for 32 octets, since this way the packetization overhead plus intra-continental delay would let them get away without using echo cancellation. I have heard that 48 octets is "too big" for their hardware hack, so it may well be that ATM cells are too small -- but I think the idea behind small cells wasn't to prevent starvation over slow links (though I may be wrong). -Johnny Packetized From owner-Big-Internet@munnari.oz.au Tue Sep 29 07:01:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08560; Tue, 29 Sep 1992 07:01:30 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08557; Tue, 29 Sep 1992 07:01:17 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA22354; Mon, 28 Sep 92 17:01:05 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA00275; Mon, 28 Sep 92 13:59:58 PDT Message-Id: <9209282059.AA00275@aland.bbn.com> To: Johnny Zweig Cc: big-internet@munnari.oz.au Subject: about ATM From: Craig Partridge Date: Mon, 28 Sep 92 13:59:57 -0700 Sender: craig@aland.bbn.com Johnny: I should know better than to add comments on the end of my notes, but I'm a researcher and find it hard to resist. The ATM cell size was dictated by at least two factors. One was the interference of streams I mentioned, the other is the digitizing issues you mention. Craig From owner-Big-Internet@munnari.oz.au Tue Sep 29 09:35:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14255; Tue, 29 Sep 1992 09:35:24 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14245; Tue, 29 Sep 1992 09:35:11 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11670>; Mon, 28 Sep 1992 16:34:53 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 28 Sep 1992 16:34:47 -0700 To: Johnny Zweig Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP: packet sizes In-Reply-To: Your message of "Mon, 28 Sep 92 13:09:46 PDT." <9209282009.AA06085@delirius.cs.uiuc.edu> Date: Mon, 28 Sep 1992 16:34:44 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep28.163447pdt.10779@skylark.parc.xerox.com> Johnny Zweig wrote: > Random thought about "64 kilobyte" packets -- with a 16 bit length field, the > biggest packet would be (2**16 - 1) minus the length of the SIP header. Not quite. In SIP, the Payload Length field does not include the SIP header, so the biggest packet is 2**16 - 1 PLUS the length of the SIP header. > For applications such as distributed virtual memory, file sharing, and a few > multimedia goodies, data comes in chunks of 4KB, 8KB and larger. Thus I will > only be able to send 7 8KB chunks in a packet (or send 8 and another packet > with the leftover few bytes). It seems like it would be nice to allow 64KB > of actual payload (not even 64KB-1). But it's also hard to do with 16 bits. You'd also want room for one or more additional headers (e.g., transport, application) between the SIP header and the data block. I'd suggest that you just send 7 of your 8KB blocks per packet; the per-packet fixed costs ought to be sufficiently amortized at that size that adding another block would not significantly increase the bandwidth. Steve From owner-Big-Internet@munnari.oz.au Tue Sep 29 09:54:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15120; Tue, 29 Sep 1992 09:55:07 +1000 (from owner-Big-Internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15103; Tue, 29 Sep 1992 09:54:59 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA29469 (5.65c/IDA-1.4.4nsd for ); Mon, 28 Sep 1992 16:54:53 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA14343 (5.65c/IDA-1.4.4-910725); Mon, 28 Sep 1992 16:54:51 -0700 Message-Id: <199209282354.AA14343@remmel.NSD.3Com.COM> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of Sun, 27 Sep 92 16:23:29 -0700. <92Sep27.162342pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 16:54:50 -0700 From: tracym@NSD.3Com.COM Steve, [Van wasn't the first, though he has a certain flair...] You might be interested that, regardless of the checksum verification issue (Router Reqs says it MUST be), Van's code had a bug: it did not check the received TTL for 0 before decrementing it, and could have caused infinite loops with some different buggy system that managed to happily send packets with ttl=0. On that note: How about using an extra sign bit in the hop count field and define the count to be run out when it is <=0, instead of just ==0. The goals are to eliminate the wraparound problem, where a packet could accidentally be given more life, and to make (perhaps many) implementations a cycle or two more efficient. (This would be very easy to swallow once 16 bits were allocated to the hop count!-) Also consider letting the last legal value be 0 instead of 1. In that vein, how about allowing packets to be thrown away with either <=0 when received or <=0 when transmitted, determined by the particular implementation? They might sometimes get one extra hop, but the purpose of hop count is to minimize problems due to loops, and hop counts should not be approaching zero for normal traffic. Regards, Tracy (I wish SIP weren't an SMDS acronym as well ;-) From owner-Big-Internet@munnari.oz.au Tue Sep 29 10:03:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15468; Tue, 29 Sep 1992 10:03:29 +1000 (from owner-Big-Internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15459; Tue, 29 Sep 1992 10:03:22 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA29745 (5.65c/IDA-1.4.4nsd for ); Mon, 28 Sep 1992 17:03:11 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA14361 (5.65c/IDA-1.4.4-910725); Mon, 28 Sep 1992 17:03:08 -0700 Message-Id: <199209290003.AA14361@remmel.NSD.3Com.COM> To: Steve Deering Cc: bsimpson@angband.stanford.edu, big-internet@munnari.oz.au, tracym@NSD.3Com.COM Subject: Re: SIP In-Reply-To: Your message of Sun, 27 Sep 92 16:36:19 -0700. <92Sep27.163629pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 17:03:07 -0700 From: tracym@NSD.3Com.COM >> And wouldn't it be more logical to have the Destination before the Source? >Why? Another important part of the destination first argument has to do with hardware, for systems that wish to slosh n bytes into a cache, or register set, or some such. If the source address isn't used (probably true for many systems, but not for all) then it breaks up the useful parts of the header. Putting the destination address first ensures that the useful header fields will always be contiguous, and possibly more efficiently accessed. Tracy From owner-Big-Internet@munnari.oz.au Tue Sep 29 10:04:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15519; Tue, 29 Sep 1992 10:04:56 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15514; Tue, 29 Sep 1992 10:04:31 +1000 (from kre) To: Steve Deering Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of Sun, 27 Sep 92 18:33:55 -0700. <92Sep27.183407pdt.10779@skylark.parc.xerox.com> Date: Tue, 29 Sep 92 10:04:22 +1000 Message-Id: <7588.717725062@munnari.oz.au> From: Robert Elz Date: Sun, 27 Sep 1992 18:33:55 PDT From: Steve Deering Message-ID: <92Sep27.183407pdt.10779@skylark.parc.xerox.com> I wish you would try to present a non-emotional argument as to why a solar-system-wide Internet ought to have or must have a diameter greater than 255 hops. I'm not sure that there is one - if you consider diameter in the intuitive way, then 255 is a lot, even with just 1ms transit, processing, and queueing time, which is pretty fast, a path that had to approach 255 hops would have a pretty long rtt. However, I agree with Frank that its hard to anticipate what the future might bring - remember that even though IP has an 8 byte TTL field, 4.2 BSD used just half of it (4 bits) by making the default TTL be 15 when packets were originated. When it was coded 15 was plenty... That was largely because the arpanet (and milnet) were just 1 hop, however far the packet travelled. Since then the way the net has been put together has changed, and now you can get a couple of hops inside what most people would think of as one router - and 15 is not nearly enough any more. Its very hard to know how nets will be built in the future, so its very hard to predict how many "hops" a packet will go through. I can imagine building a high performance, high capacity router, in which the hop count could be decremented by 8 or so (8 internal "hops") between when the packet enters and when it leaves. What's more that is a perfectly justifiable, if not ideal, operational method. If that kind of router became prevalent, an 8 bit field would leave only a "real" diameter of 32, which might, or might not, be enough. kre ps: 8 comes from building a router where the hop count is decremented as the packet passes through an interface, so that high speed forwarding (in and out on the fly) can be done. Then you take a packet that can't be processed that way, but has to go over a backplane and out another board. Now 2 hops (one for the interface in, and one out). The inferface processors want to be very high speed, so they have no special cases (ttl already decmented flag, or anything like that). Now you build a high capacity router out of several of those multi-interface-board boxes, linked together on a high speed ring, and take a packet that arrives in one box, across the ring to a generic router box (handles packets where the destination isn't in a local cache), then over the ring again to the departure box - with 2 ttl decrements in each of the boxes, and ttl has been decreased by 6 in handling a routine packet in a reasonable way. That's close enough to 8... From owner-Big-Internet@munnari.oz.au Tue Sep 29 10:25:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16388; Tue, 29 Sep 1992 10:25:58 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16385; Tue, 29 Sep 1992 10:25:48 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11666>; Mon, 28 Sep 1992 17:25:26 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 28 Sep 1992 17:25:20 -0700 To: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Mon, 28 Sep 92 08:12:49 PDT." <9209281512.AA20193@ftp.com> Date: Mon, 28 Sep 1992 17:25:17 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep28.172520pdt.10779@skylark.parc.xerox.com> > The original IP address had one format -- what we call class A. One byte > of network number ... Right. Originally it may have looked like one byte would be plenty. Turns out that we now think we need somewhere between 6 and 13 bytes to identify all of the physical networks that might be part of the Internet. Shall one conclude from that that the time-to-live field should be increased from 1 byte to 12 bytes, just in case the Internet diameter someday starts growing the same way as network numbers? Who knows, maybe in the future, internetworking will be done by hooking all of the networks in the world into one giant ring. To simplify routing. Laid out as a star, of course, for manageability. :-) On the other hand, maybe in the future, no system will be more than three hops from the nearest ATM gateway, so that a 3-bit hop limit field would be big enough. An Internet Old Youth (the non-sexist term for Old Boy?) once told me that you can't win when it comes to choosing field sizes: either your protocol will succeed beyond your wildest imagination and some field will turn out to be too small, or else your protocol will never be widely used, in which case it doesn't matter what size your fields are. (I suppose an alternative is to make all fields variable-length and self encoding. That's it: the IPv7 header should be ASN.1 encoded!) I'm still waiting for a plausible rationale for an Internet in which some delivery paths are more than 200 hops long. (Yes, I know that I run the risk of having these messages held up for ridicule 20 years from now, when the Internet has a diameter of a million hops.) Steve From owner-Big-Internet@munnari.oz.au Tue Sep 29 10:48:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17379; Tue, 29 Sep 1992 10:48:46 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17350; Tue, 29 Sep 1992 10:48:21 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11658>; Mon, 28 Sep 1992 17:47:57 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 28 Sep 1992 17:47:52 -0700 To: tracym@nsd.3com.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of "Mon, 28 Sep 92 16:54:50 PDT." <199209282354.AA14343@remmel.NSD.3Com.COM> Date: Mon, 28 Sep 1992 17:47:48 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep28.174752pdt.10779@skylark.parc.xerox.com> > From: tracym@nsd.3com.com > > ...Van's code had a bug: it did not check the received TTL for 0 before > decrementing it, and could have caused infinite loops with some different > buggy system that managed to happily send packets with ttl=0. That's not true of the code I was talking about, which is in the notes from his SIGCOMM '90 tutorial. It does this: register int i; i = ip->ip_ttl; if ( --i <= 0 ) { ip_send_time_exceeded(m); return; } ip->ip_ttl = i; > How about using an extra sign bit in the hop count field and define the > count to be run out when it is <=0, instead of just ==0. The goals are to > eliminate the wraparound problem, where a packet could accidentally be given > more life, and to make (perhaps many) implementations a cycle or two more > efficient. (This would be very easy to swallow once 16 bits were allocated > to the hop count!-) Neat idea. > (I wish SIP weren't an SMDS acronym as well ;-) Oh. I hadn't thought of that. I guess I'll have to switch to the other name: CLNPv2. Steve From owner-Big-Internet@munnari.oz.au Tue Sep 29 10:59:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18595; Tue, 29 Sep 1992 11:00:33 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18440; Tue, 29 Sep 1992 10:59:18 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11669>; Mon, 28 Sep 1992 17:58:59 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 28 Sep 1992 17:58:53 -0700 To: Robert Elz Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Mon, 28 Sep 92 17:04:22 PDT." <7588.717725062@munnari.oz.au> Date: Mon, 28 Sep 1992 17:58:43 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep28.175853pdt.10779@skylark.parc.xerox.com> > I can imagine building a high performance, high > capacity router, in which the hop count could be decremented > by 8 or so (8 internal "hops") between when the packet enters > and when it leaves. What's more that is a perfectly > justifiable, if not ideal, operational method. If that kind > of router became prevalent, an 8 bit field would leave only > a "real" diameter of 32, which might, or might not, be enough. Finally. A plausible justification for a bigger Hop Limit field. Not clinching, but persuasive. :-) Steve From owner-Big-Internet@munnari.oz.au Tue Sep 29 11:18:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19660; Tue, 29 Sep 1992 11:18:31 +1000 (from owner-Big-Internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19651; Tue, 29 Sep 1992 11:18:21 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA02966 (5.65c/IDA-1.4.4nsd for ); Mon, 28 Sep 1992 18:18:16 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA14473 (5.65c/IDA-1.4.4-910725 for big-internet@munnari.oz.au); Mon, 28 Sep 1992 18:18:14 -0700 Message-Id: <199209290118.AA14473@remmel.NSD.3Com.COM> To: big-internet@munnari.oz.au Subject: Re: lack of checksum field in SIP header - apologies In-Reply-To: Your message of Mon, 28 Sep 92 17:47:48 -0700. <92Sep28.174752pdt.10779@skylark.parc.xerox.com> Date: Mon, 28 Sep 92 18:18:13 -0700 From: tracym@NSD.3Com.COM Apologies to Van. [I've lost my archive of the original "couldn't sleep last night" message. I may well have been wrong all these years. I remember being upset with his "couldn't justify the 10 or so instructions" for the checksum when I couldn't possibly do it in less than 16 (17?) on a 68020 even assuming the free use of scratch registers.] >> ...Van's code had a bug: it did not check the received TTL for 0 before >> decrementing it, and could have caused infinite loops with some different >> buggy system that managed to happily send packets with ttl=0. > >That's not true of the code I was talking about, which is in the notes from >his SIGCOMM '90 tutorial. It does this: > > register int i; > > i = ip->ip_ttl; > if ( --i <= 0 ) { > ip_send_time_exceeded(m); > return; > } > ip->ip_ttl = i; Tracy From owner-Big-Internet@munnari.oz.au Tue Sep 29 17:32:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04923; Tue, 29 Sep 1992 17:32:53 +1000 (from owner-Big-Internet) Return-Path: Received: from rx7.ee.lbl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04917; Tue, 29 Sep 1992 17:32:47 +1000 (from van@ee.lbl.gov) Received: by rx7.ee.lbl.gov for big-internet@munnari.oz.au (5.65/1.44r) id AA01791; Tue, 29 Sep 92 00:34:17 -0700 Message-Id: <9209290734.AA01791@rx7.ee.lbl.gov> To: tracym@nsd.3com.com Cc: big-internet@munnari.oz.au Subject: Re: lack of checksum field in SIP header - apologies In-Reply-To: Your message of Mon, 28 Sep 92 18:18:13 PDT. Date: Tue, 29 Sep 92 00:34:17 PDT From: Van Jacobson > I remember being upset with his "couldn't justify the 10 or so > instructions" for the checksum when I couldn't possibly do it in > less than 16 (17?) on a 68020 even assuming the free use of > scratch registers. Tracy, This is wandering rather far afield for big-internet, but it really was 10 instructions. The code was something like: moveml a0@+,d0-d4 | get ip header addl d1,d0 | sum it (5 words) addxl d2,d0 addxl d3,d0 addxl d4,d0 movl d0,d2 | fold sum swap d2 addxw d0,d2 clrl d0 | zero msh & pick up final carry addxw d2,d0 Actually the movem shouldn't count since it's used by more than the checksum --- the ip_input routine this was embedded in sucked the entire header into registers on entry (the moveml) then just worked with the contents of those registers. Going back to Steve Deering's original point, checksum validation added 30% to the cost of forwarding (30 instr. avg. increased to 40) and, since almost all the header fields had to be checked for semantic consistency anyway (e.g., version & header length correct, dest addr in routing table, ip length <= rcvd length), it seemed to me that a lot of extra work was being done for no reason. Later, on Steve Deering's suggestion, I modified the code so that the checksum was tested if the semantic checks failed. E.g., if the ip length was less than the amount of data received, the header checksum told you whether the error was a corrupted packet or really a bogus length. I think this is in the spirit of Robert Elz's "optional" checksum (an idea I like a lot). But it would be nice if the SIP checksum *didn't* cover header fields that change hop-to-hop (the ttl) -- the checksum update code costs 10% of the total (3 instructions out of 30) for IP which is a rather high price to pay for something that's only of interest for disambiguating errors. - Van ps- Your memory was correct: In the July '89 msg I incorrectly did the ttl update via if (--ip->ip_ttl <= 0) ... (I can only plead that I had written the code & the email msg at 4am after consuming my nightly quota of brandy.) Steve Deering pointed out this error (& several little-endian problems that I never notice because we own no little-endian machines) the next day. I sent out a correction to the original msg but it probably went to the end-to-end task force & not the end2end-interest list. From owner-Big-Internet@munnari.oz.au Tue Sep 29 18:11:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06378; Tue, 29 Sep 1992 18:12:05 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06366; Tue, 29 Sep 1992 18:11:49 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA12702 (5.65b/CWI-2.177); Tue, 29 Sep 1992 09:11:35 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA18084; Tue, 29 Sep 92 09:12:00 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA07441; Tue, 29 Sep 92 09:11:28 +0100 Message-Id: <9209290811.AA07441@dxcern.cern.ch> Subject: Re: SIP / 64 k limit To: big-internet@munnari.oz.au Date: Tue, 29 Sep 92 9:11:27 MET From: Brian Carpenter CERN-CN In-Reply-To: <199209281629.AA05518@mitsou.inria.fr>; from "Christian Huitema" at Sep 28, 92 5:29 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Christian Huitema follows: > > Brian, > > We certainly differ on this. Normal! The British and the French have a long tradition of disagreement. > Fragmentation of PDU is inevitable if you want > to assign an MTU; there has to be some limit. Rationales for the limit are > reliability (packet error rate rises exponentially with packet length), > response time (the queuing effect you mention, used to justify the 256 limit > on SLIP, also used to justify the 48 byte size of ATM by the telephonists), > and also memory management (e.g. the 256k, or 100k, or 2 M limits often > encountered in mail networks). > > What is generally considered a bad idea is to have several layers of > fragmentation, e.g. fragment both at TCP and IP layers. All true. > Indeed, the ATM true > believers will push the reasoning to the point that, as ATM "allows" you (in > fact, forces you) to fragment at the cell level, then you shall have ATM > cells end to end, and no other layers of fragmentation. But the glow of ATM > seems to have already started to fade, so I wont insist there. I don't know if I'm a true believer but yes, I don't see the _point_ of ATM if you cannot use it end-to-end (please, people, if you want to flame on this topic use the comp.dcom.cell-relay newsgroup not big-internet). > > There is one strong point in your argument, though. If we note that the > current limit is 64k, today, for FC, HIPPI and ATM, and that we want to > build for 20 years, then we may realize that building todays maximum into > tomorrows protocol is perhaps not the best possible idea... That is, in fact, my _only_ point: keep our options open! Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.oz.au Tue Sep 29 19:24:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09025; Tue, 29 Sep 1992 19:24:34 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09018; Tue, 29 Sep 1992 19:24:22 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA06767; Tue, 29 Sep 1992 10:25:14 +0100 Message-Id: <199209290925.AA06767@mitsou.inria.fr> To: Steve Deering , big-internet@munnari.oz.au Subject: SIP - a summary of the field allocation debate In-Reply-To: Your message of "Mon, 28 Sep 92 17:58:43 PDT." <92Sep28.175853pdt.10779@skylark.parc.xerox.com> Date: Tue, 29 Sep 92 10:25:13 -0500 From: Christian Huitema X-Mts: smtp Folks, Trying to focus this discussion on field sizes seems, I believe that a reference to IPv4 may be a useful cross check. The v4 header, as defined in RFC-791, looks like: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A short hand definition of SIP could be "64 bits IP with useless overhead removed". Lets do a cross check: Old New Comment Version 4 bits 0 Redundant with subnet level protocol ID. IHL 4 bits 0 SIP header is fixed length TOS 8 bits 8 ? Should be kept; could perhaps be merged with some form of "flow ID". Only 6 bits are defined; current usage is very conservative (0 to 1 bits). flow id 0 8,16,24? Flow id can be used to support resource allocation. TotalLength 16 16 Is enough for all known subnets. 24,32? We dont know of future subnets. Hippi could, in fact, carry longer packets. Identification 16 0 Only needed for fragmentation. Flags 4 0 ditto Frag. Offset 12 0 ditto TTL 8 8,12,16? Growing topology may require more bits Protocol 8 8 We dont want to encourage a flurry of protocols. Header Check 16 0, 16? A subject of debate. Source Add. 32 64 Larger addresses are needed. Dest. Add. 32 64 ditto. Options 0-352 0 Supported by "SIP-CMP". If we summarize, we see that: * The agreed fields have a size of 8 + 8 + 64 + 64, leaving space for 48 bits if we want to keep a 3*64 header, for 112 bits if we admit 4*64. * IP**2 would have been 320 bytes; 192, or even 256, is not a bad result. * the minimal size of the debated fields is (8+16+8+0)= 32, (less than 48) * the max size of the debated fields is (24+32+16+16) = 88 (less than 112). So, the real question is whether we can squeeze the "debated" parts into 48 bits, or not. From the debate, we have seen that: * If IP+flow-id are merged, then a total of 16 bits is perhaps adequate, although 24 might be more confortable, hence a cost of 8-16 for "flow-id". * There seems to be a strong requirement for a TTL of 16 or at least 12 bits. * There is no real rationale for a length larger than 16 bits. Allocating 24 would probably cover all not yet foreseen needs; allocating 32 is an overkill for alignment + easier processing. * The necessity of header check is very debatable. It is redundant with end to end checks, and the very idea of recomputing a check at each hop is questionable. Bad implementations routinely recompute a valid checksum for a random header anyhow... If we buy this compromise, we obtain a new range of variation for the variable part, i.e. between (8+12+16) = 36, and (16+16+24)=54. We will only be able to keep a 3 long words header if we reduce again the allocation for either TTL or flow id, e.g. by having a combined TOS+flow id field of length 16. This gives the following compromise: TOS+flow-id 16 bits TotalLength 24 bits TTL 16 bits Protocol 8 bits (new name is "payload type") Header Check 0 bits Source Add. 64 bits Dest. Add. 64 bits With the possible map: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload type | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS and flow spec | Time to Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Do we have a deal? I believe that if we cant buy this one, then we will have to go for 4 * 64 bits, and could as well allocate the maximum desired length to each of the fields. Christian Huitema From owner-Big-Internet@munnari.oz.au Tue Sep 29 21:12:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12285; Tue, 29 Sep 1992 21:12:27 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209291112.12285@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12280; Tue, 29 Sep 1992 21:12:21 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <11657-0@datanet.tele.fi>; Tue, 29 Sep 1992 13:11:42 +0200 To: Christian.Huitema@sophia.inria.fr Cc: deering@parc.xerox.com, big-internet@munnari.oz.au In-Reply-To: <199209290925.AA06767@mitsou.inria.fr> "Christian.Huitema@sophia.inria.fr" Subject: SIP - a summary of the field allocation debate Date: Tue, 29 Sep 1992 13:11:42 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi The TOS field is too short for me. I would namely like to able to color packets in order get rid of long access lists used today. That is, packets allowed to certain set of destinations are colored by a certain color. I would imagine that I would need at least 16 bits for the colors. -- Juha From owner-Big-Internet@munnari.oz.au Tue Sep 29 21:43:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13245; Tue, 29 Sep 1992 21:44:00 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209291144.13245@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13242; Tue, 29 Sep 1992 21:43:54 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 29 Sep 1992 12:43:31 +0100 To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of "Sun, 27 Sep 92 14:52:40 PDT." <92Sep27.145250pdt.10779@skylark.parc.xerox.com> Date: Tue, 29 Sep 92 12:43:28 +0100 From: Zheng Wang > - a corrupted Source Address may result in incomplete delivery > of a multicast packet (wrong delivery tree chosen), or in > delivery of a returned SIPC error message to the wrong source, > neither of which is fatal, given the tolerance of SIP client > protocols to packet loss. Data packets are often protected by upper layer protocols (sequencing and checksum) but error messages are more vulnerable. If the source address of a packet is corrupted, a router may send a "net A unreachable" message to the wrong source and the wrong source may mark net A unreachable. > - a corrupted Destination Address may result in failure to deliver > or in delivery to the wrong destination(s). The former is > tolerated by SIP client protocols. The latter can be detected > at the receiver(s) by the transport checksum; for applications > sending sensitive data, end-to-end encryption protects against > revealing packet contents to the wrong destination(s). The corrupted destination address may fall into the multicast address space. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Sep 29 23:45:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16845; Tue, 29 Sep 1992 23:45:22 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16831; Tue, 29 Sep 1992 23:45:10 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA01363; Tue, 29 Sep 92 06:44:49 -0700 Date: Tue, 29 Sep 92 08:14:08 EDT From: "William Allen Simpson" Message-Id: <764.bill.simpson@um.cc.umich.edu> To: Steve Deering Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: SIP field order > From: Steve Deering > > And wouldn't it be more logical to have the Destination before the Source? > > Why? > The other replies have more arguments than I ever thought of! I was just putting routing fields ahead of non-routing fields. Of course, if you couple the Flow id to the Source, it becomes a routing field, too. The Payload Type field would appear to be a non-routing field, except when source routing is used. The Payload Length field is a non-routing field. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Tue Sep 29 23:45:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16867; Tue, 29 Sep 1992 23:45:43 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16862; Tue, 29 Sep 1992 23:45:35 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA01372; Tue, 29 Sep 92 06:45:15 -0700 Date: Tue, 29 Sep 92 08:26:37 EDT From: "William Allen Simpson" Message-Id: <766.bill.simpson@um.cc.umich.edu> To: Steve Deering Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: TOS in SIP > From: Steve Deering > Here's a strawman, to show the kind of thing I'm looking for: > > The following 32 bits are included in the SIP header: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Service Pref. | Flow ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Service Preference 8-bit value specifying a desired type of > delivery service: > > 0 - no preference > 1 - minimal delay > 2 - maximal throughput > 3 - minimal packet loss > 4 - minimal expense > 5-255 - reserved > How about "Well-Known Flows", like ports? The first N could be reserved, and the rest would be dynamically assigned during flow setup (either by the source or first hop router). Why such a large number (3 octets)? Surely we don't expect to see millions of simultaneous connections to the same source? My thought is that for a given Source/Destination pair, the number is more likely to be very small (<16), allowing for quite a bit of rollover time even in a single octet. I suggest one octet, reserving the first 64 (twice what we have in IP4 now) for the current IP TOS numbers, and 64 - 255 would identify a flow for a Source/Destination (or Destination/Source) pair. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Tue Sep 29 23:52:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17154; Tue, 29 Sep 1992 23:52:31 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17149; Tue, 29 Sep 1992 23:52:18 +1000 (from kasten@ftp.com) Received: by ftp.com id AA20000; Tue, 29 Sep 92 09:52:02 -0400 Date: Tue, 29 Sep 92 09:52:02 -0400 Message-Id: <9209291352.AA20000@ftp.com> To: big-internet@munnari.oz.au Subject: Re: SIP: packet sizes From: kasten@ftp.com (Frank Kastenholz) hi I was just thinking (yes, I know that this is a rare occurance and is dangerous...:-) the reason we want a length field in the packet headers is to determine the actual length of the "real" packet -- i.e. to remove any padding required at the data link level. We are sort of debating whether 2 bytes of length is enough -- do we need to go to 3 or 4 bytes, etc, etc. Why don't we say that if the length field is not 0 then it is the length of the packet. If it is 0 then the actual length received by the interface is the true length? I imagine that only "small" packets would get padded. So, packet lengths could grow without bound, at least as far as the header is concerned. We could make the "length" field one byte long (I do not imagine that there are any physical networks that have minimum packet lengths longer than 255 bytes). Another idea is to make this field the "pad length" -- i.e. how many padding bytes were added to the packet. Again, this is predicated on the idea that only a "few" bytes are added to any given packet for padding. The length field could, again, be reduced to one byte. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Wed Sep 30 01:15:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20902; Wed, 30 Sep 1992 01:16:00 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20896; Wed, 30 Sep 1992 01:15:52 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA23715 (5.65c/UK-2.1-920831); Tue, 29 Sep 1992 11:20:10 -0400 From: Gary Scott Malkin Date: Tue, 29 Sep 1992 11:20:10 -0400 Message-Id: <23715.199209291520@atlas.xylogics.com> To: kasten@ftp.com Cc: big-internet@munnari.oz.au In-Reply-To: (Frank Kastenholz's message of Tue, 29 Sep 92 09:52:02 -0400 <9209291352.AA20000@ftp.com> Subject: SIP: packet sizes > Another idea is to make this field the "pad length" -- i.e. how many padding > bytes were added to the packet. Again, this is predicated on the idea > that only a "few" bytes are added to any given packet for padding. The > length field could, again, be reduced to one byte. If we are guaranteed that ALL datalink layers will ALWAYS be able to hand up a length, then this is a great idea. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Wed Sep 30 01:47:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22221; Wed, 30 Sep 1992 01:47:52 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22216; Wed, 30 Sep 1992 01:47:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25865; Tue, 29 Sep 92 11:47:34 -0400 Date: Tue, 29 Sep 92 11:47:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209291547.AA25865@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: SIP Cc: jnc@ginger.lcs.mit.edu May I suggest the creation of a separate SIP mailing list? TUBA, PIP, etc all have separate lists. That way, we can keep B-I for generic issues, arguments about which scheme is better, etc, etc. BTW, what does the routing and addressing architecture for SIP look like? Designing packet formats is a lot of fun, but the real problem with the current IP is that the routing tables in the routers are about to go blooey, not that the TTL field is too big or too small, it has an unneeded checksum, etc. There's this story of the drunk looking for his keys under the streetlight, and when the helpful policeman offers to help, and asks where he dropped them, the drunk says "over there", pointing into the darkness. The policeman is sort of confused, until the drunk explains that he can't see very well in the dark..... Noel From owner-Big-Internet@munnari.oz.au Wed Sep 30 01:58:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22631; Wed, 30 Sep 1992 01:58:52 +1000 (from owner-Big-Internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22628; Wed, 30 Sep 1992 01:58:46 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <6462>; Tue, 29 Sep 1992 11:58:31 -0400 Received: from dino.alias.com by porter.alias.com with SMTP id AA19698 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Tue, 29 Sep 92 09:23:46 -0400 Received: by dino.alias.com id AA10717 (5.65a/IDA-1.4.2 for deering@parc.xerox.com); Tue, 29 Sep 92 09:23:42 -0400 Date: Tue, 29 Sep 1992 09:23:42 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9209291323.AA10717@dino.alias.com> To: prue@ISI.EDU (Walter Prue), deering@parc.xerox.com Subject: Re: SIP Cc: big-internet@munnari.oz.au >I don't know if anyone does it today but it would be possible between speed >matched data links to passthrough route packets as soon as the destination >address is received. That is, as soon as you know, to where the packet is >destined, start to clock the data out the appropriate data link well before >the end of the packet is received. > >Walt If SIP was to adopt the (optional) checksum field that Robert Elz was talking about the other day, could you still do what Walt suggests? Would you not first want to receive the entire packet and perform the optional checksum before deciding on the routing? Mark From owner-Big-Internet@munnari.oz.au Wed Sep 30 02:17:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23301; Wed, 30 Sep 1992 02:17:48 +1000 (from owner-Big-Internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23295; Wed, 30 Sep 1992 02:17:37 +1000 (from jkrawczy@wellfleet.com) Received: from hobbes.wellfleet ([192.32.1.254]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA01607; Tue, 29 Sep 92 12:15:40 EDT Received: by hobbes.wellfleet (4.1/SMI-4.1) id AA00339; Tue, 29 Sep 92 12:18:27 EDT Date: Tue, 29 Sep 92 12:18:27 EDT From: jkrawczy@wellfleet.com (John Krawczyk) Message-Id: <9209291618.AA00339@hobbes.wellfleet> To: kasten@ftp.com Cc: big-internet@munnari.oz.au In-Reply-To: (Frank Kastenholz's message of Tue, 29 Sep 92 09:52:02 -0400 <9209291352.AA20000@ftp.com> Subject: SIP: packet sizes Date: Tue, 29 Sep 92 09:52:02 -0400 From: kasten@ftp.com (Frank Kastenholz) Why don't we say that if the length field is not 0 then it is the length of the packet. If it is 0 then the actual length received by the interface is the true length? I imagine that only "small" packets would get padded. So, packet lengths could grow without bound, at least as far as the header is concerned. We could make the "length" field one byte long (I do not imagine that there are any physical networks that have minimum packet lengths longer than 255 bytes). Another idea is to make this field the "pad length" -- i.e. how many padding bytes were added to the packet. Again, this is predicated on the idea that only a "few" bytes are added to any given packet for padding. The length field could, again, be reduced to one byte. -- frank kastenholz I've seen a lot of suggestions here that go under the category of "layer violation"; this one is included. While I'm not a purist on layer violation, in this case I really don't want to burden my level 3 forwarding code with the knowledge of the the minimum packet size for every underlying link layer. Nor would I want to make the level 2 / driver code have to figure out that it's sending a (name your routing protocol) packet and have it insert a pad count. Maybe it's not a big deal for end stations, but for a multi-protocol, multi-media router, it is. I've seen hardware that insists on rounding things up to 2 or 4 byte boundaries, thus giving you the wrong length when an odd byte sized packet is received. If we are going to use a mechanism as suggested above, it would have to work for all physical networks and all of the hardware attached to them. -jj From owner-Big-Internet@munnari.oz.au Wed Sep 30 02:26:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23572; Wed, 30 Sep 1992 02:27:06 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23558; Wed, 30 Sep 1992 02:26:57 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27303; Tue, 29 Sep 92 12:26:47 -0400 Message-Id: <9209291626.AA27303@ginger.lcs.mit.edu> To: Frank Kastenholz Cc: big-internet@munnari.oz.au Subject: Re: SIP: packet sizes In-Reply-To: Your message of Tue, 29 Sep 92 09:52:02 -0400. <9209291352.AA20000@ftp.com> From: David Clark Date: Tue, 29 Sep 92 12:26:46 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Remember your history, or the ides of March, or something. Remember the ARPAnet, which deliberately added bits (not bytes) to a packet as it crossed the net, so that it could deliver it in whole units to a computer of any byte size... Dave From owner-Big-Internet@munnari.oz.au Wed Sep 30 03:06:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25092; Wed, 30 Sep 1992 03:06:33 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25077; Wed, 30 Sep 1992 03:06:21 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA07736; Tue, 29 Sep 1992 18:06:37 +0100 Message-Id: <199209291706.AA07736@mitsou.inria.fr> To: Gary Scott Malkin Cc: kasten@ftp.com, big-internet@munnari.oz.au Subject: Re: SIP: packet sizes In-Reply-To: Your message of "Tue, 29 Sep 92 11:20:10 -0400." <23715.199209291520@atlas.xylogics.com> Date: Tue, 29 Sep 92 18:06:36 -0500 From: Christian Huitema X-Mts: smtp The "pad length" is not such a good idea, as it creates a dependency between the IP and the subnet level. How many bytes of padding are used is subnet dependant, hence must be recomputed for each hop. If we make the hypothesis that the subnet can pass a "received length" of some sort, then a better idea might be to pass a "length mask", e.g. length-of-payload % 2**16 We are thus only reduced to declaring a MTU lower than 2**64 for those subnets that cannot deliver a reasonable indication of the packet length. Christian Huitema From owner-Big-Internet@munnari.oz.au Wed Sep 30 03:11:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25290; Wed, 30 Sep 1992 03:11:57 +1000 (from owner-Big-Internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25285; Wed, 30 Sep 1992 03:11:44 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 9749; Tue, 29 Sep 92 13:10:51 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 9057; Tue, 29 Sep 92 13:10:50 EDT Date: Tue, 29 Sep 92 12:55:06 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: TOS in SIP To: William Allen Simpson , Steve Deering , bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au In-Reply-To: <766.bill.simpson@um.cc.umich.edu> Message-Id: <920929.125506.EDT.VALDIS@vtvm1.cc.vt.edu> On Tue, 29 Sep 92 08:26:37 EDT William Allen Simpson said: >My thought is that for a given Source/Destination pair, the number >is more likely to be very small (<16), allowing for quite a bit of >rollover time even in a single octet. Hmm.. I can think of a common case where a source/dest pair has a lot of connections - consider a 128-port terminal server talking to a large CBX on one side, and a large mainframe that's catching all the connections. Yes, 3 octets is overkill. But one octet is insufficient, especially if we carve out 64 or so "reserved" values... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Wed Sep 30 03:57:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26628; Wed, 30 Sep 1992 03:58:28 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26605; Wed, 30 Sep 1992 03:57:39 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA25811; Tue, 29 Sep 92 13:56:51 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA06214; Tue, 29 Sep 92 10:55:45 PDT Message-Id: <9209291755.AA06214@aland.bbn.com> To: ietf-discuss@nri.reston.va.us Cc: big-internet@munnari.oz.au Subject: IESG criteria for IPv7 Reply-To: Craig Partridge From: Craig Partridge Date: Tue, 29 Sep 92 10:55:44 -0700 Sender: craig@aland.bbn.com Hi folks: I've been told by a couple of sources that the IESG completed its revised criteria for choosing the next IP about four weeks ago, but they still haven't released the document. I find this situation disturbing for a three reasons: + It means that the folks leading some IPv7 efforts (e.g. IESG members) know what the criteria are, while others who are not IESG members, like Steve Deering, don't. It is in all of our interests to make sure that each proposal gets equal preparation time. (Note: I believe that the IESG members leading the IPv7 efforts all believe that making sure all proposals get equal treatment is the way to go -- I don't have reason to believe there's a power play going on here, just a gummed up process). + We're all working on a tight deadline (people keep saying things about deciding in November), so delaying a document of this importance is *extraordinarily* irresponsible. + The IETF/big-internet community needs to review the document to be sure there aren't any mistakes in it. My understanding is that Phill Gross is the document's editor. So, if you might start by e-mailing Phill directly saying you'd like to see the document released ASAP. Phill's address is pgross@ans.net. Craig PS: I apologize for hitting the list, but I tried hassling Phill to get the document out yesterday and got told to buzz off. I'm hoping that additional complaints might prod him along. From owner-Big-Internet@munnari.oz.au Wed Sep 30 04:37:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27915; Wed, 30 Sep 1992 04:38:13 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.sequent.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27906; Wed, 30 Sep 1992 04:37:48 +1000 (from mckenney@sequent.com) Received: from eng3.sequent.com by gateway.sequent.com (5.61/1.34) id AA22016; Tue, 29 Sep 92 11:36:50 -0700 Received: by eng3.sequent.com (5.65/1.34) id AA13793; Tue, 29 Sep 92 11:36:06 -0700 From: Paul E. McKenney Message-Id: <9209291836.AA13793@eng3.sequent.com> Subject: Re: TOS in SIP To: VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) Date: Tue, 29 Sep 92 11:36:05 PDT Cc: bill.simpson@um.cc.umich.edu, deering@parc.xerox.com, bsimpson@angband.stanford.edu, big-internet@munnari.oz.au Priority: normal In-Reply-To: <920929.125506.EDT.VALDIS@vtvm1.cc.vt.edu>; from "Valdis Kletnieks" at Sep 29, 92 12:55 pm X-Mailer: ELM [version 2.2 CRG PL14c] >On Tue, 29 Sep 92 08:26:37 EDT William Allen Simpson said: >>My thought is that for a given Source/Destination pair, the number >>is more likely to be very small (<16), allowing for quite a bit of >>rollover time even in a single octet. > >Hmm.. I can think of a common case where a source/dest pair has a lot >of connections - consider a 128-port terminal server talking to a large >CBX on one side, and a large mainframe that's catching all the connections. > >Yes, 3 octets is overkill. But one octet is insufficient, especially if we >carve out 64 or so "reserved" values... > > Valdis Kletnieks > Computer Systems Engineer > Virginia Polytechnic Institute I agree wholeheartedly that one octet just does not do it for a large server machine. Even two octets is cutting it close in this case -- we frequently get situations where several thousand connections are needed. For example, consider a gateway connecting a wide-area network to a high-bandwidth LAN. There are a number of hosts on the LAN, but the primary target for WAN connections is a large server. Connecting the server to the WAN may not be desirable for a number of reasons: (1) don't want to disturb the server with traffic not intended for it, (2) may wish to swap out WANs quickly and easily in response to changes in tariffs (and do not want to modify the server's hardware config in this case), (3) may wish to place all access-list information in one place (the gateway) rather than distributing it among all the hosts on the LAN, and (4) may not wish to have multiple interfaces to the WAN for cost or manageability reasons. Suppose that the MSL is 120 seconds. Then a two-octet field can support an average of at most 546 connections per second. This certainly will not last for 20 years. A three-octet field can support at most 139,810 connections per second, which sounds like a lot, but is only 40x (less than six doublings) of the peak transaction rate seen by the US airline reservation system during the fare wars last Spring. Might last 20 years, but would not want to bet the farm on it. If 20 years is really the design goal, four bytes is not as big as it might seem at first blush! Thanx, Paul From owner-big-internet@munnari.oz.au Wed Sep 30 05:05:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28639; Wed, 30 Sep 1992 05:05:54 +1000 (from owner-big-internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27348; Wed, 30 Sep 1992 04:19:49 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA21962 (5.65c/IDA-1.4.4nsd for ); Tue, 29 Sep 1992 11:19:45 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA15021 (5.65c/IDA-1.4.4-910725); Tue, 29 Sep 1992 11:19:43 -0700 Message-Id: <199209291819.AA15021@remmel.NSD.3Com.COM> To: Christian Huitema Cc: big-internet@munnari.oz.au Subject: Re: SIP - a summary of the field allocation debate In-Reply-To: Your message of Tue, 29 Sep 92 10:25:13 -0500. <199209290925.AA06767@mitsou.inria.fr> Date: Tue, 29 Sep 92 11:19:42 -0700 From: tracym@NSD.3Com.COM I've wondered for some time why we've been assuming that, if there is to be a header checksum, then it will be 16 bits. All the focus on 32-bit and larger machines has neglected the possibility of using a simple 32-bit sum of the header words. Also, I'd put the checksum last in the header. If the choices are 24 bytes or 32 bytes for the header length, I'd prefer 32 with a checksum followed by 24 with no checksum. > * If IP+flow-id are merged, then a total of 16 bits is perhaps adequate, > although 24 might be more confortable, hence a cost of 8-16 for "flow-id". > > * There seems to be a strong requirement for a TTL of 16 or at least 12 bits. We know even less about TOS+flow-id than we do about the requirement for a 16-bit hop count. I'd slide the bit allocation towards the flow-id side, especially if you accept the sign-bit hack for hop-count. > * There is no real rationale for a length larger than 16 bits. Allocating 24 > would probably cover all not yet foreseen needs; allocating 32 is an > overkill for alignment + easier processing. I've felt the that decision surrounding 16-bits or more of length was very similar to that of 8-bits or more for hop-count. (and what does trace-route show when traversing a "super-router" that decrements the hop-count by 8?) 24-bits seems a better bet to me, but see below. > * The necessity of header check is very debatable. It is redundant with end > to end checks, and the very idea of recomputing a check at each hop is > questionable. Bad implementations routinely recompute a valid checksum for > a random header anyhow... > I've always hated the TCP psuedo-header, since it made TCP unreasonably dependent on the particular lower layer. Look at the efforts to define TCP over CLNP. Why should we make the mistake again of assuming the psuedo-header implementation for every higher layer protocol? (This is probably too late in the discussion to generate serious flames, you can ignore it if you like.) I'd prefer that the headers had some protection. I'd also suggest not only putting destination address before source address, but leading off the header, in the interests of getting the bits used for routing as soon as possible. It may often be the case that the length can't be validated until most of the packet has already be transmitted, so why put the length up front. Tracy's version: TOS+flow-id 24 bits TotalLength 20 or 32 bits TTL 12 or 16 bits Protocol 8 bits (new name is "payload type") Header Check 0 or 32 bits Source Add. 64 bits Dest. Add. 64 bits With the possible maps: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload type | TOS and flow spec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Time to Live | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length/hop-count split has the widest range of reasonable values, with both 16/16 and 24/8 as possible, in my opinion. My preferred header at this time: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source | | Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload type | TOS and flow spec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Must be Zero | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Tracy From owner-Big-Internet@munnari.oz.au Wed Sep 30 07:39:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05464; Wed, 30 Sep 1992 07:39:40 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05454; Wed, 30 Sep 1992 07:39:27 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11794>; Tue, 29 Sep 1992 14:38:59 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 29 Sep 1992 14:38:57 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP In-Reply-To: Your message of "Tue, 29 Sep 92 08:47:34 PDT." <9209291547.AA25865@ginger.lcs.mit.edu> Date: Tue, 29 Sep 1992 14:38:43 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep29.143857pdt.10779@skylark.parc.xerox.com> > May I suggest the creation of a separate SIP mailing list? Yes, a sip mailing list is being set up. Until it is, I hope you don't mind if we continue to discuss SIP here. We'll move off the big-noelgram, oops, big-internet list as soon as possible. :-) > BTW, what does the routing and addressing architecture for SIP look > like? SIP uses a conventional hierarchical addressing and routing architecture, just like IP or CLNP. In my original posting, I suggested two addressing hierarchies: a geographical hierarchy and a provider-based hierarchy. Routing is hop-by-hop, using classless, longest-match route lookups. SIP can be handled by the IP suite of routing protocols (e.g., OSPF, RIP-II, BGP4), modified as necessary to carry 64-bit addresses and masks. The geographical (metro-based) addressing & routing scheme imposes some new constraints on the topology and requires some additional mechanism/protocol among providers operating an the same metro area, which I have described in presentations before the ROAD group in Tucson and the NOOP WG at the IETF in San Diego, and on which I have another paper in progress. SIP does NOT depend on the infrastructure for geographical routing being in place -- the provider-based hierarchy can be used instead. Mobility is handled in a way similar to the Columbia proposal for mobile IP, with the addition of a new ICMP message that allows the "triangle routing penalty" to be avoided. The multicast routing architecture is similar to IP multicast, with the addition of an explicit "scope" field in the multicast addresses. > Designing packet formats is a lot of fun, but the real problem with the > current IP is that the routing tables in the routers are about to go blooey, > not that the TTL field is too big or too small, it has an unneeded checksum, > etc. Yes, it's easy to lose sight of the real problems when wrangling over secondary details. However, I assure you that there is a well-thought- out addressing and routing plan behind SIP -- I would not be proposing it just to get rid of fragmentation and checksums in IP. On the other hand, I wish you would refrain from jumping on anyone who wants to discuss other details of packet formats -- the migration to a new internet protocol, though motivated by addressing & routing concerns, offers a rare opportunity to clean up some other, admittedly minor, aspects of IP. Steve From owner-Big-Internet@munnari.oz.au Wed Sep 30 08:27:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07597; Wed, 30 Sep 1992 08:27:29 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07594; Wed, 30 Sep 1992 08:27:19 +1000 (from estrin@jerico.usc.edu) Received: from excalibur.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA22896; Tue, 29 Sep 92 15:26:46 PDT Received: by excalibur.usc.edu (4.1/SMI-3.0DEV3) id AA01265; Tue, 29 Sep 92 14:42:40 PDT Date: Tue, 29 Sep 92 14:42:40 PDT Message-Id: <9209292142.AA01265@excalibur.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@jerico.usc.edu To: big-internet@munnari.oz.au Subject: SIP list Reply-To: estrin@usc.edu One of my graduate students, Chintan Upadhyay, has volunteered to start and maintain a sip mailing list at usc. He will send details about where to send join requests within a couple of days. In the mean time I hope B-I readers will tolerate the SIP traffic. Thanks, D. From owner-Big-Internet@munnari.oz.au Wed Sep 30 08:34:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07986; Wed, 30 Sep 1992 08:34:54 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07974; Wed, 30 Sep 1992 08:34:40 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11805>; Tue, 29 Sep 1992 15:34:27 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 29 Sep 1992 15:34:15 -0700 To: Zheng Wang Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of "Tue, 29 Sep 92 04:43:28 PDT." <92Sep29.044344pdt.11699@alpha.xerox.com> Date: Tue, 29 Sep 1992 15:34:13 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep29.153415pdt.10779@skylark.parc.xerox.com> > Data packets are often protected by upper layer protocols > (sequencing and checksum) but error messages are more > vulnerable. If the source address of a packet is corrupted, > a router may send a "net A unreachable" message to the wrong source > and the wrong source may mark net A unreachable. IP host implementations should take no such action in response to net unreachable or host unreachable messages -- such messages may legitimately occur due to transient routing conditions, and should not be interpreted as having any immediate significance. (See RFC-1122, Host Requirements, last paragraph of section 3.2.2.1.) The only value of those messages is to allow applications, after *repeated* unsuccessful attempts to communicate with a peer, to display a message or create a log entry reporting the *probable* cause of the communication failure. > The corrupted destination address may fall into the multicast > address space. Yes, there is that danger. Note that the type of corruption that turns an entire byte to all-ones is not a problem, because the SIP multicast address format prohibits an all-ones scope value in the first byte. I have thought about prohibiting the use of all those values in the first byte that could be turned into a legal multicast prefix by a single bit error; that would result in some wastage of the address space (5.5%, if I count on the three reserved bits in the flags+scope field always being zero). Steve From owner-Big-Internet@munnari.oz.au Wed Sep 30 08:55:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09026; Wed, 30 Sep 1992 08:56:06 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09015; Wed, 30 Sep 1992 08:55:52 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11809>; Tue, 29 Sep 1992 15:55:25 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 29 Sep 1992 15:55:17 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: lack of checksum field in SIP header In-Reply-To: Your message of "Tue, 29 Sep 92 15:34:13 PDT." <92Sep29.153415pdt.10779@skylark.parc.xerox.com> Date: Tue, 29 Sep 1992 15:55:12 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep29.155517pdt.10779@skylark.parc.xerox.com> Oops. Please ignore this part of what I just wrote: > Note that the type of corruption that turns > an entire byte to all-ones is not a problem, because the SIP multicast > address format prohibits an all-ones scope value in the first byte. The multicast prefix of FF plus the flags+scope field, covers two bytes, not one. (An earlier design had it all in the first byte.) So turning the first byte into all-ones could indeed turn a unicast address into a valid multicast. The rest of what I wrote is still correct, if you change "first byte" to "first two bytes": > I have thought about prohibiting the use of all those values in the > first byte that could be turned into a legal multicast prefix by a > single bit error; that would result in some wastage of the address > space (5.5%, if I count on the three reserved bits in the flags+scope > field always being zero). Now, the odds of corrupting a unicast address into the address of a multicast group *that actually exists* are probably pretty small. Depending on what the routers do with non-existent group addresses, unicast addresses that get turned into multicast address may die before going very far. Steve From owner-Big-Internet@munnari.oz.au Wed Sep 30 09:13:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09822; Wed, 30 Sep 1992 09:13:30 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09819; Wed, 30 Sep 1992 09:13:19 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11810>; Tue, 29 Sep 1992 16:12:56 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 29 Sep 1992 16:12:49 -0700 To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: TOS in SIP In-Reply-To: Your message of "Tue, 29 Sep 92 05:26:37 PDT." <765.bill.simpson@um.cc.umich.edu> Date: Tue, 29 Sep 1992 16:12:40 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep29.161249pdt.10779@skylark.parc.xerox.com> > How about "Well-Known Flows", like ports? The first N could be > reserved, and the rest would be dynamically assigned during flow setup > (either by the source or first hop router). Yes, that has some appeal. I had thought that it might be important to carry *both* a TOS field and a flow-id, so that if packets carrying a flow-id reach a router that does not have the corresponding flow state, the packet could be forwarded according to its TOS instead. So the question is: are TOS and flow-ID orthogonal? > Why such a large number (3 octets)? Surely we don't expect to see > millions of simultaneous connections to the same source? That's a first: someone criticizing one of my fields for being too BIG! :-) > My thought is that for a given Source/Destination pair, the number > is more likely to be very small (<16), allowing for quite a bit of > rollover time even in a single octet. That's another question for the flow experts: should every flow from a single source have a unique flow ID, or need the flow IDs only be unique for a given source-destination pair? Also, does each payload type get its own flow-ID space? My own inclination would be to require flow IDs to be unique per source, independent of destination or payload type, because that would be the simplest to implement in the sources. Steve From owner-big-internet@munnari.oz.au Wed Sep 30 10:24:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12483; Wed, 30 Sep 1992 10:24:55 +1000 (from owner-big-internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09110; Wed, 30 Sep 1992 08:57:40 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA02079; Tue, 29 Sep 92 15:57:19 -0700 Date: Tue, 29 Sep 92 18:08:30 EDT From: "William Allen Simpson" Message-Id: <771.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: TOS in SIP > >On Tue, 29 Sep 92 08:26:37 EDT William Allen Simpson said: > >>My thought is that for a given Source/Destination pair, the number > >>is more likely to be very small (<16), allowing for quite a bit of > >>rollover time even in a single octet. > > > >From: VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) > >Hmm.. I can think of a common case where a source/dest pair has a lot > >of connections - consider a 128-port terminal server talking to a large > >CBX on one side, and a large mainframe that's catching all the connections. > > That's a good example. The servers that I'm familiar with use a separate IP address for each terminal. How else would you keep the sessions separate (using IP4)? If the TCP/UDP port were used instead, you wouldn't need to do resource reservation for each connection separately, just once for the machine, re-reserving when a significant bandwidth change occurred. > From: Paul E. McKenney > I agree wholeheartedly that one octet just does not do it for a large > server machine. Even two octets is cutting it close in this case -- we > frequently get situations where several thousand connections are needed. > I don't understand your example. Several thousand simultaneous connections between the same *two* IP machines? > Suppose that the MSL is 120 seconds. Then a two-octet field can support > an average of at most 546 connections per second. This certainly will not > last for 20 years. A three-octet field can support at most 139,810 connections > per second, which sounds like a lot, but is only 40x (less than six doublings) > of the peak transaction rate seen by the US airline reservation system during > the fare wars last Spring. Might last 20 years, but would not want to bet > the farm on it. If 20 years is really the design goal, four bytes is not > as big as it might seem at first blush! We must be talking about different things. I think you are talking about transactions per second, and I'm talking about resource reservation. For most transactions, only the "well-known" TOS types would be used. Does anyone see a reason why we would expect 500+ end-to-end connection setups and teardowns a second? In which case, we would spend most of our time setting up and tearing down. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Wed Sep 30 11:17:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14432; Wed, 30 Sep 1992 11:17:36 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12579; Wed, 30 Sep 1992 10:26:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06946; Tue, 29 Sep 92 20:26:53 -0400 Date: Tue, 29 Sep 92 20:26:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209300026.AA06946@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Until it is, I hope you don't mind if we continue to discuss SIP here. Oh, no problem, take whatever time is needed, I just got the impression it wouldn't happen unless something was said. SIP uses a conventional hierarchical addressing and routing architecture The hierarchical addressing makes sense, but what exactly is 'heirarchical routing'? Do you mean that routes strictly follow the address hierarchy (I assume not, right)? Routing is hop-by-hop, using classless, longest-match route lookups. SIP can be handled by the IP suite of routing protocols (e.g., OSPF, RIP-II, BGP4) The references to the current suite of IP routing protocols positively dis-impress me, frankly; the current IP routing architecture (such as it is) is a fourth rate confection of scrap iron and tin foil glued together with massive quantities of bubble gum and string. Things like IDPR and BGP have fundamentally different views of the universe and can only be glued together with great difficulty. Perhaps I am wrong, and there is a detailed scheme, but the impression I get is of a substantial lack of formal attention to the real fundmentals of a routing architeture: - what sort of information is distributed about where things are - how - who calculates the routes - how and lack of a definite plan as to how these questions are answered in the overall SIP architecture. However, I assure you that there is a well-thought- out addressing and routing plan behind SIP Addressing, perhaps, but the routing part I would take issue with, if your outline above is accurate. I would not be proposing it just to get rid of fragmentation and checksums in IP. I understand that this is not your goal, and perhaps my examples were not chosen as wisely as they could have been, but they were just examples, merely intended to illustrate my point, which is that the *chief* current problem is with routing, and I hear very little attention being given to the issues of how to route under policy constraints in a very large network. Until that issue is tackled successfully, I will continue to maintain that we are evading the main issue. On the other hand, I wish you would refrain from jumping on anyone who wants to discuss other details of packet formats My apologies to all who are offended, but look at things from my point of view. I can make a rough analogy to a patient who comes in with terminal pneumonia and a small pre-cancerous lump, and the doctors spend all the time worrying about how to treat the lump. If you're a good doctor, looking at this, you have to point out to them that the patient has other, more serious problems which they need to attend to first. Well, I'm just pointing out what I think people ought to be keeping their eye on. I'm actually not at all thrilled to be doing this; I'm really pretty sick of it, frankly. I'd much rather bail out of networking totally, and go off to work on operating systems by myself. It just seems to me that nobody else is saying these things, and that they need to be said, and for a while, at least, I'll keep saying them. the migration to a new internet protocol, though motivated by addressing & routing concerns, offers a rare opportunity to clean up some other, admittedly minor, aspects of IP. I'd like to hear an argument made that will convince Van Jacobsen (and me :-) that we need a new packet format now. I keep maintaining that if we add an endpoint identifier (and there seems to be a certain amount of agreement on this, as much as this list can agree on *anything* :-), the existing packet format can be retained for a while. I think we *can* deploy a new routing and addressing architecture as an adjunct to the current packet layer. Everyone seems to keep making the assumption that we need a new packet format Right Away, and I just don't hear a good argument as to why. Noel From owner-Big-Internet@munnari.oz.au Wed Sep 30 11:52:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15629; Wed, 30 Sep 1992 11:52:46 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.sequent.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15607; Wed, 30 Sep 1992 11:52:14 +1000 (from mckenney@sequent.com) Received: from eng3.sequent.com by gateway.sequent.com (5.61/1.34) id AA05974; Tue, 29 Sep 92 18:51:15 -0700 Received: by eng3.sequent.com (5.65/1.34) id AA29454; Tue, 29 Sep 92 18:52:00 -0700 From: Paul E. McKenney Message-Id: <9209300152.AA29454@eng3.sequent.com> Subject: Re: TOS in SIP To: bsimpson@angband.stanford.edu Date: Tue, 29 Sep 92 18:51:59 PDT Cc: big-internet@munnari.oz.au Priority: normal In-Reply-To: <771.bill.simpson@um.cc.umich.edu>; from "William Allen Simpson" at Sep 29, 92 6:08 pm X-Mailer: ELM [version 2.2 CRG PL14c] >> From: Paul E. McKenney >> I agree wholeheartedly that one octet just does not do it for a large >> server machine. Even two octets is cutting it close in this case -- we >> frequently get situations where several thousand connections are needed. >> >I don't understand your example. Several thousand simultaneous >connections between the same *two* IP machines? Yes. In the example, one of the IP machines was a gateway connecting a LAN to the rest of the world, and the other IP machine was a large server. When ``the rest of the world'' is non-IP, the gateway will often be an application gateway, and all the connections will be between two machines. We have tested over 16,000 connections between a pair of machines in a lab environment. I hasten to add that this example is a fairly unusual arrangement (even for us!). But please keep in mind that 20 years is a long time, at least in the United States. ;-) >> Suppose that the MSL is 120 seconds. Then a two-octet field can support >> an average of at most 546 connectio s per second. This certainly will not >> last for 20 years. A three-octet field can support at most 139,810 connections >> per second, which sounds like a lot, but is only 40x (less than six doublings) >> of the peak transaction rate seen by the US airline reservation system during >> the fare wars last Spring. Might last 20 years, but would not want to bet >> the farm on it. If 20 years is really the design goal, four bytes is not >> as big as it might seem at first blush! > >We must be talking about different things. I think you are talking about >transactions per second, and I'm talking about resource reservation. > >For most transactions, only the "well-known" TOS types would be used. > >Does anyone see a reason why we would expect 500+ end-to-end connection >setups and teardowns a second? In which case, we would spend most of our >time setting up and tearing down. > >Bill.Simpson@um.cc.umich.edu The popular WAIS, Gopher, etc. services use a separate TCP connection for each separate query. In this environment, transactions per second and setup/teardowns per second are identical. This results in quite a few connection setups and teardowns per second, unless actively prevented (e.g., by impassioned pleas for backup servers). If Internet information access really takes off, 500+ end-to-end connections per second will seem quite modest. Especially after 20 years of availability. It might be that the ``well-known'' TOS types you mention would be sufficient for this sort of service. If not, then transactions per second and reservations per second become identical. Thanx, Paul From owner-Big-Internet@munnari.oz.au Wed Sep 30 13:51:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20075; Wed, 30 Sep 1992 13:52:01 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20071; Wed, 30 Sep 1992 13:51:50 +1000 (from estrin@caldera.usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA09326; Tue, 29 Sep 92 20:51:43 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA21912; Tue, 29 Sep 92 20:51:40 PDT Date: Tue, 29 Sep 92 20:51:40 PDT Message-Id: <9209300351.AA21912@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@caldera.usc.edu To: jnc@ginger.lcs.mit.edu Cc: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Tue, 29 Sep 92 20:26:53 -0400 <9209300026.AA06946@ginger.lcs.mit.edu> Subject: Re: SIP Reply-To: estrin@usc.edu Just so Noel does not feel alone in reacting to "button pushing", I will react yet again and say that there are people working on the routing problem and I anxiously await Noels comments on the note i sent re. unified right before Sigcomm in August. .... Although Steve said that SIP routing is assumed to be HBH there is no reason why Unified could not be used for SIP...(and unified includes a source demand routing component). While I am on the subject we posted a spec of SDRP version 1 (we started with the version that does not use setup) as an internet draft if anyone has comments... D. From owner-Big-Internet@munnari.oz.au Wed Sep 30 13:58:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20395; Wed, 30 Sep 1992 13:58:16 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20385; Wed, 30 Sep 1992 13:58:03 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11838>; Tue, 29 Sep 1992 20:57:53 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 29 Sep 1992 20:57:46 -0700 To: Christian Huitema Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP - a summary of the field allocation debate In-Reply-To: Your message of "Tue, 29 Sep 92 08:25:13 PDT." <199209290925.AA06767@mitsou.inria.fr> Date: Tue, 29 Sep 1992 20:57:32 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep29.205746pdt.10779@skylark.parc.xerox.com> > A short hand definition of SIP could be "64 bits IP with useless overhead > removed". Precisely. I like your summary chart, Christian. > * IP**2 would have been 320 bytes; 192, or even 256, is not a bad result. ^^^^^ typo; was meant to be "bits" > * If IP+flow-id are merged, then a total of 16 bits is perhaps adequate, ^^ typo; was meant to be TOS > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload type | Total Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TOS and flow spec | Time to Live | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Destination | > | Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Source | > | Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Not bad. But until we understand how the TOS/flow-ID field works, it's hard to say how many bits it needs. If you're willing to give up half of the Payload Type space, you could set the high-order bit of that field to 1 and call this IP versions 8 to 15; that way you could continue to use all of IP's link-layer encapsulations. :-) Thanks for all of the good feedback. Steve From owner-Big-Internet@munnari.oz.au Wed Sep 30 14:50:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB22631; Wed, 30 Sep 1992 14:51:18 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22611; Wed, 30 Sep 1992 14:50:23 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11848>; Tue, 29 Sep 1992 21:50:06 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 29 Sep 1992 21:50:04 -0700 To: tracym@nsd.3com.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP - a summary of the field allocation debate In-Reply-To: Your message of "Tue, 29 Sep 92 11:19:42 PDT." <199209291819.AA15021@remmel.NSD.3Com.COM> Date: Tue, 29 Sep 1992 21:50:00 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep29.215004pdt.10779@skylark.parc.xerox.com> > I've wondered for some time why we've been assuming that, if there > is to be a header checksum, then it will be 16 bits. All the focus on > 32-bit and larger machines has neglected the possibility of using a simple > 32-bit sum of the header words. One nice property of the 16-bit IP checksum is that it is equally cheap to compute on both big-endian and little-endian machines. The same is not true of a 32-bit sum: you end up having to byte-swap the whole header on one type of machine or the other, which is rather expensive. > I've always hated the TCP psuedo-header, since it made TCP unreasonably > dependent on the particular lower layer. Look at the efforts to define > TCP over CLNP. That's just a result of an inadequate abstraction. The TCP pseudo-header checksum should be thought of as a sum over the packet length value plus the network layer's addressing information, for whatever network layer you are using. In the case of IP, the addressing information is source address, destination address, and protocol; for CLNP, it's the source and destination NSAP addresses. What is the particular difficulty that has been encountered with CLNP? > Why should we make the mistake again of assuming the > psuedo-header implementation for every higher layer protocol? That's not necessarily an assumption of SIP. All SIP assumes is that the higher-layer protocols are able to detect misdelivery and errors in reported packet length. It is perfectly reasonable for a transport header to carry and checksum its own globally-unique transport-entity- identifiers and length field, in which case it does not need to detect corruption of any network-layer fields, and it needs no pseudo-header. (See the VMTP spec, RFC-1045, for an example of such a transport protocol.) All the pseudo-header does is allow some redundancy to be avoided between the transport and network layer headers. > I'd also suggest not only putting destination address before source > address, but leading off the header, in the interests of getting the bits > used for routing as soon as possible. Note that the source address is also used for routing, both for multicast and for per-source flow-state lookup. Several people have pointed out the possibility of doing cut-through forwarding if the destination address comes first. For anything more complex than a 1x1 switch, I'll be so bold as to claim that the only form of cut-through forwarding that makes any sense for an internet router is the kind supported by ATM, where a switch can start forwarding the leading cells of a packet before the last cell has arrived. As long as the SIP header all fits into the first cell, I don't believe it matters much what order the individual fields of the header are in. Thanks for the comments, Tracy. Steve From owner-big-internet@munnari.oz.au Wed Sep 30 15:06:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23131; Wed, 30 Sep 1992 15:08:00 +1000 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18413; Wed, 30 Sep 1992 13:07:51 +1000 (from kre) To: mandrews@alias.com (Mark Andrews) Cc: prue@ISI.EDU (Walter Prue), deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of Tue, 29 Sep 92 09:23:42 -0400. <9209291323.AA10717@dino.alias.com> Date: Wed, 30 Sep 92 13:07:43 +1000 Message-Id: <8048.717822463@munnari.oz.au> From: Robert Elz Date: Tue, 29 Sep 1992 09:23:42 -0400 From: mandrews@alias.com (Mark Andrews) Message-ID: <9209291323.AA10717@dino.alias.com> If SIP was to adopt the (optional) checksum field that Robert Elz was talking about the other day, could you still do what Walt suggests? Would you not first want to receive the entire packet and perform the optional checksum before deciding on the routing? I don't think anyone is suggesting checksumming the entire packet - its just a header checksum. If your router wants to validate the checksum before using the header, then it would need to wait until the entire header has been received. However, there's no need to do it that way, you can start the routing, and do the header validation in parallel (and abort transmission if the checksum fails), or only bother to calculate the checksum at all if routing the packet fails for some reason (so you can send back a sensible failure message). Keeping (some kind of) checksum field is important so that those options all remain open to the router. kre From owner-Big-Internet@munnari.oz.au Wed Sep 30 17:40:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28118; Wed, 30 Sep 1992 17:41:04 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28089; Wed, 30 Sep 1992 17:40:02 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11850>; Wed, 30 Sep 1992 00:39:37 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Wed, 30 Sep 1992 00:39:28 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of "Tue, 29 Sep 92 17:26:53 PDT." <9209300026.AA06946@ginger.lcs.mit.edu> Date: Wed, 30 Sep 1992 00:39:19 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Sep30.003928pdt.10779@skylark.parc.xerox.com> > The hierarchical addressing makes sense, but what exactly is 'heirarchical > routing'? What's hierarchical routing??! Noel, you ignorant slut! If you don't know what hierarchical routing is, you're not worthy to lick a router's bits. Go away and study the elementary routing literature (Kleinrock and Kamoun, "Hierarchical routing for large networks; performance evaluation and optimization", Computer Networks, 1:155-174, 1977, would be a good start), and then take a look at OSPF and IS-IS -- maybe you've heard of them? -- for examples of hierarchical routing protocols (albeit, only supporting two levels of hierarchy); until then, don't waste our time -- the grown-ups are trying to get some work done here. (So, have I got the proper debating style down right?) (For those who are of a different culture or generation, *please* don't berate me for the "ignorant slut" remark -- it's American Boomer argot.) > ...the *chief* current problem is with routing, and I hear very little > attention being given to the issues of how to route under policy > constraints in a very large network. The *chief* current problem with routing is *scaling*, not lack of *policy* machinery! If you want to work on policy routing, that's fine, but we have an immediate engineering problem of how to let the Internet grow bigger -- seems there are lots of people who want to join the Internet, regardless of it's support for policy constraints. Fortunately, the engineering solution is quite straightforward: add more levels of hierarchy to the addresses, above the "network" level, and then exploit that hierarchy in the inter-domain routers to reduce routing table size, while supporting continued and increasing growth in number of end-user domains. To the extent that "the current IP routing architecture (such as it is) is a fourth rate confection of scrap iron and tin foil glued together with massive quantities of bubble gum and string," it's because there is *too much* policy intervention (in the form of static tables in various boundary routers) in what could otherwise be the smooth operation of conventional, hierarchical, hop-by-hop routing protocols. > Things like IDPR and BGP have fundamentally different views of the > universe and can only be glued together with great difficulty. Who said anything about IDPR? With apologies to Martha, I don't consider IDPR to be part of the current Internet routing architecture. It may well become so, some day, but the SIP proposal certainly does not depend on that being the case. Now, to the degree that IDPR is a link-state inter-domain routing protocol that can be used to compute routes for hop-by-hop forwarding, it may in fact be preferable to BGP, which is burdened with expensive policy baggage. Even better might be simply to add a few more levels of hierarchy to OSPF, and use that for inter-domain routing. In case you haven't guessed, "policy-based routing" is one of my hot buttons, and I'd better stop flaming about that now, or I'll lose all the points I got with Deborah for including a source routing mechanism in SIP. > I'd like to hear an argument made that will convince Van Jacobsen (and me :-) > that we need a new packet format now. I keep maintaining that if we add an > endpoint identifier (and there seems to be a certain amount of agreement on > this, as much as this list can agree on *anything* :-), the existing packet > format can be retained for a while. I think we *can* deploy a new routing and > addressing architecture as an adjunct to the current packet layer. Everyone > seems to keep making the assumption that we need a new packet format Right > Away, and I just don't hear a good argument as to why. I'd like to hear more than handwaving arguments from you about nebulous new routing and addressing architectures, which you can't explain concretely enough for anyone else to understand, but to which you expect the rest of us commit the future of the Internet. There is a straightforward solution to the Internet scaling problems that involves increasing the address size and, hence, changing the packet format, which uses existing, well-understood (by everyone except you, apparently) routing technology. If you have a better way to solve the scaling problem that can be developed and deployed before the Internet melts down, let's see your protocol spec or algorithm description or whatever it is that will allow us to judge for ourselves. So there. Steve From owner-Big-Internet@munnari.oz.au Wed Sep 30 18:49:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00525; Wed, 30 Sep 1992 18:50:05 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00513; Wed, 30 Sep 1992 18:49:54 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Wed, 30 Sep 92 01:49:36 -0700 Date: Wed, 30 Sep 92 01:49:36 -0700 From: Tony Li Message-Id: <9209300849.AA24950@lager.cisco.com> To: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: SIP To the extent that "the current IP routing architecture (such as it is) is a fourth rate confection of scrap iron and tin foil glued together with massive quantities of bubble gum and string," it's because there is *too much* policy intervention (in the form of static tables in various boundary routers) in what could otherwise be the smooth operation of conventional, hierarchical, hop-by-hop routing protocols. The existing policy mechanisms, crude tho they may be, are there to address the unforunate reality that this is a political world we live in, complete with AUP's, fussy folks who want to route their packets in certain directions and other folks who are not willing to use their bandwidth to provide routing for neighbors. As such, there is no "smooth operation" _ever_ possible in inter-domain routing. So I would suggest that the real problem is to scale the Internet while still being able to maintain contact with reality. Now, to the degree that IDPR is a link-state inter-domain routing protocol that can be used to compute routes for hop-by-hop forwarding, it may in fact be preferable to BGP, which is burdened with expensive policy baggage. Steve, you ignorant slut! ;-) BGP carries NO expensive policy baggage. In contrast, IDPR has the wonderful property that it floods your policies througout the ENTIRE world. I believe that you have your comparison _exactly_ backwards. So There. Nyah! Tony From owner-Big-Internet@munnari.oz.au Wed Sep 30 18:57:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00728; Wed, 30 Sep 1992 18:58:10 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00718; Wed, 30 Sep 1992 18:57:43 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA08924; Wed, 30 Sep 1992 09:58:23 +0100 Message-Id: <199209300858.AA08924@mitsou.inria.fr> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au Subject: Re: TOS in SIP In-Reply-To: Your message of "Tue, 29 Sep 92 18:08:30 EDT." <771.bill.simpson@um.cc.umich.edu> Date: Wed, 30 Sep 92 09:58:20 -0500 From: Christian Huitema X-Mts: smtp >> From: Paul E. McKenney >> I agree wholeheartedly that one octet just does not do it for a large >> server machine. Even two octets is cutting it close in this case -- we >> frequently get situations where several thousand connections are needed. >> >I don't understand your example. Several thousand simultaneous >connections between the same *two* IP machines? Resource reservation is very likely to be used in conjunction with some form of source routing. The assumption that flows are identified by the tuple may break in this case, when is in fact always , and when is almost always the same . These flows will require in practice to be identified by . The space must thus be big enough to identified all flows for which ressources have been reserved from a given host towards a given route. Note that there is no particular need to perform resource reservation for each and every connection, transaction, session, you-name-it. It may be quite reasonable to reserve a bulk of resources for one particular host on one particular route, and to let end to end procedures sort out the resource sharing between the various transactions. I hope the ATM model has not yet achieved the same brain washing effect as the OSI model! This may be also a requirement to take into account in the design of the encapsulation protocol. If you are using source routing to multiplex several flows onto different trunks using different resource reservations, then it will be useful to change not only the payload type + next destination at each "decapsulation", but also the flow-id. Christian Huitema