From owner-Big-Internet@munnari.oz.au Thu Jul 1 06:40:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10274; Thu, 1 Jul 1993 06:41:33 +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 AA10268; Thu, 1 Jul 1993 06:40:48 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA07487; Wed, 30 Jun 93 16:36:09 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA13083; Wed, 30 Jun 93 16:40:51 EDT Date: Wed, 30 Jun 93 16:40:51 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9306302040.AA13083@cabernet.wellfleet> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: where in the world is that router...? for a variety of reasons, i believe all IPng routers should have GPS receivers in them: 1. you could auto-configure geographic based addressing Jon; According to my understanding of geographic addressing, this does not actually work. Geographic addressing does *NOT* give a router an address based on where it is physically. Rather, it gives a router (and hosts) an address based on where its network is attached to the public service provider. Back when I worked for a large multinational computer company, I was located in Littleton MA, with a workstation (connected to local networks, which were connected to routers, ...) which was on a private network whose main attachment to a public service network (actually BARnet) was in Palo Alto. If you gave such a workstation an address based on where it is geographically, then the address will have nothing to do with where it is in the network topology. Thus the public network connection in Palo Alto would need to list an enormous long list of very small areas or even individual workstations in its routing updates sent to the public network. A couple of years ago I asked Steve Deering how this would work, and after some delay got the very reasonable answer that my workstation in Littleton would need a Palo Alto geographic address. Thus GPS doesn't help in this situation. At the risk of digressing a bit: you might also note from this example that the same private network had (and probably still has) a secondary connection on the east coast. Thus we have an issue, does the east coast workstation get an address based on the closest connection to a public service provider, or based on the primary connection to a public service provider? Geographic addressing in this case (where the two public service providers involved are located in different geographic areas) has the exact same issues as provider based addressing does (assuming connections to two different providers). This is part of a logical dualism: Geographic based addressing is convenient if you have connections to multiple providers in the same geographic area; provider based addressing is convenient if you have connections in multiple places to the same provider. Geographic addressing constrains the topology by requiring that all providers which serve a particular area be interconnected directly (or make special arrangements to route to each other); similarly provider based addressing assumes that any one provider will be internally connected (or make special arrangements to allow different parts of the same provider's network to route to each other). There is no free lunch here. Your other issues are of course independent, and I am probably not the best person to comment on them (especially the security issues). Ross From owner-Big-Internet@munnari.oz.au Fri Jul 2 18:22:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14886; Fri, 2 Jul 1993 18:22:33 +1000 (from owner-Big-Internet) Return-Path: Received: from mwassocs.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14870; Fri, 2 Jul 1993 18:22:03 +1000 (from whyman@mwassocs.demon.co.uk) Date: Fri, 2 Jul 93 09:11:47 BST From: Tony Whyman Message-Id: <2270.whyman@mwassocs.demon.co.uk> To: big-internet@munnari.oz.au Reply-To: whyman@mwassocs.demon.co.uk Subject: Addressing and the IPng Selection Process X-Mailer: VE3PZR VIEW DIS V1.01. Lines: 497 In principle, the future internet address plan should not be an issue that distinguishes the various IPng proposals. They all have the same general requirement to address a very large number of hosts in a structured manner, that enables both efficient administration and route aggregation leading to a reduction in the number of routes that each router must handle. However, it is an issue, because some of the proposals have chosen to restrict the address field that they can carry to 64-bits (e.g. SIP and TP/IX), while others do not impose a hard upper limit on the size of the address (e.g. PIP and TUBA). Whether 64-bits is sufficient for future internet development is therefore an issue of major importance in the IPng decision process. If it cannot be demonstrated that 64-bits is sufficient then this argues strongly against the associated IPng proposals. On the other hand, if it can be demonstrated that 64-bits is sufficient, then a strong argument is provided in favour of the lean approach to addressing implied by 64-bits. I have therefore prepared this paper to try and analyse perceived user requirements for future internet addressing and get away from the rather simple statements along the lines of " gosh, 2**64 is a very big number and ..........". DEFINITION OF AN ADDRESS However, it is first worth writing down what I consider an address to be. Although it ought to be obvious, there is considerable mis- understanding about what an address really is, and getting the definition out of the way may save unnecessary arguments elsewhere. Definition: an address is a unique identifier for an entity which, together with an associated routing algorithm can be used to find a path to that entity. I regard that definition as important because it is often forgotten how important the routing algorithm is in determining address structure and allocation. It is very easy to say that with an address field of 2**n bits we can address (meaning identify) 2**n hosts, and if we choose n such that 2**n is bigger than the number of atoms in the universe then we're OK. However, without also specifying the routing algorithm this cannot be substantiated, and experience has generally shown that the more efficient the routing algorithm, the less efficient is the address allocation. PERCEIVED USER REQUIREMENTS The following is what I consider to be the User Requirements for the future internet addressing plan: 1. Addresses must be unique and unambiguous. 2. Administration must be devolved to the lowest level of the address administration hierarchy, wherever possible. 3. Users must be able to be responsible for assigning addresses to the systems that they own without any reference to a superior registration authority following the initial assignment of a portion of the address space. 4. Users must be able to interconnect their networks both directly and via multiple service providers without requiring the assignment of distinct alias addresses for each interconnection scenario. 5. The number of routes that each user needs to know about must be minimised. 6. Multi-homed and Mobile Hosts must be supported. 7. Multicast addressing must be supported. 8. Service Provider Charging Policies must be able to reference the address structure in order to publish a tariff that includes differential charging by destination address in a manner that is clear to the non-technical user. 9. Users assigned addresses under the internet addressing plan must have a mechanism that permits them to communicate with users that have addresses assigned under other addressing plans. ROUTING ALGORITHM ASSUMPTIONS I do not believe that in order to lay down the overall addressing plan, it is necessary to know in full detail the exact routing algorithm(s) that will be used in the future internet - although the actual address assignment to hosts will need to take into account the effective routing algorithm. However, it is necessary to make certain assumptions about the routing algorithms in order to develop an addressing plan, and, indeed, once a plan is agreed and implemented, the routing algorithm(s) must conform with those assumptions. I intend to make the following assumptions: 1. For the purposes of routing, the address comprises an upper part (prefix) and a lower part (stub). The routing function then starts by inspecting the prefix. 2. Routing on the upper part is by comparison of the prefix with address prefixes that characterise known routes. The selected route, if any, being that characterised by the longest match of upper part of the destination address against the address prefixes that characterise the available routes. 3. When the upper part of the address matches a prefix that characterises the "local area" then further routing takes place on the address stub. 4. The stub is considered to be either a single identifier or structured into a hierarchical list of identifiers. In principle, routing on the stub is by simple table lookup, taking the identifiers in the order that they appear, until a decision is made on what to do with the packet. Each lookup returns either the local identifier of a network attached to the router and an address on that network to which the packet must be sent, or identifies another table in which to look up the next identifier in the list, or an indication that the address does not exist. The above assumptions are intended to be in line with CIDR and the anticipated development of internet routing, and are also valid for OSI routing. Under the above assumptions, existing IP routing may be considered as assuming that an address consists entirely of the stub. REQUIREMENTS ANALYSIS The first three requirements are about administration of the addressing plan. In order for addresses to be unique and unambiguous with devolved administration, then address allocation must be hierarchical. There need to be multiple address allocation authorities, with each such authority responsible for a portion of the total address space. An address allocation authority may assign addresses from its address space and further subdivide its address space up into smaller address spaces for which responsibility is assigned to subordinate address allocation authorities. At the top level, there may either be a single address allocation authority or the addressing plan must itself identify the top level addressing authorities and assign each a portion of the overall address space. INTERCONNECTION The fourth requirement is essential for both useability and for ensuring effective competition in the provision of internet services. Generally, users will not happy if they have to maintain large numbers of alias addresses, and even less happy if choosing one alias results in lower network costs that choosing another i.e. choosing the wrong one costs money. Furthermore, if the choice of address does affect the choice of route then there are clear implications for competition in service provision, as inertia, order of addresses in directories, etc., may all make it more difficult for a new service provider to establish themselves. The implication of the fourth requirement is that each "user", whether that be a large organisation, or a small one, is identified by an address prefix i.e. any routing via the address stub takes place solely within an organisation. To see why this needs to be so, consider the example of a PABX. In the telephone network, routing follows the same hierarchical routing strategy implied by routing using the stub portion of an address. If a PABX is attached to more than one telephone company, or has direct lines to another organisation's PABX, then additional access codes are usually used in front of the telephone number to select the telephone company/direct line. Effectively, alias addresses are created, with the choice of route dependent on the alias selected by the end user. On the other hand, if the PABX was programmed to compare a dialled telephone number against a list of telephone number prefixes and then select the telephone company/direct line according to matches on this list, then an organisational policy can be applied; the end user dials a number and the least cost route automatically selected without any end user involvement. The same principles apply to routing in data networks, and the fourth requirement can only be met from routing via address prefixes. ROUTE AGGREGATION The fifth requirement for minimal routing knowledge adds a further dimension to this. Simple hierarchical assignment of address prefixes can meet the fourth requirement. However, the fifth requirement implies a relationship with the network topology. CIDR, for example, meets this requirement through provider relative addresses, and the aggregation of routes to all users served by a single provider. However, the shortcoming of this is that when a user is attached to more than one service provider, those providers must all explicitly advertise the route to that user to the rest of the universe. It might be argued that the service provider that allocated the user their address prefix need not advertise the route explicitly. However, the principle of routing to longest match would then disadvantage that service provider. Putting it simply, with provider relative addressing, if too many users attach to multiple service providers, then aggregation ceases to be of any value. A similar problem occurs when a user changes provider but does not change its address. A way out of this problem is to assign addresses from other scopes, such as geographical countries, rather than the scope of a service provider. However, this only leads to effective aggregation if all service providers in, for example, a single country, are interconnected. Otherwise, they cannot each usefully advertise a route to all users within that country. However, interconnection is the most sensitive issue for any provider of telecommunications services and is always closely fought. Simply assuming that all service providers within a single country are interconnected is unrealistic. A more useful approach is probably to consider the internet as consisting of multiple disjoint, overlapping and nested communities. Such communities may be country based, but might also industry related (e.g. financial services), or other geographical (e.g. European Research and Education), or just service provider related (e.g. the customers of ACME Internet Services), or the customers of several interconnected service providers. The idea is that each such internet community has an address prefix associated with them. A user is assigned its own address prefix from a community within which each of its service providers is interconnected. Then service providers need only advertise routes to the communities that they serve. (It should also be noted that any similarity between the concept of an internet consisting of multiple disjoint, overlapping and nested communities and IDRP's concept of Routing Domain Confederations is entirely intentional.) The idea is to take advantage of natural requirements for intercommunication and at the same time provide a strong stimulus to service providers to interconnect in order to serve specific communities. The drawback of this scheme, and probably any other that depends on route aggregation is that users will change their service providers, service providers will argue and stop interconnecting, and, if these events do not result in the re-assignment of addresses then there will be a gradual deterioration in the efficiency of route aggregation. This can only be countered if periodically addresses are changed, where necessary, to reflect the actual network topology. This should not be viewed as surprising or unusual. Telephone companies often have to change subscriber's numbers, as do postal authorities in respect of mail addresses. And, in data networks, one of the most useful aspects of directories is allowing addresses to change while names remain constant. The notion that an address is only assigned (licensed?) for a limited period is one that needs to be accepted. This in turn has implications for address space utilisation, as withdrawn addresses need to be quarantined for a reasonably long period before re-assignment, and, at any given time, a portion of the address space will be unavailable for use. MULTI-HOMED AND MOBILE HOSTS AND MULTICAST ADDRESSES The implications of these requirements are really on the detail of individual routing algorithms rather than addresses. However, as far as addressing is concerned, the concept of the internet community appears to be a useful means for supporting these requirements. For example, if the destinations of a given multicast address are all within a single community then the fact that it is multicast may not even need to be externally visible. More generally, there may, for example, need to be distinct communities for globally mobile systems. CHARGING POLICIES As the internet grows it seems reasonable to assume that increasingly, service providers will operate pay as you go charging policies, with differential charging policies according to how far the packet has to be sent. In order to do this, service providers must be able to publish a tariff card typically relating destination address (prefixes) to cost. This is straightforward enough given routing based on address prefixes with the assignment of prefixes related to communities. However, this has implications for the break points in address allocation. The problem occurs in how address are represented on tariff cards and how easily it is to relate to the tariff card. The existing notation for IP address is very convenient and can be readily adapted to use on a tariff card, and, being a decimal notation, can be readily used by the non-technical user. For such reasons, it should be preferred over hexadecimal notations However, the notation is oriented around octet boundaries. As long as the tariff bands are aligned along octet boundaries, this should not be an issue. However, if they are bit aligned then the reading of a tariff card will become much more difficult. There are considerable useability advantages in the alignment of the natural subdivisions in the addressing hierarchy on octet boundaries. INTERCONNECTION WITH NON-INTERNET USERS The initial reaction to this requirement is probably, why care? However, the requirement does not come from non-internet users who, by definition don't care, but from those internet users that need to communicate with them. Basically, the addressing plan needs to include "escapes" to enable such users to be addressed either on a local or a global basis by internet users without interfering with their communication with the rest of the internet. Such escapes may be no more than some locally significant prefix that implies that the rest of the address is a non-internet address, with local routing mechanisms used to reach it. Alternatively, global escapes might be used which include the identification of another public data network, and an address for that non-internet user on that network. PROPOSED ADDRESS SYNTAX Taking into account the above, there are probably four basic network address syntaxes that need to be accommodated i.e. 1. INTERNATIONAL COMMUNITY: * * 2. REGIONAL COMMUNITY: * * 3. GLOBALLY IDENTIFIED NON-INTERNET ADDRESS 4. LOCALLY IDENTIFIED NON-INTERNET ADDRESS * = occurs zero, one or more times. The need for the first two formats derives from the need to aggregate routes while not requiring a specific topology i.e. users and service providers should interconnect to meet their own requirements, form an internet community and then organise their addresses relative to that community. The formats allow communities to be nested within one another, where that is considered to be practicable. Some such communities will be genuinely international and a single international registration authority will be necessary to allocate their community identifiers. However, many more will be regionally based, and in line with the desirability of devolved administration, it seems correct to also allow for regional registration authorities. However, this is expected to be for administrative convenience, and the aggregation of routes to all communities within a given region is anticipated to be as fortuitous as it is likely. The other two formats come from the need to allow for "escapes" to other addressing plans. Such escapes need to be at the top level of the addressing plan. HOW MANY BITS? While it is not too difficult to develop a general structure for future internet addresses, determining suitable sizes for each field requires more analysis. In principle, the first two bits of an address are sufficient to differentiate these syntaxes, and the could thus be no more the two bits long. However, this would leave no room for other address formats that were found necessary. Furthermore, octet alignment would be desirable for tariff cards. Some will no doubt argue that four bits is the most that should be allocated for the identification of the address format. I would prefer eight on the grounds that this permits greater room for expansion and painless alignment with ISO's NSAP Addressing Plan, which would be very helpful in satisfying requirement nine. EXAMPLE To try and get a feel for the right sizes for the other fields, it's probably worth looking at an example. The example I have chosen is close to home - i.e. how many bits are necessary to address all households in the UK. Firstly, UK Households are probably best viewed as a regional community within Europe. The identifiers for regional communities may reasonably be organised first by continent and then by states/regions. However, states should not be nested within regions, as this would not permit separate regional communities, distinct from individual states. The number of states within Europe seems to be getting larger by the day. There are probably about forty now. In addition, there are natural regions such as the EC, Benelux, the Nordic countries. From this it is reasonable to conclude that six to seven bits are the minimum for identifying states/regions within Europe, and including a continent identifier, nine to ten bits will be necessary. Invoking the desirable octet alignment requirement and the need to identify the different address syntaxes, the first two octets of the address are the minimum that should be regarded as necessary for identifying regional internet communities within a country such as the UK. Domestic households would then be a community within the UK's address space. How many such communities should be allowed for? It's difficult to give a good estimate, 256 is certainly too small. However, as the different communities will be of different size, their identifying prefixes could be of different lengths. As UK Households can be regarded as a large and important community, they could be assigned a one octet community identifier, while allowing other communities to have longer but still unambiguous identifiers. This makes a total of three octets for identifying UK Households as a community. The UK has a population of just under 60 million. The number of households is about 25 million. Thus 25-bits can identify all UK Households within their community. However, simply assigning each house a unique identifier is not going to give any opportunity for route aggregation, and I very much doubt whether routers will be available that can handle 25 million or more routes. To address all UK households without overloading routers will require further hierarchical structuring. Forgetting for the moment the problems of multiple service providers, at the very least there will need to be some sort of structure along the lines of the existing telephone network. In order to address individual household, the country will need to be divided up into separate "routing areas". Given the precedent of telephone numbers about 1,000 areas are probably necessary, although as areas will be of differing sizes, a larger area like London could be identified by a one octet identifier, while smaller areas are given a two octet identifier. London has a population of some 7 to 8 million with a high proportion of single occupancy households. An addressing plan will need to assume at least 4 million households within an area such as London. Again some subdivision is necessary probably into about 400 sub-areas with a mean of 10,000 each. To deal with natural variances in the sub-areas, two octet Household identifiers within each sub- area and 1.5 octet sub-area identifiers are the minimum that should be considered. This allows all Households in London to be identified by a 7.5 octet identifier. CONCLUSION I shall finish this paper here. Much more work is necessary to develop a full addressing plan, and, indeed, it must be able to evolve as the internet grows. But look at the above example. At first sight, with a 64-bit address, sixteen hosts could be identified in each UK Household. However, anyone who believes that this justifies a 64-bit address space is deluding themselves. It's a "shoe-horn" job. It's just possible to identify London Households in 64-bit addresses, but only with optimistic assumptions and no allowances for growth, quarantined addresses, or the flexibility that ought to be there in the upper part of the address space. And, a fan-out of sixteen is unlikely to be sufficient for many Households. Also. the example I have chosen is not necessarily the worse case - I would have chosen China or India for that. Even though 64-bits may be sufficient to identify all atoms in the know universe, it is clearly not sufficient to address them. Apart from allowing for a one octet , a more prudent address structure would have allowed for at least one octet for addressing within each Household and probably a three octet identifier within the sub-area, a two octet sub-area identifier, a two octet area identifier, and one and a half octets to identify the community. Making for a twelve octet address. To extrapolate to China or India, would need at least an extra level, making perhaps fourteen to sixteen octets as the minimum size address that should be acceptable. The conclusions for the IPng selection should be obvious. -- Tony Whyman McCallum Whyman Associates Ltd Tel +44 962 735580 FAX +44 962 735581 Internet: whyman@mwassocs.demon.co.uk Compuserve: 100041,315 From owner-big-internet@munnari.oz.au Sat Jul 3 02:03:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02079; Sat, 3 Jul 1993 02:03:56 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307021603.2079@munnari.oz.au> Received: from hadar.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28407; Sat, 3 Jul 1993 00:11:37 +1000 (from ULLMANN@PROCESS.COM) Date: Fri, 2 Jul 1993 10:08 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: whyman@mwassocs.demon.co.uk Cc: big-internet@munnari.oz.au Subject: RE: Addressing and the IPng Selection Process Hi, Interesting, but quite long, chain of reasoning. It seems tenuous in places ... :-) I would like to point out that the households in London are numbered by an operational network today, and it uses a little over 4.6 octets, not 7.5 (44 71 xxx xxxx for some of them). --- A simpler chain might be: Divide the world up into about 100 "countries" (7 bits), each has about 50 million people; divide them (each) into 1000 areas (10 bits), each has 50,000 people, number them (this is local exchange routing; if telco can do it on esssentially every switch in the world, we can do it. Actually: it will be telco that does it ...) (16 bits) and each person wants a local net (8 bits). Total is 41 bits. So reserve (effectively) 6 at the top (use 1/64 of the initial space), use 10 for countries (without worrying about what size they are), 8 for first level division within the country, another 8 for a second level (i.e. 65K areas), 16 for local number, and we still have 16 bits for host addresses for each person. --- This is a somewhat _more_ structure than the telephone system uses today, and the telephone system _works_. --- To forget about the specific breaks between levels for a moment, look at it this way: we want order(10^10) networks. Say we want 2^16 hosts per network, we have 48 bits left. With 4 levels there are average 316 (10^2.5) nets/level/node, we can allocate 12 bits (10^4.2), therefore we need 7.7% assignment efficiency. With 3 levels there are average 2152 (10^3.3) nets/level/node, we allocate 16 bits (10^4.8), we need 3.2% assignment efficiency. With 2 levels there are 100,000 (10^5) nets/level; we allocate 24 bits, efficiency needed is 0.625%. --- We want _fewer_ levels, not more. 3 levels is within our present day technology; we route more than 10^3.3 (i.e. 2K) networks in our one-level backbone today. 2 levels is within our reach, if not quite within our grasp; the backbone is being updated to handle 64,000 network routes; 100,000 is only a little bigger. Structure is fine; but adding in lots of gratuitous structure will indeed cause you to run out of bits real fast. (Look how easily 160 bits can get used up when you start chopping it up on hard boundaries ... AFI+IDI+area+MAC+TSEL :-) By all means choose numbers so we have some nice structural aggregation, and often more levels and smaller tables, but do NOT wire it into the design. --- "provider" should only be in the address when it is the LEC, i.e. your local telco, the people who actually own the physical wire to your site. ---- (enough ranting for one note?) With my best regards, Robert (see RFC1475, RFC1476, draft-ietf-tpix-adplan-01.txt) From owner-Big-Internet@munnari.oz.au Sat Jul 3 02:19:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02650; Sat, 3 Jul 1993 02:20: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 AA02646; Sat, 3 Jul 1993 02:19:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23568; Fri, 2 Jul 93 12:18:31 -0400 Date: Fri, 2 Jul 93 12:18:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307021618.AA23568@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, whyman@mwassocs.demon.co.uk Subject: Re: Addressing and the IPng Selection Process Cc: jnc@ginger.lcs.mit.edu However, anyone who believes that this justifies a 64-bit address space is deluding themselves. It's a "shoe-horn" job. ... Even though 64-bits may be sufficient to identify all atoms in the know universe, it is clearly not sufficient to address them. ... The conclusions for the IPng selection should be obvious. While I agree with the basics of your argument (there are obviously some things I don't like, such as the naming of entities with your "addresses", as opposed to places in the network), I sadly doubt you're going to have any effect. Those who think 64 bits will work will continue to think so, even in the face of what seems to me ample evidence otherwise. We could have a giant debate here, and very few minds would be changed. All I can say is that I expect that the fact that a significant fraction of the community simply does not think 64 bits is enough is going to lead to *very* tough sledding down the road, as far as general acceptance of any of the 64-bit proposals goes. The future is pretty easy to predict. I expect all the various main technical factions (such as SIP, TUBA, etc), each of which simply cannot accept another possibility, for what seem to be good technical reasons (e.g. 64-bit address space limitations), will use the necessary interoperability features of their proposals to actually deploy them all on some reasonably wide scale. The resulting mass of confusion will leave the majority of users unwilling to switch to any of the new proposals. Since the growth issues will still be there, people will take the path of least resistance, which is to keep the existing packet format (IPv4) and deploy NAT boxes. The only remaining interesting question is exactly what addressing and routing scheme the NAT boxes will use amongst themselves to coordinate the routing on the global Internet scale. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 3 05:18:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08734; Sat, 3 Jul 1993 05:19:10 +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 AA08727; Sat, 3 Jul 1993 05:18:54 +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 9579; Fri, 02 Jul 93 15:18:26 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.10 ptf000) with BSMTP id 1191; Fri, 02 Jul 93 15:18:25 EDT Date: Fri, 02 Jul 93 15:04:39 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: where in the world is that router...? To: Jon Crowcroft , big-internet@munnari.oz.au In-Reply-To: <9306300811.15010@munnari.oz.au> Message-Id: <930702.150439.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 30 Jun 93 09:10:59 +0100 you said: >for a variety of reasons, i believe all IPng routers should have GPS >receivers in > >1. you could auto-configure georgraphic based addressing >2. you could timestamp and/or location stamp cryptoi sealed packets >and make it impossibler to spoof being a router unless you could >spoof the delay from there or be there. This really isn't as big a win as you might think. Consider that commercial GPS receivers get a "fuzz" on the location so it's only accurate to some 150 meters or so. Even the military ones with the DES decryption to defuzz only get to within 5-10 meters. The problem here is that all the "interesting" places have multiple routers within 10 meters (anybody know how big physically the UMD 'swamp' is?) You should also look at the NTP mailing list archives regarding nanosecond accuracy of timestamps - you end up having to migrate a lot of stuff into the kernel and/or the device driver. Would kind of be a bummer if in order to guarantee the timestamp is accurate enough, it had to be outside the checksum calculation or similar. And of course, I don't think *ANY* of us would be really thrilled if our T-1 went out to lunch and complained about a "security problem" just because the local telco moved the physical path to a different string of microwave towers.... (This is not to say I am anti-GPS - I've personally been pushing NTP on our campus as the time service of choice - I just don't think that you can use it for 'security based on location'. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Sat Jul 3 09:39:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17110; Sat, 3 Jul 1993 09:40:23 +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 AA17098; Sat, 3 Jul 1993 09:39:57 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA26987 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Fri, 2 Jul 1993 16:38:40 -0700 Date: Fri, 2 Jul 1993 16:38:40 -0700 From: Tony Li Message-Id: <199307022338.AA26987@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Addressing and the IPng Selection Process The only remaining interesting question is exactly what addressing and routing scheme the NAT boxes will use amongst themselves to coordinate the routing on the global Internet scale. I'm not convinced that's even interesting. Every new organization gets a NAT and a single globally unique class C front end. The class C is routed using CIDR. We then encourage existing organizations which are expanding to deploy NAT, reclaim their addresses, and live happily ever after. ;-) Tony From owner-Big-Internet@munnari.oz.au Sun Jul 4 01:08:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16727; Sun, 4 Jul 1993 01:09:12 +1000 (from owner-Big-Internet) Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16715; Sun, 4 Jul 1993 01:08:59 +1000 (from kre@munnari.OZ.AU) Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09318; Sat, 3 Jul 1993 05:34:54 +1000 (from solensky@andr.UB.com) Return-Path: Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA13004; Fri, 2 Jul 93 12:34:47 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA15398; Fri, 2 Jul 93 15:34:44 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA12895; Fri, 2 Jul 93 15:34:43 EDT Date: Fri, 2 Jul 93 15:34:43 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9307021934.AA12895@fenway.andr.UB.com> To: kre@munnari.oz.au Subject: New "growth" charts Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Sun, 04 Jul 1993 01:08:38 +1000 Resent-Message-Id: <26032.741712118@munnari.OZ.AU> Resent-From: Robert Elz Updated growth charts should now be available via anonymous ftp at munnari.oz.au:~big-internet/nsf-netnumbers-9307.ps, as well as a compressed version (".Z") for those who find that more convienent. There are now 13,293 advertised network numbers compared to 5739 at this time last year, representing an annual growth rate of 131.63%. The predicted value of 12,449 nets for July 1 was surpassed in less than a week. The "best-fit" logistic curve though the existing data also continues to accelerate: the curve now levels off at approximately 37.6 million network numbers, compared to about 23.1 million at the end of June and 15729 this time last year. Once again, there's two trend lines on the "Total Networks" charts to give the viewer some idea of how last months' and this months' trend lines compare. The right end of each has also been pushed out an additional year so that IPv4's "drop dead" date, appearing to be sometime in the year 2000, is included in the illustration. I've also taken the packet and byte count numbers that Merit announces through the end of May and fitted them to logistic curves. It's interesting to note that the packet-count curve levels off sooner than the byte-count curve, but I tend to think that it's just a result of having more data available for the former which, due to the low values there, tends to drag down the overall trend line (as opposed to, say, suggesting that packets will get longer in the future). The prediction for August 1 being at 13,502 net numbers (current + 209) suggests that the trend line for the short-term future may still be running on the conservative side. -- Frank From owner-Big-Internet@munnari.oz.au Sun Jul 4 12:00:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14002; Sun, 4 Jul 1993 12:00: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 AA13999; Sun, 4 Jul 1993 12:00:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06563; Sat, 3 Jul 93 22:00:16 -0400 Date: Sat, 3 Jul 93 22:00:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307040200.AA06563@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@cisco.com Subject: Re: Addressing and the IPng Selection Process Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The only remaining interesting question is exactly what addressing and routing scheme the NAT boxes will use amongst themselves to coordinate the routing on the global Internet scale. I'm not convinced that's even interesting. Every new organization gets a NAT and a single globally unique class C front end. The class C is routed using CIDR. Hmm, true. (A class C works for sites which never have more than ~250 hosts communicating offsite at a single point in time, although if you make the internal allocations meaningful pairwise with the one from the far end, instead of the same for all outside sites, you can stretch this a lot; more bookkeeping though.) Of course, there's still the issue of what routing architecture you will use to do policy routing in the Internet; the current single-class architecture isn't going to hack it. I expect the routing wizards can come to some conclusion here without too much strain. OK, shut down Big-I, we can all go home now! :-) Noel From owner-Big-Internet@munnari.oz.au Mon Jul 5 01:00:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07423; Mon, 5 Jul 1993 01:00:18 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307041500.7423@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07412; Mon, 5 Jul 1993 01:00:02 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 4 Jul 1993 15:59:51 +0100 To: Valdis Kletnieks Cc: big-internet@munnari.oz.au Subject: Re: where in the world is that router...? In-Reply-To: Your message of Fri, 02 Jul 93 15:04:39 -0400. <930702.150439.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Sun, 04 Jul 93 15:59:49 +0100 From: Jon Crowcroft >This really isn't as big a win as you might think. Consider that >commercial GPS receivers get a "fuzz" on the location so it's only >accurate to some 150 meters or so. Even the military ones with the DES >decryption to defuzz only get to within 5-10 meters. thabnks for the detailed info - looks like my idea is a "might have been"... aside (only 17% relevance to this list) In this increasingly de-militarised world (economically speaking) I am getting increasinghle annoyed by the prevention of avaialbility of workable securty facilities to everyday folks by incresasingle irelevant agencies - the number of tiems i've been asked by VERY LARGE multinational commercial organisations for advice on privacy and authentication techology for their intyernets only to have to say "so and so wont let you unless you are US or NATO top secret cleared blah blah.." >The problem here is that all the "interesting" places have multiple >routers within 10 meters (anybody know how big physically the UMD >'swamp' is?) sure - we commonly go through 5 hops inside the UK "FIX" about 5 meters across... >You should also look at the NTP mailing list archives regarding >nanosecond accuracy of timestamps - >And of course, I don't think *ANY* of us would be really thrilled if our >T-1 went out to lunch and complained about a "security problem" just >because the local telco moved the physical path to a different string of >microwave towers.... no, but this mecahnism only needs to be used by peple who care about the route their traffic takes...it wouldnt stop packet forwarding for anyone else... >(This is not to say I am anti-GPS - I've personally been pushing NTP on >our campus as the time service of choice - I just don't think that you >can use it for 'security based on location'. ok, but is 'security based on location' still a starter, or am i on a hiding to "nowhere"? jon From owner-Big-Internet@munnari.oz.au Tue Jul 6 00:49:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02672; Tue, 6 Jul 1993 00:52: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 AA02480; Tue, 6 Jul 1993 00:49:13 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11549>; Mon, 5 Jul 1993 07:48:46 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 5 Jul 1993 07:48:29 -0700 To: Kjeld Borch Egevang Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: July IETF: Network Address Translators BOF In-Reply-To: Your message of "Mon, 05 Jul 93 05:32:45 PDT." <9307050832.aa21654@IETF.CNRI.Reston.VA.US> Date: Mon, 5 Jul 1993 07:48:24 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Jul5.074829pdt.12171@skylark.parc.xerox.com> > From: Kjeld Borch Egevang > Subject: July IETF: Network Address Translators BOF > To: IETF-Announce:; > > The address reuse solution is to place Network Address Translators (NAT) > at the borders of stub domains. Each NAT box (typically a router) has a > table consisting of pairs of local IP addresses, used by hosts within > the stub domain when communicating with other hosts within that domain, > and a set of globally unique addresses used by NAT to enable certain > hosts within the stub domain to communicate with hosts outside the stub > domain. The IP addresses inside the stub domain are not globally unique. > The IP addresses used within one stub domain can thus be reused in other > stub domains as local IP addresses. This does not sound like NAT -- no address translation is taking place, according to the description above. This is simply limiting the number of globally-unique addresses available to a site and, hence, the number of hosts within the site that may communicate globally. For a NAT scheme to be a real solution to the address-exhaustion problem, there must be no need for *any* globally unique addresses per site, because 32 bits won't be enough to enable allocation to all the potential sites in the world, given the inevitable inefficiencies of an allocation hierachy. (48 bits, on the other hand, would be enough.) If this BOF is intended to consider NAT solutions seriously, the attendees should be advised to read Van Jacobson's NAT proposal, which doesn't use globally-unique addresses. Steve tion sooner rather than later. Finding such pitfalls may not prevent people from installing NAT (since anyone can do it without coordinating with anyone else), but will at least make the going easier..... PF From owner-Big-Internet@munnari.oz.au Tue Jul 6 02:06:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06083; Tue, 6 Jul 1993 02:07:32 +1000 (from owner-Big-Internet) Return-Path: Received: from rigel.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06056; Tue, 6 Jul 1993 02:06:00 +1000 (from bill.simpson@um.cc.umich.edu) Received: by rigel.acs.oakland.edu (5.65/DEC-Ultrix/4.3) id AA12994; Mon, 5 Jul 1993 12:05:30 -0400 Date: Mon, 5 Jul 93 02:27:04 EDT From: "William Allen Simpson" Message-Id: <1318.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: Addressing and the IPng Selection Process > From: Tony Li > I'm not convinced that's even interesting. Every new organization > gets a NAT and a single globally unique class C front end. The class C > is routed using CIDR. > OK, Tony. I'm an organization. Every other (computer using) member of my family is a separate organization. We each have class C's. How does one class C per person in the world fit CIDR? Particularly since I've moved my class C from Madison Heights MI, to Waterford MI, to Ann Arbor MI, to Chicago, to Boston, to Buffalo NY, all in the past 3 months. I guess I need a class C per (potential) location and connection, eh? Goody! Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Tue Jul 6 04:53:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12093; Tue, 6 Jul 1993 04:53: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 AA12090; Tue, 6 Jul 1993 04:53:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12345; Mon, 5 Jul 93 14:52:48 -0400 Date: Mon, 5 Jul 93 14:52:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307051852.AA12345@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, francis@thumper.bellcore.com, jnc@ginger.lcs.mit.edu, whyman@mwassocs.demon.co.uk Subject: Re: Addressing and the IPng Selection Process Cc: jnc@ginger.lcs.mit.edu I agree that those who think 64 bits is enough will continue to think so, but I think the reason is because, for some set of constraints, they are right. That's true, put enough constraints on and it will work. I just don't happen to like a) the constraints, or b) the cost if the guess (and that's all it is, a guess) that 64 bits is going to be enough is wrong. Among the former are: a) no embedded X.121/E.164/etc addresses, so we will have the IP address assignment and resolution on common-carrier WAN problem with us forever, b) very limited ability to name policy aggregates, because of limited space and flexibility in the address, etc, etc. So if playing around and address assignment effort are not considered to be important aspects of the problem at this point in time, then the 64-bits is enough..... Huh? It's more than just those two. How do you stick an SMDS address into 64 bits, or do you *like* maintaining a separate IP->SMDS address registry? Noel From owner-Big-Internet@munnari.oz.au Tue Jul 6 05:00:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12344; Tue, 6 Jul 1993 05:00:46 +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 AA12341; Tue, 6 Jul 1993 05:00:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12403; Mon, 5 Jul 93 14:59:23 -0400 Date: Mon, 5 Jul 93 14:59:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307051859.AA12403@ginger.lcs.mit.edu> To: deering@parc.xerox.com, kbe@sony.craycom.dk Subject: Re: July IETF: Network Address Translators BOF Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu For a NAT scheme to be a real solution to the address-exhaustion problem, there must be no need for *any* globally unique addresses per site, because 32 bits won't be enough to enable allocation to all the potential sites in the world, ... If this BOF is intended to consider NAT solutions seriously, the attendees should be advised to read Van Jacobson's NAT proposal, which doesn't use globally-unique addresses. Your basic point is well taken, but let's not forget that Van's isn't the *only* potential NAT solution without globally-unique 32-bit addresses; there are whole classes of them! I'm a bit concerned about the lack of an addressing and routing architecture in Van's (other than DNS names, which are hardly suitable as addresses for real routing as they have no topological component). Noel From owner-Big-Internet@munnari.oz.au Tue Jul 6 06:11:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14274; Tue, 6 Jul 1993 06:11:39 +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 AA14271; Tue, 6 Jul 1993 06:11:18 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11612>; Mon, 5 Jul 1993 13:10:51 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 5 Jul 1993 13:10:45 -0700 To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: big-internet@munnari.oz.au, van@ee.lbl.gov Subject: Re: July IETF: Network Address Translators BOF In-Reply-To: Your message of "Mon, 05 Jul 93 10:56:21 PDT." <9307051756.AA10761@hsdndev.harvard.edu> Date: Mon, 5 Jul 1993 13:10:41 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Jul5.131045pdt.12171@skylark.parc.xerox.com> > Can you post a pointer to Van's NAT proposal? Well, I just checked my copy of Van's NAT paper and it has "DRAFT - do not distribute" notices on every page, so clearly it was not helpful for me to suggest that everyone interested in the NAT BOF should read it. Sorry for the teaser. And Noel, the Official NAT Taxonomer, was right: there are a number of variations on the NAT theme that do not require globally-unique 32-bit addresses. Perhaps Noel has some pointers to papers describing those other schemes? Steve From owner-Big-Internet@munnari.oz.au Tue Jul 6 07:25:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16786; Tue, 6 Jul 1993 07:26:09 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307052126.16786@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16782; Tue, 6 Jul 1993 07:25:54 +1000 (from @bronze.bbn.com:jcurran@nic.near.net) Received: from BRONZE.BBN.COM by nic.near.net id aa08800; 5 Jul 93 17:25 EDT To: Noel Chiappa Cc: big-internet@munnari.oz.au, francis@thumper.bellcore.com, whyman@mwassocs.demon.co.uk Subject: Re: Addressing and the IPng Selection Process In-Reply-To: Your message of Mon, 05 Jul 1993 14:52:48 -0400. <9307051852.AA12345@ginger.lcs.mit.edu> Date: Mon, 05 Jul 1993 17:23:22 -0400 From: John Curran -------- ] From: Noel Chiappa ] Subject: Re: Addressing and the IPng Selection Process ] Date: Mon, 5 Jul 93 14:52:48 -0400 ] ... ] That's true, put enough constraints on and it will work. I just don't happen ] to like a) the constraints, or b) the cost if the guess (and that's all it ] is, a guess) that 64 bits is going to be enough is wrong. Noel, It is clear that 64 bits can be enough, with sufficient coordination. The fact that such coordination may not be achieved is not a fault of the design, but simply a usage problem. ;-), /John From owner-big-internet@munnari.oz.au Tue Jul 6 09:57:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22133; Tue, 6 Jul 1993 09:57:17 +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 AA17602; Tue, 6 Jul 1993 07:51:37 +1000 (from van@ee.lbl.gov) Received: by rx7.ee.lbl.gov for big-internet@munnari.oz.au (5.65/1.44r) id AA06799; Mon, 5 Jul 93 14:51:27 -0700 Message-Id: <9307052151.AA06799@rx7.ee.lbl.gov> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Subject: Re: July IETF: Network Address Translators BOF In-Reply-To: Your message of Mon, 05 Jul 93 13:10:41 PDT. Date: Mon, 05 Jul 93 14:51:25 PDT From: Van Jacobson Sigh. The NAT paper still has "DRAFT - do not distribute" because it's very incomplete (about a third of the sections say "TBA"). People are still welcome to look at it. It's available for anonymous ftp from ftp.ee.lbl.gov:.nat/nat.ps.Z. Also, Noel, we have had the discussion about NAT, addressing and routing several times & at one point I thought you were convinced (rank foolishness on my part). I think a strength of the NAT architecture is its interaction with routing: Intra-AD routing gets much simpler since all addresses are `local' to the AD and, since the AD has complete control of its addresses, those local addresses can be chosen to maximize topological content. And the intra-AD routing stays simple and `local' no matter how large the Internet grows or how baroque the inter-AD routing gets. I think this guaranteed simplicity at the lowest, and largest, level of the routing hierarchy is important because the eventual limits to growth will be the complexity seen by end users or end-user service providers. E.g., I'm not worried about how much routing complexity the NSFNet backbone providers have to deal with - that's their job and presumably they know how to do it. But I am worried about how complicated the world looks to "Mom and Pop's Ice Cream and Internet Connections". At the Inter-AD level, NAT simply has no opinion on routing -- it's a separate problem. E.g., if the world decides to use 32 bit AD identifiers, you concatenate the AD's local addresses and the AD identifier & you have a 64 bit unique identifier that looks a lot like a SIP address. Any inter-domain routing that would work with SIP would work here. If you grow out of 32 bit AD identifiers you could either add another level to the NAT hierarchy (say intercontinental, interdomain, intradomain) and keep going without needing to renumber anything or you could re-engineer the intra-domain level with larger identifiers. Either way it would be *completely* invisible to any of the intra-domain hosts and routers. If you take nimrod's view that there shouldn't be any distinction between intra- and inter-AD that's fine too. Just view NAT as if there were global addresses/EIDs/whatever in whatever form you find convenient but, for scalability and simplicity at the bottom levels, these global thingies are kept in an `address server' and hosts use a 32 bit, locally unique alias for the global thingies. Other than the one level of indirection, this is formally identical to putting the global thingies in packets since any point in the network can map the 32 bit identifier to the global thingy any time it wants. So, yes, my NAT proposal didn't contain a routing or addressing architecture. That's a feature, not an oversight. - Van From owner-Big-Internet@munnari.oz.au Tue Jul 6 14:08:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01762; Tue, 6 Jul 1993 14:09:19 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01749; Tue, 6 Jul 1993 14:08:53 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA20346; Tue, 6 Jul 93 00:07:41 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA24461; Tue, 6 Jul 93 00:09:49 EDT Message-Id: <9307060409.AA24461@tipper> X-Really-To: gibbs.oit.unc.edu To: Steve Deering Cc: Kjeld Borch Egevang , big-internet@munnari.oz.au Subject: Re: July IETF: Network Address Translators BOF In-Reply-To: Your message of "Mon, 05 Jul 93 07:48:24 PDT." <93Jul5.074829pdt.12171@skylark.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 Jul 93 00:09:48 -0400 From: Simon E Spero This isn't really NAT, but for some reason this brings a (fairly) simple question to mind... Has anybody done any measurements on what would happen to DNS performance once caching is disabled? If so, were separate measurements taken for just caching top level information? Simon From owner-Big-Internet@munnari.oz.au Tue Jul 6 16:48:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08112; Tue, 6 Jul 1993 16:50:23 +1000 (from owner-Big-Internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08042; Tue, 6 Jul 1993 16:48:13 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA14869; Tue, 6 Jul 1993 08:45:57 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA21716; Tue, 6 Jul 1993 08:45:55 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307060645.AA21716@dxcern.cern.ch> Subject: Re: Addressing and the IPng Selection Process To: jcurran@nic.near.net (John Curran) Date: Tue, 6 Jul 1993 08:45:54 +0200 (MET DST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, francis@thumper.bellcore.com, whyman@mwassocs.demon.co.uk In-Reply-To: <9307052126.16786@munnari.oz.au> from "John Curran" at Jul 5, 93 05:23:22 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1441 >--------- Text sent by John Curran follows: > > -------- > ] From: Noel Chiappa > ] Subject: Re: Addressing and the IPng Selection Process > ] Date: Mon, 5 Jul 93 14:52:48 -0400 > ] ... > ] That's true, put enough constraints on and it will work. I just don't happen > ] to like a) the constraints, or b) the cost if the guess (and that's all it > ] is, a guess) that 64 bits is going to be enough is wrong. > > Noel, > > It is clear that 64 bits can be enough, with sufficient coordination. > > The fact that such coordination may not be achieved is not a fault > of the design, but simply a usage problem. > > ;-), > /John > Such coordination WILL not be achieved, due to a fault in the design of human social, economic, and political behaviour. How can we, after the IPv4 experience, even consider going forward with ANY address format which is not essentially infinitely extensible? Does anybody remember computers with 12 bit addresses, and how people thought moving to 16 bit addresses would be just fine? Did anybody ever find the 640 k limit in MS/DOS a bit annoying? Sorry to be overtly sarcastic, but John's irony might just have been missed. 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 | | PIP, SIP, IPv7, Nimrod, TUBA or anything. | From owner-big-internet@munnari.oz.au Tue Jul 6 22:50:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22807; Tue, 6 Jul 1993 22:50:13 +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 AA20395; Tue, 6 Jul 1993 21:48:12 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 07:48:01 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 07:48:00 EDT Date: Tue, 6 Jul 93 07:48:00 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9307061148.AA15389@tsuchiya.bellcore.com> To: big-internet@munnari.oz.au Subject: new pip transition spec..... Gang, I've put together a new transition plan for Pip. I've been increasingly unhappy with various aspects of IPAE, and so have taken a shot at a different approach. I'm posting this on big-internet because transition is a general concern, and because the approach I've put together (called IPIT, for IP Independent Transition) can be applied to any IPng. IPIT will come out in a few days as an internet draft, but for those who want to see it sooner, a copy can be found at thumper.bellcore.com:pub/pip/docs/pipTransition.txt. I've attached the introductory sections below...... Thanks, PF _______________________________________________ Abstract This document outlines a transition scheme for moving from IP to Pip. While this document discusses Pip in particular, it could be applied to any IPng. The transition scheme discussed here is called IPIT, for IP Independent Transition. It has been developed to address problems with the IPAE transition scheme, after which the previous Pip transition scheme was based. The shortcomings of IPAE stem from its reliance on IP addresses dur- ing the first phases of transition. The result is that IP-only hosts will not be able to talk to IPng hosts after IP addresses have depleted. IPIT allows new Pip systems to talk to IP systems without a globally unique IP address. As a result, IP address depletion is less likely with IPIT, and IP-only hosts will be able to talk to Pip hosts forever. In this sense, IPIT is as much a co-existence scheme as it is a transition scheme. 1. Problems with IPAE I have increasing concerns about IPAE-style transition. There are some aspects of it that are bad for Pip in particular, but I also have a general concern. That is, the transition requires that the large majority of systems are IPng systems at the point in time when IP addresses are no longer unique. When IP addresses are no longer unique, then IPng systems are configured without embedded IP addresses. Without an embedded IP address, an IPng system cannot talk to an IP-only system, because the IP-only system has no way to uniquely identify the IP-only system [1]. If there are very few IP-only systems by the time IP addresses are no longer unique, then the problem is not so bad. I am concerned, how- ever, that it will take the community a very long time to really install IPng. Even with address depletion as a motivating factor towards IPng, it may be that users will choose to do NAT or address reuse rather than install IPng. I am also concerned that the need for IP address assignments in new systems will do nothing to slow the depletion of IP addresses. IPAE-style transition additionally has some bad ramifications for Pip specifically. Having to assign IP addresses to Pip hosts constrains them in several ways. First, the auto-address configuration feature of Pip is less advantageous if an IP address must be manually assigned to the host. Plug-and-play operation is lost. Second, the IPAE scheme implies that packets from an IP host to a Pip host are routed via IP until they happen to reach a Pip router. When the infrastructure is still primarily IP (with a Pip overlay), this will mean that IP packets from IP hosts will travel as IP for most of the path, and are therefore subject to the same limitations as IP. This manifests itself as limiting mobility and limiting provider selection. In our Columbus demo, we realized that we could only achieve one-direction provider selection with IPAE, because the return packets would take the IP path regardless of the path taken by the forward (Pip) packet. When considering demo'ing mobility for the Amsterdam demo, we discovered that the movement from one LAN to another would require a new IP address, and therefore a new Pip ID. Thus, mobility in Pip over the near term is only as good as mobility with IP, which is not very good. So, for all of the above reasons, I am beginning to favor a transition scheme that does not require an IP address in the Pip header. I call the scheme IP Independent Transition, or IPIT. IPIT is more complex algorithmically than IPAE, but I think it is not overly complex. In any event, IPIT has the advantage of immediately freeing Pip from the constraints and limitations of IP. From owner-Big-Internet@munnari.oz.au Tue Jul 6 23:15:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23716; Tue, 6 Jul 1993 23:15:22 +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 AA23701; Tue, 6 Jul 1993 23:15:09 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 09:13:39 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for whyman@mwassocs.demon.co.uk; Tue, 6 Jul 93 09:13:38 EDT Date: Tue, 6 Jul 93 09:13:38 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9307061313.AA15521@tsuchiya.bellcore.com> To: big-internet@munnari.oz.au, francis@thumper.bellcore.com, jnc@ginger.lcs.mit.edu, whyman@mwassocs.demon.co.uk Subject: Re: Addressing and the IPng Selection Process > > > So if playing around and address assignment effort are not considered to > be important aspects of the problem at this point in time, then the > 64-bits is enough..... > > Huh? It's more than just those two. How do you stick an SMDS address into 64 > bits, or do you *like* maintaining a separate IP->SMDS address registry? > I agree that the SMDS/whatever address should be placed in the packet, but I'm not sure that putting it in the address is the right thing to do. With Pip, we *could* put it in the address, but have chosen to put it in an option instead. This has various advantages that I don't want to discuss here but which you can find the the Pip near-term architecture paper.... PF From owner-Big-Internet@munnari.oz.au Wed Jul 7 00:29:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27408; Wed, 7 Jul 1993 00:30:23 +1000 (from owner-Big-Internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27385; Wed, 7 Jul 1993 00:29:59 +1000 (from kasten@ftp.com) Received: by ftp.com id AA14239; Tue, 6 Jul 93 10:28:44 -0400 Date: Tue, 6 Jul 93 10:28:44 -0400 Message-Id: <9307061428.AA14239@ftp.com> To: jcurran@nic.near.net Subject: Re: Addressing and the IPng Selection Process From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, francis@thumper.bellcore.com, whyman@mwassocs.demon.co.uk > ] That's true, put enough constraints on and it will work. I just don't happen > ] to like a) the constraints, or b) the cost if the guess (and that's all it > ] is, a guess) that 64 bits is going to be enough is wrong. > > Noel, > > It is clear that 64 bits can be enough, with sufficient coordination. > > The fact that such coordination may not be achieved is not a fault > of the design, but simply a usage problem. John I vaguely recall a story from the early days of computing -- when they still used vacuum tubes and relays and the like. They built this monster to solve certain classes of problems. These were fairly big hairy complex things that required the machine to chew on the problem for a while (hours maybe). They finished the machine, fired it up, and started it working on the problems. They never solved the problems. It turned out that the MTBF was less than the time it takes to solve the problem. What's the moral of the story I hear you all cry? The moral is that neat technology that is not usable is nothing more than scrap iron (or perhaps scrap paper now). If "sufficient" coordination is "too much" effort, then 64 bits simply will not work. I have not quantified "sufficient" nor have I quantified "too much". -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Wed Jul 7 00:32:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27585; Wed, 7 Jul 1993 00:33: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 AA27492; Wed, 7 Jul 1993 00:32:57 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11671>; Tue, 6 Jul 1993 07:32:23 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 6 Jul 1993 07:32:14 -0700 To: coleman@pandanus.ntu.edu.au (James P H Coleman) Cc: tanstey@pandanus.ntu.edu.au, big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Routing idea - Y-Routing In-Reply-To: Your message of "Tue, 15 Jun 93 20:32:27 PDT." <199306160333.AA02265@pandanus.cs.ntu.edu.au> Date: Tue, 6 Jul 1993 07:32:06 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Jul6.073214pdt.12171@skylark.parc.xerox.com> How would you do multicast forwarding in the Y-Routing architecture? Multicast delivery follows a tree, not a single path. Steve Deering From owner-Big-Internet@munnari.oz.au Wed Jul 7 01:13:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29258; Wed, 7 Jul 1993 01:13:46 +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 AA29249; Wed, 7 Jul 1993 01:13:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16363; Tue, 6 Jul 93 11:12:39 -0400 Date: Tue, 6 Jul 93 11:12:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307061512.AA16363@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, van@ee.lbl.gov Subject: Re: July IETF: Network Address Translators BOF Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Also, Noel, we have had the discussion about NAT, addressing and routing several times & at one point I thought you were convinced (rank foolishness on my part). Convinced of what? You did convince me of a great number of things (including the likely inevitabilty of some form of NAT :-), but I don't recall buying *everything* you said! :-) I think a strength of the NAT architecture is its interaction with routing: Intra-AD routing gets much simpler since all addresses are `local' to the AD and, since the AD has complete control of its addresses, those local addresses can be chosen to maximize topological content. And the intra-AD routing stays simple and `local' no matter how large the Internet grows or how baroque the inter-AD routing gets. I think this guaranteed simplicity at the lowest, and largest, level of the routing hierarchy is important because the eventual limits to growth will be the complexity seen by end users or end-user service providers. I actually don't see that there is a very strong interaction. The basis of all NAT scheme is that the 32-bit quantities in packets are no longer globally unique; surely this implies a looser interaction between allocation of these, and the routing, no? Intra-AD routing may have to manage more data in total, but it's a local problem, distributed discretely over many small regions. By far harder is the problem of inter-AD routing, where the issues of the tradeoff between routing overhead and routing optimality become severe. Inter-AD complexity is not necessarily isolated from the intra-AD arena either, as you seem to suggest, in the case of sites which are multiply connected to the Internet and want to do policy routing, as more and more will be. There's an inevitable leakage of external information into the routing inside the AD, to allow picking the "correct" boundary router. At the Inter-AD level, NAT simply has no opinion on routing -- it's a separate problem. True. However, this implies that a *delployable*, fully fleshed out NAT-class proposal does need an inter-AD routing architecture. Either way it would be *completely* invisible to any of the intra- domain hosts and routers. Not quite true. As I've pointed out, for multiply connected sites, some info has to come in as to what the external situation is, and this is true no matter whether you have a hop-by-hop or flow-setup routing/forwarding paradigm. If you allow the agent creating the mapping from the locally-unique 'address' to the outside to make all the decisions about what boundary router to use, you can pretty much keep it out, true, but I'm not sure how workable that delegation will be in practise. If you take nimrod's view that there shouldn't be any distinction between intra- and inter-AD that's fine too. Just view NAT as if there were global addresses/EIDs/whatever in whatever form you find convenient but, for scalability and simplicity at the bottom levels, these global thingies are kept in an `address server' and hosts use a 32 bit, locally unique alias for the global thingies. This is the model I prefer (to the degree that I like anything to do with having non-globally unique things in packets at all :-), and in fact, the original Nimrod document did mention this as one possibility for handling the exhaustion of the 32-bit space. So, yes, my NAT proposal didn't contain a routing or addressing architecture. That's a feature, not an oversight. Well, leaving it out didn't remove the need for it; we still need one! :-) Noel From owner-big-internet@munnari.oz.au Wed Jul 7 01:38:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00432; Wed, 7 Jul 1993 01:38:28 +1000 (from owner-big-internet) Return-Path: Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25599; Tue, 6 Jul 1993 23:59:58 +1000 (from kasten@ftp.com) Received: by ftp.com id AA13316; Tue, 6 Jul 93 10:00:06 -0400 Date: Tue, 6 Jul 93 10:00:06 -0400 Message-Id: <9307061400.AA13316@ftp.com> To: solensky@andr.ub.com, big-internet@munnari.oz.au Subject: Re: New "growth" charts From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > There are now 13,293 advertised network numbers compared to 5739 at this time > last year, representing an annual growth rate of 131.63%. The predicted value > of 12,449 nets for July 1 was surpassed in less than a week. The "best-fit" > logistic curve though the existing data also continues to accelerate: the > curve now levels off at approximately 37.6 million network numbers, compared > to about 23.1 million at the end of June and 15729 this time last year. I'd like to point out that 37.6 million exceeds what I would imagine to be the maximum that we can squeeze out of the v4 address. To get 37.6 million networks requires over 25 bits of "network number" (leaving less than 7 for the local part). I do not think that CIDR (along with all the other hacks that have been suggested) will get us this :-) I wonder if the routing will last this long? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 table consisting of pairs of local IP addresses, used by hosts within >> the stub domain when communicating with other hosts within that domain, >> and a set of globally unique addresses used by NAT to enable certain >> hosts within the stub domain to communicate with hosts outside the stub >> domain. The IP addresses inside the stub domain are not globally unique. >> The IP addresses used within one stub domain can thus be reused in other >> stub domains as local IP addresses. > >This does not sound like NAT -- no address translation is taking place, >according to the description above. This is simply limiting the number >of globally-unique addresses available to a site and, hence, the number >of hosts within the site that may communicate globally. For a NAT scheme >to be a real solution to the address-exhaustion problem, there must be no >need for *any* globally unique addresses per site, because 32 bits won't >be enough to enable allocation to all the potential sites in the world, >given the inevitable inefficiencies of an allocation hierachy. (48 bits, >on the other hand, would be enough.) If this BOF is intended to consider >NAT solutions seriously, the attendees should be advised to read Van >Jacobson's NAT proposal, which doesn't use globally-unique addresses. Maybe my description isn't clear enough. Let's say the class A network 89.0.0.0 was allocated for NAT. Then we could have lots of independent internets where addresses were 89.x.x.x. If a host in one of these nets should have access to the Internet (the big one) a NAT box should translate the 89.x.x.x source-address to a globally valid Internet- address. The assumption is that only a few of the hosts need to communicate externally and thus a class C address could be used (externally) for 254 such hosts. Packets entering the NAT box from the Internet would have destination-addresses translated to 89.x.x.x. You could do the same thing with a host with two addresses (one or two interfaces), but I don't think that's common. You also have an advantage with NAT as you can easily reconfigure your NAT box if a host should be denied access to the outside world. If global addresses were allocated dynamically from a pool the limit would be 254 simultaneous connections, but then you have the problem with deallocation. If the site is multi-homed the global addresses could be allocated via DNS, but then you have problems if the DNS is down. My goal was to make a simple NAT implementation. It can solve some of our problems here so I would like others to benefit from my experiences. I have heard of Van Jacobsen's NAT proposal and will try to get it (I just found out where to get it from his letter to this mailing-list). -- Kjeld Borch Egevang kbe@craycom.dk Research & Development Voice: +45 44530100 Cray Communications A/S - Denmark Fax: +45 44531415 From owner-big-internet@munnari.oz.au Wed Jul 7 02:23:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01858; Wed, 7 Jul 1993 02:24: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 AA27752; Wed, 7 Jul 1993 00:40:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16274; Tue, 6 Jul 93 10:36:45 -0400 Date: Tue, 6 Jul 93 10:36:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307061436.AA16274@ginger.lcs.mit.edu> To: deering@parc.xerox.com, sob@hsdndev.harvard.edu Subject: Re: July IETF: Network Address Translators BOF Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, van@ee.lbl.gov And Noel, the Official NAT Taxonomer, was right: Gads, a dubiuous honor indeed! How do I decline? Perhaps Noel has some pointers to papers describing those other schemes? I only know of three documented versions (none of which I consider acceptable, although C-NAT is the best of the lot): - S-NAT, by Paul, in which each end-AS has a small globally allocated part of the address space (like the class C thing we just discussed), and the address in the packets in the network between end-AS's is in that range - L-NAT, by Van, in which the globally unique 'name' (I shudder to call them 'addresses' :-) of each host is the DNS name, and a translation from one locally-unique 32-bit address to another occurs at each AS boundary; i.e. there's a path setup process where you go and install all the translations - C-NAT, by Ross, which is a scheme for using CLNP addresses as the address in the packet while it is in the network I don't know offhand where any of them are; they were working documents for the Road group. I did write up a "Taxonomy of NAT variants" for Road, and a copy was eventually sent to this list; I was too lazy to turn it into a real document. If you want to look in the archives, here's the info: Date: Thu, 18 Jun 92 12:16:13 -0400 Message-Id: <9206181616.AA18215@ginger.lcs.mit.edu>. I'll update it (it contains a bunch of references to obsolete stuff like class E addresses) and get it put up for anonymous FTP from munnari. Noel From owner-big-internet@munnari.oz.au Wed Jul 7 02:39:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02423; Wed, 7 Jul 1993 02:39:59 +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 AA27737; Wed, 7 Jul 1993 00:40:02 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 10:37:55 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for kbe@sony.craycom.dk; Tue, 6 Jul 93 10:37:54 EDT Date: Tue, 6 Jul 93 10:37:54 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9307061437.AA15705@tsuchiya.bellcore.com> To: deering@parc.xerox.com, kbe@sony.craycom.dk Subject: Re: July IETF: Network Address Translators BOF Cc: big-internet@munnari.oz.au > > This does not sound like NAT -- no address translation is taking place, > according to the description above. This is simply limiting the number > of globally-unique addresses available to a site and, hence, the number > of hosts within the site that may communicate globally. For a NAT scheme > to be a real solution to the address-exhaustion problem, there must be no Yes, the NAT scheme describe still requires some unique addresses. So, it isn't a *final* solution, but was never meant to be..... > need for *any* globally unique addresses per site, because 32 bits won't > be enough to enable allocation to all the potential sites in the world, > given the inevitable inefficiencies of an allocation hierachy. (48 bits, > on the other hand, would be enough.) If this BOF is intended to consider > NAT solutions seriously, the attendees should be advised to read Van > Jacobson's NAT proposal, which doesn't use globally-unique addresses. > I really didn't mean to open up the possibility of NAT schemes in all their potential complexity, I in no way do I think such a scheme should replace IPng. We propose talking about this particular technique because it buys *some* savings, without requiring any protocol work. The NAT box can be installed completely autonomously, without coordination with any other site. I was hoping a small group of people could go off in a corner and learn some useful things about the simple NAT scheme so that people know the pitfalls. I did not envision a big project for some NAT architecture, and think such a thing is a bad idea..... PF From owner-Big-Internet@munnari.oz.au Wed Jul 7 02:50:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02748; Wed, 7 Jul 1993 02:51: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 AA02730; Wed, 7 Jul 1993 02:50:49 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11615>; Tue, 6 Jul 1993 09:50:23 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 6 Jul 1993 09:50:12 -0700 To: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: new pip transition spec..... In-Reply-To: Your message of "Tue, 06 Jul 93 04:48:00 PDT." <9307061148.AA15389@tsuchiya.bellcore.com> Date: Tue, 6 Jul 1993 09:50:08 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Jul6.095012pdt.12171@skylark.parc.xerox.com> Paul, I have not yet read your IPIT document -- I look forward to doing so on the plane to Amsterdam -- but the following statements in the text you posted to big-internet are incorrect: > The result [of IPAE reliance on IP addresses] is that IP-only hosts > will not be able to talk to IPng hosts after IP addresses have > depleted. Under IPAE, IPv4 hosts will be able to talk to IPng hosts in the same "IP domain" (a subcomponent of the global Internet within which IP addresses can still be allocated uniquely, e.g., a campus or a corporate internet), forever. > That is, the [IPAE] transition requires that the large majority of > systems are IPng systems at the point in time when IP addresses are no > longer unique. The correct statement is that, under IPAE, all systems that need to communicate globally must be IPng-capable by the point in time when IP addresses are no longer unique. It is not at all clear that that is a "large majority of systems", given the fact that many organizations already severely limit the number of systems that they allow to talk to the outside world. > When IP addresses are no longer unique, then IPng systems are configured > without embedded IP addresses. That's not true. The intention is that IPng systems will continue to be assigned low-order 32 bits that can serve as IP addresses within their respective non-global IP domains. This requirement can be relaxed only in "pure IPng" domains. Perhaps this is not made clear in the IPAE document, but I believe I am stating the understanding of the SIP/IPAE working group. Steve From owner-Big-Internet@munnari.oz.au Wed Jul 7 05:39:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09415; Wed, 7 Jul 1993 05:39:36 +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 AA09402; Wed, 7 Jul 1993 05:39:14 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA21955; Tue, 6 Jul 93 15:33:59 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA14665; Tue, 6 Jul 93 15:38:49 EDT Date: Tue, 6 Jul 93 15:38:49 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307061938.AA14665@cabernet.wellfleet> To: ULLMANN@PROCESS.COM Subject: RE: Addressing and the IPng Selection Process Cc: big-internet@munnari.oz.au, rcallon@wellfleet.com I would like to point out that the households in London are numbered by an operational network today, and it uses a little over 4.6 octets, not 7.5 (44 71 xxx xxxx for some of them). Ah, but the phone system has several big "advantages". The local access (the equivalent of NSFNET regionals) are monopolies. The topology is very constrained. Also, the monopolistic structure allows "sufficient coordination" (to use Frank Kastenholz's term) to be much simpler to manage. Just because the phone system uses small addresses externally, doesn't mean that it always uses just one small address internally (for example, 800 numbers have to be mapped to other addresses). The phone system is currently worried about their unfortunately too small address size. I don't think that we would want the operation of the Internet to become substantially more constrained and monopolozed than it is now (unless we have no other choice). Phone calls, when sent internally through the phone system, use systems which are strictly intended for phone operations. Data, on the other hand, is likely to traverse things intended for other purposes (like, phone systems), which use different addressing schemes. Finally, the number of phones that I have in my house is very limited (two phones, one externally visible number). The number of computers which I expect to have in my home in 10 years is much much larger. Ross From owner-Big-Internet@munnari.oz.au Wed Jul 7 06:20:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11060; Wed, 7 Jul 1993 06:20:47 +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 AA11050; Wed, 7 Jul 1993 06:20:08 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22141; Tue, 6 Jul 93 16:15:10 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA14715; Tue, 6 Jul 93 16:08:18 EDT Date: Tue, 6 Jul 93 16:08:18 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307062008.AA14715@cabernet.wellfleet> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: Addressing and the IPng Selection Process Cc: rcallon@wellfleet.com That's true, put enough constraints on and it will work. I just don't happen to like a) the constraints, or b) the cost if the guess (and that's all it is, a guess) that 64 bits is going to be enough is wrong. Among the former are: a) no embedded X.121/E.164/etc addresses, so we will have the IP address assignment and resolution on common-carrier WAN problem with us forever, There is a very important problem lurking in here. The cost of doing a DNS-like address mapping lookup in the router fast path is *delay*, and for high performance routing this is bad (probably means lots and lots of buffering). I have not yet found anyone from a router company (having talked to folks from several companies) who thinks that DNS-style lookups in the fast path is a good idea. One of the really nice things about larger addresses is that at least for some credible scenarios it gives us insurance against having to do long-delay address lookups (we don't know how the Internet will grow, but we do know that it will grow and we need to have the flexibility to handle this). Because of this issue, I am personally gradually coming to the conclusion that *short* addresses might turn out to be a serious problem for very high performance routers. The PIP strategy of allowing additional address parts may work here as well, but we need to have some addressing/routing scheme which allows us to avoid DNS-style lookups. A similar advantage of ES-IS style host to router interactions (as opposed to ARP style) is that this allows routers to know the end system to subnet address lookups a priori, which again eliminates the need for delay/buffering in the fast path. (I think that this advantage is getting copied into all of the IPng proposals, so isn't an issue in making a choice between them). Ross From owner-Big-Internet@munnari.oz.au Wed Jul 7 06:24:23 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11289; Wed, 7 Jul 1993 06:24:41 +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 AA11286; Wed, 7 Jul 1993 06:24:23 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 16:24:05 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for francis@thumper.bellcore.com; Tue, 6 Jul 93 16:24:04 EDT Date: Tue, 6 Jul 93 16:24:04 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9307062024.AA16600@tsuchiya.bellcore.com> To: deering@parc.xerox.com, francis@thumper.bellcore.com Subject: Re: new pip transition spec..... Cc: big-internet@munnari.oz.au > > Paul, > > I have not yet read your IPIT document -- I look forward to doing so > on the plane to Amsterdam -- but the following statements in the text > you posted to big-internet are incorrect: > Yes, you are right. I should have modified my statements to indicate that it was refering to inter-domain communications, not intra-domain. Intra-domain systems will still be able to talk by virtue of re-used 32-bit numbers.... PF From owner-Big-Internet@munnari.oz.au Wed Jul 7 06:26:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11374; Wed, 7 Jul 1993 06:26:47 +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 AA11371; Wed, 7 Jul 1993 06:26:28 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 16:26:17 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for francis@thumper.bellcore.com; Tue, 6 Jul 93 16:26:16 EDT Date: Tue, 6 Jul 93 16:26:16 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9307062026.AA16644@tsuchiya.bellcore.com> To: deering@parc.xerox.com, francis@thumper.bellcore.com Subject: Re: new pip transition spec..... Cc: big-internet@munnari.oz.au Oh, I didn't mention....I'll try to change the intro according to your comments and re-issue..... I look forward to getting more corrections.... :-) (Geeeez, you're getting as bad as Halpern......) PF From owner-Big-Internet@munnari.oz.au Wed Jul 7 07:02:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12924; Wed, 7 Jul 1993 07:02:22 +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 AA12921; Wed, 7 Jul 1993 07:02:06 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11672>; Tue, 6 Jul 1993 14:01:33 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Tue, 6 Jul 1993 14:01:23 -0700 To: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: new pip transition spec..... In-Reply-To: Your message of "Tue, 06 Jul 93 13:26:16 PDT." <9307062026.AA16644@tsuchiya.bellcore.com> Date: Tue, 6 Jul 1993 14:01:21 PDT Sender: Steve Deering From: Steve Deering Message-Id: <93Jul6.140123pdt.12171@skylark.parc.xerox.com> > (Geeeez, you're getting as bad as Halpern......) I take that as a compliment. Thanks! Steve From owner-big-internet@munnari.oz.au Wed Jul 7 13:23:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00540; Wed, 7 Jul 1993 13:24:10 +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 AA12187; Wed, 7 Jul 1993 06:43:28 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 16:43:20 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 6 Jul 93 16:43:19 EDT Date: Tue, 6 Jul 93 16:43:19 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9307062043.AA16775@tsuchiya.bellcore.com> To: big-internet@munnari.oz.au Subject: corrected Pip transition.... Ok, I've posted the revised Pip transition spec (same place, thumper.bellcore.com:pub/pip/docs/pipTransition.txt) Sorry to burden you with this again, but here is there revised intro..... PF ___________________________________________________ Abstract This document outlines a transition scheme for moving from IP to Pip. While this document discusses Pip in particular, it could be applied to any IPng. The transition scheme discussed here is called IPIT, for IP Independent Transition. It has been developed to address problems with the IPAE transition scheme, after which the previous Pip transition scheme was based. The shortcomings of IPAE stem from its reliance on IP addresses dur- ing the first phases of transition. The result is that IP-only hosts will not be able to talk globally to IPng hosts after IP addresses have depleted (they will only be able to talk intra-domain). IPIT allows new Pip systems to talk to IP systems without a globally unique IP address. As a result, IP address depletion is less likely with IPIT, and IP-only hosts will be able to talk to Pip hosts for- ever. In this sense, IPIT is as much a co-existence scheme as it is a transition scheme. 1. Problems with IPAE I have increasing concerns about IPAE-style transition. There are some aspects of it that are bad for Pip in particular, but I also have a general concern. That is, for ubiquitous global packet exchange, the transition requires that the large majority of systems are IPng systems at the point in time when IP addresses are no longer unique. When IP addresses are no longer unique, then IPng systems, at least for the purpose of inter-domain communications, are config- ured without globally unique IP addresses. Without a globally unique IP address, an IPng system cannot talk to an IP-only systems in other domains, because the IP-only system has no way to uniquely identify the IP-only system [1]. If there are very few IP-only systems by the time IP addresses are no longer unique, then the problem is not so bad. I am concerned, how- ever, that it will take the community a very long time to really install IPng. Even with address depletion as a motivating factor towards IPng, it may be that users will choose to do NAT or address reuse rather than install IPng. I am also concerned that the need for IP address assignments in new systems will do nothing to slow the depletion of IP addresses. IPAE-style transition additionally has some bad ramifications for Pip specifically. Having to assign IP addresses to Pip hosts constrains them in several ways. First, the auto-address configuration feature of Pip is less advantageous if an IP address must be manually assigned to the host. Plug-and-play operation is lost. Second, the IPAE scheme implies that packets from an IP host to a Pip host are routed via IP until they happen to reach a Pip router. When the infrastructure is still primarily IP (with a Pip overlay), this will mean that IP packets from IP hosts will travel as IP for most of the path, and are therefore subject to the same limitations as IP. This manifests itself as limiting mobility and limiting provider selection. In our Columbus demo, we realized that we could only achieve one-direction provider selection with IPAE, because the return packets would take the IP path regardless of the path taken by the forward (Pip) packet. When considering demo'ing mobility for the Amsterdam demo, we discovered that the movement from one LAN to another would require a new IP address, and therefore a new Pip ID. Thus, mobility in Pip over the near term is only as good as mobility with IP, which is not very good. So, for all of the above reasons, I am beginning to favor a transi- tion scheme that does not require an IP address in the Pip header. I call the scheme IP Independent Transition, or IPIT. IPIT is more complex algorithmically than IPAE, but I think it is not overly com- plex. In any event, IPIT has the advantage of immediately freeing Pip from the constraints and limitations of IP. From owner-Big-Internet@munnari.oz.au Wed Jul 7 14:02:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02457; Wed, 7 Jul 1993 14:03:17 +1000 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02435; Wed, 7 Jul 1993 14:02:47 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA19289 (5.65c+/IDA-1.4.4); Wed, 7 Jul 1993 00:02:02 -0400 Date: Tue, 6 Jul 93 22:55:29 EDT From: "William Allen Simpson" Message-Id: <1327.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: Addressing and the IPng Selection Process > That's true, put enough constraints on and it will work. I just don't happen > to like a) the constraints, or b) the cost if the guess (and that's all it is, > a guess) that 64 bits is going to be enough is wrong. Among the former are: > > a) no embedded X.121/E.164/etc addresses, so we will have the IP > address assignment and resolution on common-carrier WAN problem with > us forever, > There is a very strange idea here. You actually advocate putting the source and destination IEEE 802/E.164/etc interface number in every packet? I've seen the future, and it's IPX.... > b) very limited ability to name policy aggregates, because of limited > space and flexibility in the address, > Another very strange idea. You want to address each system based on the policy types of connectivity it enjoys? So, I'm using this system (192.138.226.92) as an educational system, a commercial system, a research system, have (at various times) a high speed link, a low speed link, a low cost link, and am allowed into many regional systems, and more commercial and international networks, and have multiple charging methods available for access. Other systems on my local net don't have the same policy, so they'd need separate address aggregates. Roughly (6*6*20*2)! permutation. My calculator won't display the number. No wonder some folks think we need more addresses than the number of hydrogen atoms in the universe. > Huh? It's more than just those two. How do you stick an SMDS address into 64 > bits, or do you *like* maintaining a separate IP->SMDS address registry? > Noel, I'm surprised at you! After all of the lectures on naming versus addressing! Let me put it this way (add the most condescending tone you've ever heard Noel use): I believe we have some agreement that IEEE 802 numbers have no topological relation to the Internet routing and addressing. Therefore, they are *NAMES* of interfaces, not addresses. E.164 (telephone) numbers do not indicate a system (end-point), but *NAME* one interface to a system (the telco attachment), just like IEEE 802 numbers. They have no topological relation to the Internet routing and addressing. I see no real push in the IETF to turn over all of our routing and addressing to the phone companies. The SMDS 60 bit number is also treated like an IEEE 802 number in RFC-1209. The SMDS numbers have no topological relation to the Internet, so they MUST also be treated as *NAMES*, not addresses. X.25 only has a small destination number of 8 bits. ATM must have a very short number, too, since its entire header is 5 bytes. So, the translation mechanisms must already exist, everywhere in the telco infrastructure, and everywhere in the Internet. Finally, in SMDS and X.25 and Frame Relay and every other "foreign" transport, we have to keep a list of all the numbers which we are willing to accept packets from. You trust the phone company to do this for you? Therefore, we have to keep more than a translation registry, we need an entire database of permissions! Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Wed Jul 7 20:04:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17665; Wed, 7 Jul 1993 20:04:20 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17660; Wed, 7 Jul 1993 20:04:04 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA10454; Wed, 7 Jul 93 06:03:54 EDT Date: Wed, 7 Jul 93 06:03:54 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307071003.AA10454@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: FYI on ATM addressing Bill, ATM networks do not put the addresses in each cell, so the 5 octets of cell header don't limit the size of the ATM address as you speculated. There are two flavours of ATM address that appear likely to be widely deployed in the near term. The first is E.164 addresses (i.e. telephone numbers). The second is ATM Private Network addresses from the ATM Forum, which have the same syntax as GOSIP NSAPs but not necessarily with all of the semantics of GOSIP or ISO. Both name interfaces on end systems and both have heirarchy relating strictly to the ATM subnetwork. If you believe that ATM will take over the world and displace all existing Ethernets/Token-Rings/etc, then one might be able to argue that ATM topology is closely related to IP topology. I do not believe that ATM will become quite that universal and I firmly believe that Ethernet is not going away soon. Therefore I gently suggest that we cannot assume that the ATM topology will have much relationship to the overlying IP:TNG topology. One item that TUBA/ISO folks need to keep in mind is that, because ATM Private Network addresses appear to be ISO NSAPs, there is a potentially serious problem if ATM routing information were _partially_ mixed with ISO CLNP routing information. If there is no mixing of ATM and CLNP routing information, I think all is well. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Wed Jul 7 22:28:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23037; Wed, 7 Jul 1993 22:28:51 +1000 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23028; Wed, 7 Jul 1993 22:28:35 +1000 (from Scott_Brim@cornell.edu) Received: from CU-DIALUP-0409.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AB17342; Wed, 7 Jul 93 08:28:17 EDT Message-Id: <9307071228.AB17342@mitchell.cit.cornell.edu> Date: Wed, 7 Jul 1993 09:27:56 -0400 To: Van Jacobson From: Scott_Brim@cornell.edu X-Sender: swb@nr-tech.cit.cornell.edu (Unverified) Subject: Re: July IETF: Network Address Translators BOF Cc: big-internet@munnari.oz.au I don't think we ever wrote down our concerns about Van's NAT in the ROAD meetings, but I recall that it seemed likely to cause "hot spots" where routers would have to keep state information about millions of pairs of interacting end systems. From owner-Big-Internet@munnari.oz.au Wed Jul 7 22:50:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23929; Wed, 7 Jul 1993 22:50:58 +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 AA23921; Wed, 7 Jul 1993 22:50:39 +1000 (from van@ee.lbl.gov) Received: by rx7.ee.lbl.gov for big-internet@munnari.oz.au (5.65/1.44r) id AA09006; Wed, 7 Jul 93 05:50:28 -0700 Message-Id: <9307071250.AA09006@rx7.ee.lbl.gov> To: Scott_Brim@cornell.edu Cc: big-internet@munnari.oz.au Subject: Re: July IETF: Network Address Translators BOF In-Reply-To: Your message of Wed, 07 Jul 93 09:27:56 EDT. Date: Wed, 07 Jul 93 05:50:27 PDT From: Van Jacobson Huh? Not only was this not written down, it was never discussed while I was within hearing distance. And it's wrong. The address binding state in any AD is a small constant multiple of the distinct hosts that enter and/or exit that AD. There is no pair-wise state kept (that would lead to quadratic growth which would be dumb). The state kept in a border router is just a cache of the address binding state kept elsewhere in the AD and the cache size can be as large or small as you want to make it. - Van From owner-big-internet@munnari.oz.au Thu Jul 8 01:21:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29888; Thu, 8 Jul 1993 01: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 AA28901; Thu, 8 Jul 1993 00:54:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24976; Wed, 7 Jul 93 10:54:04 -0400 Date: Wed, 7 Jul 93 10:54:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307071454.AA24976@ginger.lcs.mit.edu> To: Scott_Brim@cornell.edu, van@ee.lbl.gov Subject: Re: July IETF: Network Address Translators BOF Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I recall that it seemed likely to cause "hot spots" where routers would have to keep state information about millions of pairs of interacting end systems. I keep hearing this "unlimited exponential state growth" thing, in a number of contexts (among them flows). It says that the growth in hot spots will be O(N^2), where N is the number of sites in the network. It doesn't make sense to me. Applying this argument to the road network would imply that there are roads which have O(N^2) traffic growth, and that just doesn't happen. Last time I looked, we didn't have any 137-lane highways. You build your networks as a mesh, and the traffic is distributed through many parallel links and switches, so that the load on any individial link or switch grows (semi- :-) manageably. If nothing else, the traffic load through a switch is limited by the *bandwidth* into the switch, and network bandwidths aren't growing at O(N^2). Yes, you can have more flows through a switch, and get O(N^2) flow growth, even with O(N) bandwidth growth, if each flow is *reducing* the amount of traffic it sends (i.e. bandwidth it consumes). However, this is not a plausible traffic pattern. I just don't get it, and if my thinking is wrong, I'd love to hear why. Noel From owner-big-internet@munnari.oz.au Thu Jul 8 02:21:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03204; Thu, 8 Jul 1993 02:21:41 +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 AA01422; Thu, 8 Jul 1993 01:44:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25414; Wed, 7 Jul 93 11:43:57 -0400 Date: Wed, 7 Jul 93 11:43:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307071543.AA25414@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, bsimpson@morningstar.com Subject: Re: Addressing and the IPng Selection Process Cc: jnc@ginger.lcs.mit.edu There is a very strange idea here. You actually advocate putting the source and destination IEEE 802/E.164/etc interface number in every packet? Well, what I said was I wanted to put those physical interface addresses in the internetwork addresses, but as I'm sure you recall, I'm not in favor of putting those addresses in every packet (although they would be in datagram transaction packets, such as DNS lookups). I would rather prefer to see something else (probably an EID, but I'd happy to argue to pros and cons) as the thing which is in most/all (depending on what it is) packets. I know that a lot of people think not putting an "address" in every packet is nuts, but I don't see why. You have a thing in the packet which is not the actual physical address, so you still have to do some magic, but rather than *completely* decouple what's in the packet from the address, and get some useful functionality thereby, you have this thing which is neither fish (a complete address) nor fowl (a flexible name for the host). It reminds me of an NSAP, except it's even less useful. > b) very limited ability to name policy aggregates, because of limited > space and flexibility in the address, You want to address each system based on the policy types of connectivity it enjoys? ... Other systems on my local net don't have the same policy, so they'd need separate address aggregates. Roughly (6*6*20*2)! permutation. My calculator won't display the number. This is not what I'm alluding to at all. I know that some people like the concept of doing policy routing by using different addresses, but I reject that point of view. In fact, for a long time in Nimrod it was *not allowed* to have more than one address for any given interface! (That restriction has since been relaxed for variuous reasons, but doing policy is *not* one of them.) What I was talking about was something different. Let's assume that large, geographically distributes organizations A, B and C all have existing 3-layer addressing heirarchies (i.e. site, network, host). They get together, and set up a usage policy between themselves, and a 4-th level address is assigned to that region of the topology, so that when maps are distributed, the region across which that policy holds can be named *by an address*. This is the kind of thing I'm talking about; use of naming levels in the addressing heirarchy to name 'policy aggregates', and I suspect it's going to get pretty complicated. > Huh? It's more than just those two. How do you stick an SMDS address > into 64 bits, or do you *like* maintaining a separate IP->SMDS address > registry? I believe we have some agreement that IEEE 802 numbers have no topological relation to the Internet routing and addressing. Therefore, they are *NAMES* of interfaces, not addresses. E.164 (telephone) numbers do not indicate a system (end-point), but *NAME* one interface to a system (the telco attachment), just like IEEE 802 numbers. Yes. They have no topological relation to the Internet routing and addressing. I see no real push in the IETF to turn over all of our routing and addressing to the phone companies. Ahhh, I think I didn't say what I meant clearly enough in this message. I don't propose that the address always contain an E.164 address *and not much else* (thereby leaving, it is true, all the routing to the common carriers), but rather that it *often* appear as the low order part of a well-structured internet address, much the same way an 802 number would appear as the low order part. Of course, if you wanted the packet to go the whole way through the common carriers, you could just use the E.164 address, and route the packet to the closest entry point to the common carrier system, but you wouldn't *have* to do that. X.25 only has a small destination number of 8 bits. This is a connection identifier. During call setup, they use a longer telephone number like thing, called an X.121 address (if memory serves). ATM must have a very short number, too, since its entire header is 5 bytes. ATM also has a VC setup, and the header just identifies the VC of the frame through a non-globally unique number (i.e. it gets mapped from hop to hop, if my memory is not malfunctioning again). So, the translation mechanisms must already exist, everywhere in the telco infrastructure, and everywhere in the Internet. I didn't quite follow this? Finally, in SMDS and X.25 and Frame Relay and every other "foreign" transport, we have to keep a list of all the numbers which we are willing to accept packets from. You trust the phone company to do this for you? Therefore, we have to keep more than a translation registry, we need an entire database of permissions! This is an onerous task, certainly, but unrelated to the point I make. The table you speak of is a local matter. On a common carrier SMDS/X.25/whatever network, if the destination physical address does not somehow come "with" the packet, either i) routers connected to the net can get to only a limited number of attached hosts, those which are in their local translation table, or ii) *someone* has to maintain a global directory of translations for that common carrier. Since I consider the first option (the one we are currently using) limiting and painful, it seems we will someday have to tackle the latter, unless we avoid the necessity by providing the destination physical address "with" the packet. Noel From owner-Big-Internet@munnari.oz.au Thu Jul 8 22:21:08 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18893; Thu, 8 Jul 1993 22:21:14 +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 AA18889; Thu, 8 Jul 1993 22:21:08 +1000 (from francis@thumper.bellcore.com) Received: from tsuchiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 8 Jul 93 08:21:01 EDT Received: by tsuchiya.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 8 Jul 93 08:21:00 EDT Date: Thu, 8 Jul 93 08:21:00 EDT From: francis@thumper.bellcore.com (Paul Francis--formerly Tsuchiya) Message-Id: <9307081221.AA19696@tsuchiya.bellcore.com> To: big-internet@munnari.oz.au Subject: pip transition at ietf..... Gang, The new Pip transition scheme (IPIT) will be discussed at the first session of the Pip working group. Since IPIT doesn't necessarily apply to just Pip, SIP or TUBA folks might also want to come by.... PF rom owner-Big-Internet@munnari.oz.au Fri Jul 9 02:12:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28738; Fri, 9 Jul 1993 02:12:44 +1000 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28732; Fri, 9 Jul 1993 02:12:32 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws04.merit.edu by vela.acs.oakland.edu with SMTP id AA08487 (5.65c+/IDA-1.4.4); Thu, 8 Jul 1993 12:12:08 -0400 Date: Thu, 8 Jul 93 10:51:53 EDT From: "William Allen Simpson" Message-Id: <1331.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: network <-> physical addresses > X.25 only has a small destination number of 8 bits. > > This is a connection identifier. During call setup, they use a longer > telephone number like thing, called an X.121 address (if memory serves). > > ATM must have a very short number, too, siFrom owner-Big-Internet@munnari.oz.au Fri Jul 9 21:47:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17440; Fri, 9 Jul 1993 21:47:48 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17433; Fri, 9 Jul 1993 21:47:38 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05428; Fri, 9 Jul 93 07:47:31 EDT Date: Fri, 9 Jul 93 07:47:31 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307091147.AA05428@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: policy based routing Brian, I'm not sure that accounting is sufficient as an alternative to real policy-based routing. For example, my employer would very much like to be able to route traffic based on some security policy and use the RFC-1108 IPSO information as the basis for that policy decision. One of my problems with policy-based routing is that the entity implementing the policy must have some way of authenticating whatever data is used to make the routing decision. If no such authentication is possible or implemented, then users of policy-based routing are just deluding themselves. This relates back to my personal belief that most Internet users don't really want/need confidentiality. Rather most folks really want/need authentication and integrity without confidentiality (which is often cheaper, solves most users security problems, and has fewer legal/export problems associated with it). I personally would be quite happy with authentication-only, though of course my employer wants both authentication and confidentiality. Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Sat Jul 10 00:27:40 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24079; Sat, 10 Jul 1993 00:27:46 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22094; Fri, 9 Jul 1993 23:50:25 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13932; Fri, 9 Jul 1993 15:50:19 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA20345; Fri, 9 Jul 1993 15:50:17 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307091350.AA20345@dxcern.cern.ch> Subject: Re: policy based routing To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Date: Fri, 9 Jul 1993 15:50:17 +0200 (MET DST) Cc: big-Internet@munnari.oz.au In-Reply-To: <9307091147.AA05428@itd.nrl.navy.mil> from "Ran Atkinson" at Jul 9, 93 07:47:31 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 506 Ran, Yes. I think that if we had a clear accounting paradigm and a clear authentication paradigm and a clear confidentiality paradigm, THEN we could evolve a much simpler view of policy routing. You are correct that there would still be a need for policy routing, but it would no longer be trying to satisfy conflicting requirements. Never thought I would use "paradigm" three times in one sentence :-) 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 Sat Jul 10 02:40:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29792; Sat, 10 Jul 1993 02:41:10 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29786; Sat, 10 Jul 1993 02:40:54 +1000 (from hwb@upeksa.sdsc.edu) Received: by upeksa.sdsc.edu (AIX 3.2/UCB 5.64/4.03) id AA14519; Fri, 9 Jul 1993 09:40:45 -0700 From: hwb@upeksa.sdsc.edu (Hans-Werner Braun) Message-Id: <9307091640.AA14519@upeksa.sdsc.edu> Subject: Accounting. To: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Date: Fri, 9 Jul 93 9:40:45 PDT Cc: big-internet@munnari.oz.au In-Reply-To: <9307090640.AA01673@dxcern.cern.ch>; from "Brian Carpenter CERN-CN" at Jul 9, 93 8:40 am >routing but paying. I'd like to suggest that a very serious issue >for the big-internet (and not just for the IPng discussion) is >accounting. > ><< howls of protest from all sorts of people >> > >Yes I know that accounting is boring and that most computer scientists >are allergic to it. However I am reasonably convinced that if we >had an adequate accounting paradigm, we would not need to be concerned >anywhere near as much about policy routing. Brian: I completely agree with your accounting comment (I am not really catching up on B-I, but someone forwarded your note to me). We were working on some short (five pages) writeup lately on some issues related to this subject, which can be FTPed from ftp.sdsc.edu in pub/sdsc/anr/papers/accting.sg.ps.Z. In a nutshell, we are not after some grand'n'glorious accounting scheme that solves every problem in the universe, but ways to make incremental progress from the current situation. There are several reasons for that, not the least of which being inconsiderate behavior by some end-users or applications about how they use the network. At least resource-consumption attribution (accounting) would be nice, with billing a perhaps later application using accounting schema. Hans-Werner From owner-big-internet@munnari.oz.au Sat Jul 10 03:11:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01084; Sat, 10 Jul 1993 03:11:58 +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 AA23997; Sat, 10 Jul 1993 00:26:06 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA02896; Fri, 9 Jul 93 10:20:23 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA16132; Fri, 9 Jul 93 10:25:43 EDT Date: Fri, 9 Jul 93 10:25:43 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307091425.AA16132@cabernet.wellfleet> To: bsimpson@morningstar.com, kasten@ftp.com Subject: Re: Addressing and the IPng Selection Process Cc: big-internet@munnari.oz.au > I *never* want to see *anyone* ever again suggest putting an E.164, > SMDS, IEEE 802 or any other physical network address in every packet > as a IPng requirement. (Bill S.) Well, then you are not going to get what you want. It is true that embedding subnet addresses in IP-level addresses is not feasible with 32 bit (or even 64 bit) addresses. It is also true that embedded subnet addresses is not a sensible solution to *every* routing problem in *every* possible topology. It is also true that it is possible to think up *some* topology in which this does not seem like a good idea. However, embedded subnet addresses are very useful in some specific topologies. Also, as the Internet expands into small businesses and homes, it is quite likely that the specific situation in which embedded addresses are the most useful might account for the vast majority of inter-domain connections in the Internet. If you don't have the capability to embed addresses in those situations in which this is useful, then you are likely to be stuck with an extra level of address mapping, which will add both considerable complexity to the solution, plus considerable delay (which is very bad for high speed routers). Both of these imply expense (both for people time and for equipment). Because of this, people are going to be using embedded addresses in the future (in fact, people are *already* using this, and I am told that it is working very well in the right situations). It seems to me that if I build a network, which is a component of The Internet, then I should be able to structure my portion of the Address in a manner that is best suited to my needs and desires. Granted, in a highly dynamic environment, binding physical and network addresses may be a rather silly thing to do. On the other hand, if I have an essentially static environment, using physical addresses in the network layer could be a win -- for instance, there would be less maintenance and administrative overhead. In short, I do not see how we can dictate to people how they do addressing within their own corners of the world. (Frank) Yes, I agree with Frank. In principle we could *try* to dictate how people do addressing. If we come up with a reasonable addressing scheme, then folks will follow it (although "we" in this context had better include public service providers and probably also router vendors -- we can't expect to dictate an address scheme on the public service providers without consulting with them and expect them to pay any attention). If we come up with an addressing scheme which is too constraining, limits the topologies in which it works well, or which requires convoluted or overly complex mechanisms, then folks aren't going to follow it (especially since there are alternatives on the table that are not excessively constraining). Ross From owner-big-internet@munnari.oz.au Sat Jul 10 13:48:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26829; Sat, 10 Jul 1993 13:49:16 +1000 (from owner-big-internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19585; Sat, 10 Jul 1993 10:20:08 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA08458; Fri, 9 Jul 93 20:20:12 -0400 Date: Fri, 9 Jul 93 20:20:12 -0400 Message-Id: <9307100020.AA08458@worldlink.worldlink.com> From: David Piscitello To: bsimpson@morningstar.com Cc: big-internet@munnari.oz.au Subject: Re: requirements vs. features >I *never* want to see *anyone* ever again suggest putting an E.164, >SMDS, IEEE 802 or any other physical network address in every packet >as a IPng requirement. Never say never. I don't think it's a requirement for IPng, but I do see value in *accommodating* those who think it's useful. From owner-Big-Internet@munnari.oz.au Wed Jul 14 23:27:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24272; Wed, 14 Jul 1993 23:28:09 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307141328.24272@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24249; Wed, 14 Jul 1993 23:27:22 +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 ; Wed, 14 Jul 1993 14:27:06 +0100 To: big-internet@munnari.oz.au Subject: Re: will IPnG support fax? Date: Wed, 14 Jul 93 14:27:03 +0100 From: Jon Crowcroft i know its not april the first, but this isn't entirely a joke wqe'd like to offer distributed fax services so we cxan recipricollay send faxes at local phone rates...but distribute things betwee nthe fax site s by aemail ( a lot of people already do email to fax locally) - all you need is good authenticaiton etc and a means of distribing bills - a bit like the internet accounting problem plus the policy routing problem combined really and really useful:-) jon From owner-Big-Internet@munnari.oz.au Thu Jul 15 00:24:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27432; Thu, 15 Jul 1993 00:24:50 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307141424.27432@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27390; Thu, 15 Jul 1993 00:24: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 ; Wed, 14 Jul 1993 15:23:29 +0100 To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: will IPnG support fax? In-Reply-To: Your message of "Wed, 14 Jul 93 14:27:03 BST." <9307141328.24272@munnari.oz.au> Date: Wed, 14 Jul 93 15:23:26 +0100 From: Zheng Wang >wqe'd like to offer distributed fax services so we cxan recipricollay >send faxes at local phone rates...but distribute things betwee nthe what you really need is a relay to the phone system so you can not only send fax but also ring anyone anywhere at local rate:-) Cheers Zheng From owner-Big-Internet@munnari.oz.au Thu Jul 15 16:51:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03361; Thu, 15 Jul 1993 16:52:04 +1000 (from owner-Big-Internet) Return-Path: Received: from cruskit.aarnet.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03357; Thu, 15 Jul 1993 16:51:52 +1000 (from gih@cruskit.aarnet.edu.au) Received: by cruskit.aarnet.edu.au id AA14867 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Thu, 15 Jul 1993 16:51:38 +1000 From: Geoff Huston Message-Id: <199307150651.AA14867@cruskit.aarnet.edu.au> Subject: Re: will IPnG support fax? To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Thu, 15 Jul 1993 16:51:37 +1000 (EST) Cc: big-internet@munnari.oz.au In-Reply-To: <9307141328.24272@munnari.oz.au> from "Jon Crowcroft" at Jul 14, 93 02:27:03 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 326 Jon, Surely this is a massive diversion in terms of IPng issues. If you're interested in a global fax project I'll send you some details off line - but in terms of the interplay between such application systems and the underlying transport architecture I'd offer the view that the relationship is somewhat marginal. Geoff From owner-big-internet@munnari.oz.au Tue Jul 20 03:56:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26199; Tue, 20 Jul 1993 03:57: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 AA24567; Tue, 20 Jul 1993 03:21:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01763; Mon, 19 Jul 93 13:21:12 -0400 Date: Mon, 19 Jul 93 13:21:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307191721.AA01763@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: N^2 growth in flow state Cc: jnc@ginger.lcs.mit.edu As a result of my brief note about my not believing that the flow state in hot spots will grow at O(N^2) (where N is the number of end-nodes in the network), JMH and I had an offline discussion of this topic which concluded that, as long as the bandwidth requirements of the average flow do not decrease over time (which seems a safe bet; if it did, it would be the only instance I can think of in computers where resource usage went down over time :-), the growth in flow state in any switch is bounded by the growth in bandwidth through the switch. While bandwidths are admittedly going up a lot faster than linearly, they are *definitely* not growing at O(N^2), so we can't have O(N^2) state growth. If anyone out there believes in O(N^2) state growth, I think there ought to be a discussion of this issue on the list. This is a very important point to take into consideration in designing for the future, and most everyone seems to have the idea that it *is* O(N^2) (perhaps in one of those deals where you hear that X is the common wisdom, and accept it without thinking about it), but it almost certainly *isn't*. Fire away! Noel From owner-Big-Internet@munnari.oz.au Tue Jul 20 05:26:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28933; Tue, 20 Jul 1993 05:26:36 +1000 (from owner-Big-Internet) Return-Path: Received: from munin.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28921; Tue, 20 Jul 1993 05:26:20 +1000 (from crawdad@munin.fnal.gov) Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA07478 (5.65c+/IDA-1.4.4 for big-internet@munnari.oz.au); Mon, 19 Jul 1993 14:26:01 -0500 Message-Id: <199307191926.AA07478@munin.fnal.gov> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: N^2 growth in flow state In-Reply-To: Your message of Mon, 19 Jul 93 13:21:12 EDT. <9307191721.AA01763@ginger.lcs.mit.edu> Date: Mon, 19 Jul 93 14:26:00 -0500 From: Matt Crawford I can't prove the state info will grow as N^2, but I can stick a pin in your argument that it won't. To make an extra buck, the switch owner will sell reserved but unused bandwidth on a no-guarantee basis to customers who are willing to let their data "fly standby." The number of standby flows is not bounded by a linear function of the switch bandwidth. Plausible? Convincing, even? Matt Crawford Fermilab From owner-big-internet@munnari.oz.au Tue Jul 20 08:19:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00351; Tue, 20 Jul 1993 08:20: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 AA01816; Tue, 20 Jul 1993 06:36:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03068; Mon, 19 Jul 93 16:35:49 -0400 Date: Mon, 19 Jul 93 16:35:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307192035.AA03068@ginger.lcs.mit.edu> To: crawdad@munin.fnal.gov, jnc@ginger.lcs.mit.edu Subject: Re: N^2 growth in flow state Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu the switch owner will sell reserved but unused bandwidth on a no-guarantee basis to customers who are willing to let their data "fly standby." The number of standby flows is not bounded by a linear function of the switch bandwidth. In other words, you don't think that the average bandwidth requirements are going to go up, right? (If flows are 'standby', they are sending no data at times, thereby decreasing the average bandwidth, right?) Even in that case, wouldn't the negative growth in the average flow bandwidth, Ba, have to be of the same magnitude as the difference in growth between the total switch bandwidth, Bs and the average number of flows (both active and standby), n, (assuming the growth of the latter is larger than the former, which is the assumption). In other words (using the notation G(x) for the growth rate of x), G(Ba) * G(n) <= G(Bs) so, if you really think G(n) is O(N^2), then Ba has to be declining sufficiently quickly so that G(Ba)*O(N^2) <= G(Bs), and since I don't think G(Bs) is anything like O(N^2), Ba is going to have to be going down pretty fast if that inequality is going to continue to hold. Does this really seem plausible? Am I missing something somewhere? Noel From owner-Big-Internet@munnari.oz.au Tue Jul 20 17:36:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25738; Tue, 20 Jul 1993 17:36:42 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307200736.25738@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25729; Tue, 20 Jul 1993 17:36:20 +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 ; Tue, 20 Jul 1993 08:35:41 +0100 To: Matt Crawford Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: N^2 growth in flow state In-Reply-To: Your message of "Mon, 19 Jul 93 14:26:00 CDT." <199307191926.AA07478@munin.fnal.gov> Date: Tue, 20 Jul 93 08:35:37 +0100 From: Jon Crowcroft >To make an extra buck, the switch owner will sell reserved but unused >bandwidth on a no-guarantee basis to customers who are willing to let >their data "fly standby." The number of standby flows is not bounded >by a linear function of the switch bandwidth. >Plausible? Convincing, even? best solution for all data given switches are sized right and poloicy dicates the right share between guaranteed services and un-guaranteed ones (as per train versus car):-) jon From owner-big-internet@munnari.oz.au Wed Jul 21 06:23:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27111; Wed, 21 Jul 1993 06:23:38 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307202023.27111@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25926; Wed, 21 Jul 1993 05:57:57 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6479; Tue, 20 Jul 93 15:57:45 EDT Date: Tue, 20 Jul 93 15:56:43 EDT From: yakov@watson.ibm.com To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: N^2 growth... >If anyone out there believes in O(N^2) state growth, I think >there ought to be a discussion of this issue on the list... I think that a paper I published in January 1993 ACM CCR "Forwarding Database Overhead for Inter-Domain Routing" may help to shed some light on this subject. Yakov Rekhter From owner-Big-Internet@munnari.oz.au Wed Jul 21 16:34:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25715; Wed, 21 Jul 1993 16:34:50 +1000 (from owner-Big-Internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25710; Wed, 21 Jul 1993 16:34:32 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10022; Wed, 21 Jul 1993 08:34:22 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA04260; Wed, 21 Jul 1993 08:34:21 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307210634.AA04260@dxcern.cern.ch> Subject: Gossip To: big-internet@munnari.oz.au Date: Wed, 21 Jul 1993 08:34:20 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 925 Two things I saw in industry newsletters last night, which may interest Big-Internet. 1. (OSN newsletter, July 1993) The European Commission is rumoured to be considering repealing Directive 87/95: the one that makes use of International Standards obligatory in public procurements in the main European economies. 2. (Open Systems Communication, June 1993) The (US) GOSIP Institute is about to publish a White Paper called "Internet 2000". Judging by the report I read, there is a TUBAish flavour in this paper. Comments, flames, etc to rdesjardins@attmail.com please (not me!!!). Anybody wants to cc this to ietf-discuss, do it, but I don't have time in my life for that list :-) 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 | | PIP, SIP, TP/IX, Nimrod, TUBA or anything. Really. | From owner-Big-Internet@munnari.oz.au Wed Jul 21 22:34:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12734; Wed, 21 Jul 1993 22:35:05 +1000 (from owner-Big-Internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12731; Wed, 21 Jul 1993 22:34:47 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA02936; Wed, 21 Jul 1993 14:34:36 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA25490; Wed, 21 Jul 1993 14:34:32 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307211234.AA25490@dxcern.cern.ch> Subject: Re: Gossip To: schow@sun1.interlan.com (Peter Schow) Date: Wed, 21 Jul 1993 14:34:32 +0200 (MET DST) In-Reply-To: <9307211219.AA11660@sun1.nmpd.racal.COM> from "Peter Schow" at Jul 21, 93 08:21:32 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 626 Yeah, I should have specified that this is a new version. Brian >--------- Text sent by Peter Schow follows: > > Brian, > > > 2. (Open Systems Communication, June 1993) > > > > The (US) GOSIP Institute is about to publish a White Paper > > called "Internet 2000". Judging by the report I read, there > > is a TUBAish flavour in this paper. Comments, flames, etc > > to rdesjardins@attmail.com please (not me!!!). > > Dick DesJardins and the US GOSIP Institute published that white > paper last year. I believe it also appeared in the InterOp > newsletter, Connexions. > > Have a good day, > > Pete Schow > > > From owner-Big-Internet@munnari.oz.au Thu Jul 22 01:00:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20592; Thu, 22 Jul 1993 01:00:33 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20588; Thu, 22 Jul 1993 01:00:19 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA04161; Wed, 21 Jul 93 10:56:02 -0400 Date: Wed, 21 Jul 93 10:56:02 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9307211456.AA04161@er.doe.gov> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, yakov@watson.ibm.com Subject: Re: N^2 growth... These discussions seem to be mired in an assumption that where we've been is going to be similar to where we're going. Remember that the original internet and the development to this point is based on a model of cooperating networks with similar purposes. Thus a global routing perspective made sense to think about and "optimal" routing was a meaningful concept. For better or for worse, due to our success we are being impelled into a much more complicated world in which customers', providers' etc views of optimal are likely to be different, policy may matter, billing will be important, etc. In addition, the current net is characterized by a number of multilateral service provision agreements regional - regional, regional - backbone, backbone - backbone Commercially we have the most experience with bilateral agreements. So in the future the environment we're likely to have consisits of a number of internal network routing models which exchange data with a common intra-network routing model but which are completely independant of the intra network model and each other except that they can exchange the right data. From an end-to-end point of view what is required is to determine the sequence of networks to be used to reach the destination host for given policy constraints and given cost constraints. Of course this network path needs to be capable of surviving link outages,... Clearly, for arbitrary interconnection meshes this is a very difficult problem; one important question is what assumptions about the underlying physical and logical structure simplify the problem for the intra network information flow so that it is manageable. For example if all links in a net offer the same TOS, policy matrix, etc then the problem is simpler. Also, if you assume no single point of failure within any of the nets or in interconnection points, i.e. each pair of nets has at least two interconnection points) perhaps the probability of needing to rebuild the internetwork path in the middle of something important is small enough that an inefficient failure recovery mode is feasible. DH From owner-big-internet@munnari.oz.au Thu Jul 22 08:50:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09714; Thu, 22 Jul 1993 08:50: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 AA25842; Thu, 22 Jul 1993 02:54:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16280; Wed, 21 Jul 93 12:54:13 -0400 Date: Wed, 21 Jul 93 12:54:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307211654.AA16280@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu These discussions seem to be mired in an assumption that where we've been is going to be similar to where we're going. ... the original internet ... [was] based on a model of cooperating networks with similar purposes. Thus a global routing perspective made sense to think about and "optimal" routing was a meaningful concept. I agree with your basic point, but I'd put your last thought a little differently. I think that the very homogeneous network encouraged use of solutions which i) assumed that everyone had the same goals, and thus measures of what was "good", and thus ii) could use cooperative, distributed mechanisms to provide needed system-wide functions. (To be frank, given the paucity of more complex mechanisms, a very cooperative network was also a necessity to get the thing off the ground; it was either accept that model, or have nothing.) This shows up not only in routing, but in things like congestion control. In an offline discussion, John Wroclawski of MIT and I were discussing the fact that the Internet is not suffering congestive collapse at the moment mostly because everyone has implement Van Jacobsen's TCP algorithms, not because of mechanisms in the network itself; i.e. it's another cooperative solution. He pointed out that to be stable across the system, and share the bandwidth fairly, not only is it necessary for everyone to use the same algorithmm, but they must use the same parameters, otherwise some user groups will 'freeze out' others; i.e. correct functionality is very dependant on very close system-wide cooperation. Going back to your last sentence again, I still do think we need a global perspective on routing (and all other system wide functions such as congestion control), it just needs to be one that recognizes that different users are going to have different ideas of good, one that make allowances for the more complex mesh of service provision agreements restricting open interconnection, one that is less dependant on extremely close cooperation to function correctly, etc. Without such a global perspective, we will inevitably be lead to a balkanized network, with a proliferation of local standards leading inevitably to much more limited system capabilities though incompatabilities, etc. While it is true that a very "arm's-length" model has been operating in the global voice network, the rigid boundaries and limitations of that system have recently led directly to world-wide attempts to loosen things up. I can speculate that the limitations on the system grew not just from "turf conciousness" between different national entities, but also from the technological limits present at the time the system was set up. As soon as it became feasible to provide a more complex service model, the pressure was on to do so. Can we try and avoid that detour in building the global data network? Noel From owner-big-internet@munnari.oz.au Thu Jul 22 11:37:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15932; Thu, 22 Jul 1993 11:37:42 +1000 (from owner-big-internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11422; Thu, 22 Jul 1993 09:39:18 +1000 (from casner@ISI.EDU) Received: from xfr.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 21 Jul 1993 16:39:11 -0700 Posted-Date: Wed 21 Jul 93 16:38:34-PDT Received: by xfr.isi.edu (4.1/4.0.3-4) id ; Wed, 21 Jul 93 16:38:35 PDT Date: Wed 21 Jul 93 16:38:34-PDT From: Stephen Casner Subject: Re: N^2 growth... To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Message-Id: <743297914.0.CASNER@XFR.ISI.EDU> In-Reply-To: <9307211654.AA16280@ginger.lcs.mit.edu> Mail-System-Version: > John Wroclawski of MIT and I were discussing the fact > that the Internet is not suffering congestive collapse at the moment mostly > because everyone has implement Van Jacobsen's TCP algorithms And the real-time audio and video applications are about to become a serious violation of that cooperative, distributed mechanism. -- Steve ------- From owner-Big-Internet@munnari.oz.au Thu Jul 22 15:04:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25633; Thu, 22 Jul 1993 15:04:35 +1000 (from owner-Big-Internet) Return-Path: Received: from moink.NMSU.Edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25621; Thu, 22 Jul 1993 15:04:18 +1000 (from amolitor@moink.nmsu.edu) Received: by moink.nmsu.edu (5.61/eels); id AA03175; Wed, 21 Jul 93 23:04:03 -0600 Date: Wed, 21 Jul 93 23:04:03 -0600 From: amolitor@moink.nmsu.edu (Andrew Molitor) Message-Id: <9307220504.AA03175@moink.nmsu.edu> To: big-internet@munnari.oz.au Subject: Re: N^2 growth... To remark on the original (I think) issue here, it may well be that O(N^2) is a bit much, but it is growing, and if someone decides that it's growing at O(log(log(N) * sqrt(N))), they're likely to be wrong. Perhaps O(N^2) is a handy upper bound/design goal? Andrew From owner-Big-Internet@munnari.oz.au Thu Jul 22 19:47:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09755; Thu, 22 Jul 1993 19:47:53 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307220947.9755@munnari.oz.au> Received: from haig.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09749; Thu, 22 Jul 1993 19:47:39 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by haig.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Jul 1993 10:47:14 +0100 To: big-internet@munnari.oz.au Subject: x.25 Date: Thu, 22 Jul 93 10:47:12 +0100 From: Jon Crowcroft i am rather surprised no-one has suggested CONS as the IPng all we'd have to do is increase the default max packet size increase the sequence number and window size its got VCs and VC multiplexing, so its just like ATM its got fast select with data, so yu've got datagrams its got X.121 adsdresses which are 14 hexadecimal digits and therefore bigger than IP but smaller than NSAPs (fit in an ATM cell quite nicely) so jsut what's wrong with it? jon (cowering behind the sofa as a hail of rotting fruit gets hurled from al corners of the internet at his mailbox:-) From owner-Big-Internet@munnari.oz.au Fri Jul 23 00:39:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21451; Fri, 23 Jul 1993 00:39:19 +1000 (from owner-Big-Internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21444; Fri, 23 Jul 1993 00:39:09 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA01135; Thu, 22 Jul 93 10:39:19 -0400 Date: Thu, 22 Jul 93 10:39:19 -0400 Message-Id: <9307221439.AA01135@worldlink.worldlink.com> From: David Piscitello To: big-internet@munnari.oz.au Subject: x.25 as IPng Jon writes: i am rather surprised no-one has suggested CONS as the IPng I'm sure someone has; you're probably listening to the wrong list. all we'd have to do is increase the default max packet size increase the sequence number and window size its got VCs and VC multiplexing, so its just like ATM its got fast select with data, so yu've got datagrams and don't forget all those error handling features! its got X.121 adsdresses which are 14 hexadecimal digits and therefore bigger than IP but smaller than NSAPs (fit in an ATM cell quite nicely) Jon, I'm ashamed of you! You can carry NSAPAs in X25 (1984 and beyond!) check your standards fella! In fact, if you use my "system id's for TUBA" I-D, you'd note that you can embed IP addresses in the DSPs of the NSAP addresses for those IP-to-X25 gateways so jsut what's wrong with it? you've convinced me, but oh, too bad, the registration period for the competition JUST expired. sad, really... jon (cowering behind the sofa as a hail of rotting fruit gets hurled from al corners of the internet at his mailbox:-) if you find a pair of sunglasses, they're mine:-) From owner-Big-Internet@munnari.oz.au Fri Jul 23 00:41:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21624; Fri, 23 Jul 1993 00:42:20 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21594; Fri, 23 Jul 1993 00:41:50 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA07361; Thu, 22 Jul 93 10:29:42 -0400 Date: Thu, 22 Jul 93 10:29:42 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9307221429.AA07361@er.doe.gov> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: N^2 growth... From jnc@ginger.lcs.mit.edu Wed Jul 21 12:50:29 1993 Received: by ginger.lcs.mit.edu id AA16280; Wed, 21 Jul 93 12:54:13 -0400 Date: Wed, 21 Jul 93 12:54:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307211654.AA16280@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu These discussions seem to be mired in an assumption that where we've been is going to be similar to where we're going. ... the original internet ... [was] based on a model of cooperating networks with similar purposes. Thus a global routing perspective made sense to think about and "optimal" routing was a meaningful concept. I agree with your basic point, but I'd put your last thought a little differently. I think that the very homogeneous network encouraged use of solutions which i) assumed that everyone had the same goals, and thus measures of what was "good", and thus ii) could use cooperative, distributed mechanisms to provide needed system-wide functions. (To be frank, given the paucity of more complex mechanisms, a very cooperative network was also a necessity to get the thing off the ground; it was either accept that model, or have nothing.) This shows up not only in routing, but in things like congestion control. In an offline discussion, John Wroclawski of MIT and I were discussing the fact that the Internet is not suffering congestive collapse at the moment mostly because everyone has implement Van Jacobsen's TCP algorithms, not because of mechanisms in the network itself; i.e. it's another cooperative solution. He pointed out that to be stable across the system, and share the bandwidth fairly, not only is it necessary for everyone to use the same algorithmm, but they must use the same parameters, otherwise some user groups will 'freeze out' others; i.e. correct functionality is very dependant on very close system-wide cooperation. Going back to your last sentence again, I still do think we need a global perspective on routing (and all other system wide functions such as congestion control), it just needs to be one that recognizes that different users are going to have different ideas of good, one that make allowances for the more complex mesh of service provision agreements restricting open interconnection, one that is less dependant on extremely close cooperation to function correctly, etc. Without such a global perspective, we will inevitably be lead to a balkanized network, with a proliferation of local standards leading inevitably to much more limited system capabilities though incompatabilities, etc. While it is true that a very "arm's-length" model has been operating in the global voice network, the rigid boundaries and limitations of that system have recently led directly to world-wide attempts to loosen things up. I can speculate that the limitations on the system grew not just from "turf conciousness" between different national entities, but also from the technological limits present at the time the system was set up. As soon as it became feasible to provide a more complex service model, the pressure was on to do so. Can we try and avoid that detour in building the global data network? Noel ========================= I agree with your concerns about a balkanized net, although I'm not convinced that internal network routing is the show stopper here. Clearly, some thingsrequire a global perspective like naming, EID's or addressing perhaps, to be useful. Some other things require a less global perspective providing the interface the net provides to the outside world is rich enough to allow things to find one another and exchange information. Perhaps this means that you need to exchange enough information to construct loose source routes at the "network to network" level of detail. Perhaps we should spend some time as agroup considering what should be global, and what data interfaces should pass around to provide the view of the net that we need to provide the services we need. Dan From owner-Big-Internet@munnari.oz.au Fri Jul 23 00:52:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22107; Fri, 23 Jul 1993 00:53:30 +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 AA22071; Fri, 23 Jul 1993 00:52:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25715; Thu, 22 Jul 93 10:52:37 -0400 Date: Thu, 22 Jul 93 10:52:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307221452.AA25715@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: x.25 Cc: jnc@ginger.lcs.mit.edu i am rather surprised no-one has suggested CONS as the IPng - all we'd have to do is ...increase the sequence number and window size I've been heard to remark (rather sarcastically :-) that if the proponents of some of the IPng proposals had been sent off to design the Internet in 1975, they'd have come back with X.25 with a larger sequence number space. You can thus imagine my reaction to this proposal! :-) If you're serious about this (I can't tell if this is tongue in cheek or not), I'll go off and study CONS (which which I must confess I'm not familiar; is there an on-line reference?), and give you a response. For one thing, the addresses are wrong; full length NSAPs with mandatory globally-unique ID's would be barely acceptable, so X.121 addresses will not do. Noel From owner-Big-Internet@munnari.oz.au Fri Jul 23 01:23:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23273; Fri, 23 Jul 1993 01:23:29 +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 AA23268; Fri, 23 Jul 1993 01:23:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26271; Thu, 22 Jul 93 11:23:11 -0400 Date: Thu, 22 Jul 93 11:23:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307221523.AA26271@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu a paper ... in January 1993 ACM CCR "Forwarding Database Overhead for Inter-Domain Routing" may help to shed some light on this subject. Not having access to a computer science library down here in the wilds of Virginia, I don't have a copy of this. Can someone who does summarize the arguments tot he list, for those of us (and I imagine there are quite a few) who are in a similar position? I will clean up my argument as stated in the debate with JMH and post it separately. Noel From owner-big-internet@munnari.oz.au Fri Jul 23 01:21:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23239; Fri, 23 Jul 1993 01:21:56 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17782; Thu, 22 Jul 1993 23:21:05 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA22329; Thu, 22 Jul 1993 15:20:58 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA04651; Thu, 22 Jul 1993 15:20:55 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307221320.AA04651@dxcern.cern.ch> Subject: Re: x.25 To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Thu, 22 Jul 1993 15:20:53 +0200 (MET DST) Cc: big-internet@munnari.oz.au In-Reply-To: <9307220947.9755@munnari.oz.au> from "Jon Crowcroft" at Jul 22, 93 10:47:12 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 75 Jon, The date on your computer is out by 3 months and 21 days. Brian From owner-Big-Internet@munnari.oz.au Fri Jul 23 02:26:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25685; Fri, 23 Jul 1993 02:26:45 +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 AA25670; Fri, 23 Jul 1993 02:26:30 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA09875; Thu, 22 Jul 1993 18:27:30 +0200 Message-Id: <199307221627.AA09875@mitsou.inria.fr> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: x.25 In-Reply-To: Your message of "Thu, 22 Jul 93 10:52:37 EDT." <9307221452.AA25715@ginger.lcs.mit.edu> Date: Thu, 22 Jul 93 18:27:29 +0200 From: Christian Huitema => I've been heard to remark (rather sarcastically :-) that if the proponents of => some of the IPng proposals had been sent off to design the Internet in 1975, => they'd have come back with X.25 with a larger sequence number space. You can => thus imagine my reaction to this proposal! :-) If the 1975 designers of X.25 were to design a nework today, they would probably try to remove the sequence numbering altogether, and make the packets shorter so one can transmit them real fast. Like 53 bytes. And yes, the address should not be only 14 digits. 13 looks just fine. Christian Huitema From owner-big-internet@munnari.oz.au Fri Jul 23 02:29:09 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25925; Fri, 23 Jul 1993 02:29:14 +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 AA23148; Fri, 23 Jul 1993 01:19:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26081; Thu, 22 Jul 93 11:19:05 -0400 Date: Thu, 22 Jul 93 11:19:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307221519.AA26081@ginger.lcs.mit.edu> To: amolitor@moink.nmsu.edu, big-internet@munnari.oz.au Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu it may well be that O(N^2) is a bit much, but it is growing ... Perhaps O(N^2) is a handy upper bound/design goal? Well, there is a very good reason to figure out if O(N^2) is a realistic upper bound for the growth rate of flows through a single switch, or if it is absolutely bounded by something much more moderate and *local* (i.e. influenced by things over which the switch installer has influence, not things elsewhere in the system over which they don't), like bandwidth through the switch. If it is potentially O(N^2), then over time this will lead to an explosive and probably unsupportable consumption of resources (principally memory) in the switch. So, either a) you have to provide a mandatory topology interconnection scheme, or some similar device, which does forcibly mandate lower growth rates, or b) give up on *any* scheme (*including* resource reservation architectures, flow installation for special policy requirements, etc) which require per-flow state be stored. The latter is quite a serious restriction, and would invalidate much research currently being done. The argument is pretty simple; if total flows through a switch are growing at O(N^2), then assuming the fraction of them which uses resource reservation, etc, is approximately constant over time, they also will be growing at O(N^2); there will be a constant factor of absolute difference, but still the same engineering problem over time. Even if the fraction is falling over time, using the argument I used to Matt Crawford's point, it will have to be falling at a pretty good clip to keep the growth in state reasonable. Say, O(1/N) neagt likive growth in the fraction of total flows which use resource reservation, etc, to produce a mere O(N) growth, which is still pretty horrible. I mean, look, we are all going around trying to design a routing architecture which has less than O(N) growth, because O(N) is too much, right? If, on the other hand, flow growth *is* bounded by switch bandwidth growth, we are preeeeety much in the clover. Resources to control flows will only need to grow at a rate which i) is presumably somewhat related to the technology and money available for the switch itself, and ii) is controlled only by local circumstances. Now, don't get me wrong, I'm not saying this is trivial engineering, it's not (bandwidths are going up at a rate of knots), but O(N^2) is simply shattering. Noel From owner-Big-Internet@munnari.oz.au Fri Jul 23 03:12:06 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27484; Fri, 23 Jul 1993 03:12:23 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307221712.27484@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27473; Fri, 23 Jul 1993 03:12:06 +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 ; Thu, 22 Jul 1993 18:11:51 +0100 To: big-internet@munnari.oz.au Subject: Re: x.25 In-Reply-To: Your message of "Thu, 22 Jul 93 18:27:29 +0100." <199307221627.AA09875@mitsou.inria.fr> Date: Thu, 22 Jul 93 18:11:50 +0100 From: Jon Crowcroft >shorter so one can transmit them real fast. Like 53 bytes. And yes, the >address should not be only 14 digits. 13 looks just fine. let me reassure everyone that I WAS JOKING i meant we should bridge everything over aal5 & atm:-) jon From owner-Big-Internet@munnari.oz.au Fri Jul 23 03:11:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27458; Fri, 23 Jul 1993 03:11:49 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307221711.27458@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27453; Fri, 23 Jul 1993 03:11:41 +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 ; Thu, 22 Jul 1993 18:11:30 +0100 To: big-internet@munnari.oz.au Subject: Re: x.25 In-Reply-To: Your message of "Thu, 22 Jul 93 18:27:29 +0100." <199307221627.AA09875@mitsou.inria.fr> Date: Thu, 22 Jul 93 18:11:26 +0100 From: Jon Crowcroft >shorter so one can transmit them real fast. Like 53 bytes. And yes, the >address should not be only 14 digits. 13 looks just fine. let me reassure everyone that I WAS JOKING i meant atm:-) jon From owner-Big-Internet@munnari.oz.au Fri Jul 23 04:57:32 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01184; Fri, 23 Jul 1993 04:57:42 +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 AA01177; Fri, 23 Jul 1993 04:57:32 +1000 (from cmj@bridge2.NSD.3Com.COM) Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA11867 (5.65c/IDA-1.4.4nsd for ); Thu, 22 Jul 1993 11:57:20 -0700 Received: by jaspar.NSD.3Com.COM id AA04687 (5.65c/IDA-1.4.4-910730); Thu, 22 Jul 1993 11:57:19 -0700 Date: Thu, 22 Jul 1993 11:57:19 -0700 From: "Cyndi M. Jung" Message-Id: <199307221857.AA04687@jaspar.NSD.3Com.COM> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: x.25 Cc: big-internet@munnari.oz.au > >shorter so one can transmit them real fast. Like 53 bytes. And yes, the > >address should not be only 14 digits. 13 looks just fine. >let me reassure everyone that I WAS JOKING >i meant we should bridge everything over aal5 & atm:-) > jon So, have you had your fun yet? Or are you still joking? Cyndi From owner-big-internet@munnari.oz.au Fri Jul 23 05:41:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02958; Fri, 23 Jul 1993 05:42:04 +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 AA28881; Fri, 23 Jul 1993 03:51:20 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA28763 (5.65/1.23); Thu, 22 Jul 93 13:50:38 -0400 Date: Thu, 22 Jul 93 13:50:38 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9307221750.AA28763@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: amolitor@moink.nmsu.edu, big-internet@munnari.oz.au Subject: Re: N^2 growth... In-Reply-To: <9307221519.AA26081@ginger.lcs.mit.edu> References: <9307221519.AA26081@ginger.lcs.mit.edu> < The argument is pretty simple; if total flows through a switch are > growing at O(N^2), then assuming the fraction of them which uses > resource reservation, etc, is approximately constant over time, they > also will be growing at O(N^2); I guess I must have missed something here. What's the `N' in this complexity? Connected hosts? Bandwidth? Links? And in any case, wouldn't some sort of `flow aggregation' take place? (I was thinking of a flow scheme for Pip which used the Pip's hierarchical FTIFs to name flows...) If my switch is handling fifty flows between here and MIT, all with similar characteristics, then I would expect any flow-based scheme to be able to hand these off to the intermediate nodes without those nodes having to keep state for more than one `meta-flow' between our switch and MIT's. Similarly, I would hope that all the traffic from NEARnet to, say, SDSC, which traverses the ANS backbone, would be aggregated into one `meta-meta-flow' (`meta^2-flow'?) for the benefit of the intermediate routers. -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 Fri Jul 23 06:31:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05075; Fri, 23 Jul 1993 06:31:38 +1000 (from owner-big-internet) Received: from gateway.mitre.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02607; Fri, 23 Jul 1993 05:33:13 +1000 (from barns@cove.mitre.org) Return-Path: Received: from cove.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA25691; Thu, 22 Jul 93 15:33:03 -0400 Received: by cove.mitre.org (4.1/SMI-4.1) id AA03336; Thu, 22 Jul 93 15:32:41 EDT Message-Id: <9307221932.AA03336@cove.mitre.org> To: big-internet@munnari.oz.au Cc: barns@cove.mitre.org Subject: Re: N^2 growth... In-Reply-To: Noel Chiappa's message of "Thu, 22 Jul 93 11:19:05 EDT." <9307221519.AA26081@ginger.lcs.mit.edu> Date: Thu, 22 Jul 93 15:32:40 -0400 From: barns@cove.mitre.org Evolutionary changes in mean path length and path width (so to speak - i.e., multipath) also factor into the equation in the direction adverse to the O(N) argument; how big a factor? small in the short term, I guess; in the long term, I don't know. mm? /Bill From owner-Big-Internet@munnari.oz.au Fri Jul 23 06:46:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05623; Fri, 23 Jul 1993 06:47:08 +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 AA05615; Fri, 23 Jul 1993 06:46:53 +1000 (from Tom.Lyon@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA29475; Thu, 22 Jul 93 13:46:41 PDT Received: from whitsun.eng.sun.com by Eng.Sun.COM (4.1/SMI-4.1) id AA24221; Thu, 22 Jul 93 13:46:44 PDT Received: by whitsun.eng.sun.com (4.1/SMI-4.1) id AA04479; Thu, 22 Jul 93 13:46:40 PDT Date: Thu, 22 Jul 93 13:46:40 PDT From: Tom.Lyon@Eng.Sun.COM (Tom Lyon) Message-Id: <9307222046.AA04479@whitsun.eng.sun.com> To: rolc@nsco.network.com, atm@Sun.COM, Big-Internet@munnari.oz.au, iplpdn@IETF.CNRI.Reston.VA.US, jmh@anubis.network.com Subject: Re: Routing Over Large Clouds >This group will be focussed on the problems of routing over large >switched clouds. I think the chief problem of routing over the clouds is brain-damage due to oxygen deprivation. :-) From owner-big-internet@munnari.oz.au Fri Jul 23 07:02:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06510; Fri, 23 Jul 1993 07:02:45 +1000 (from owner-big-internet) Return-Path: Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02510; Fri, 23 Jul 1993 05:29:19 +1000 (from jmh@anubis.network.com) Received: from anubis-e1.network.com by nsco.network.com (5.61/1.34) id AA09663; Thu, 22 Jul 93 14:31:33 -0500 Received: from gramarye.network.com by anubis.network.com (4.1/SMI-4.1) id AA04227; Thu, 22 Jul 93 14:28:33 CDT Date: Thu, 22 Jul 93 14:28:33 CDT From: jmh@anubis.network.com (Joel Halpern) Message-Id: <9307221928.AA04227@anubis.network.com> To: rolc@nsco.network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us Subject: Routing Over Large Clouds As a consequence of several discussions at the last IETF, and new WG/BOF is being formed. This group will be focussed on the problems of routing over large switched clouds. A charter for this group is being developed with the Routing Area director. To facilitate discussion, I have created the e-mail list, and am sending out this announcement. The list is: rolc@network.com Request for addition should be sent to: rolc-request@network.com The Repostory for the Archive of this list, accessible via anonymous FTP is: nsco.network.com:/rolc/rolc.arc Files of interest to the group will be made available there (in addition to the formal internet-drafts, which of course will be available in the standard repositories.) The topics to be addressed by this group (probably) cover all aspects of routing IP over "large clouds". In this context, large clouds refer primarily to large public data services, such as future ATM, SMDS, and Frame Relay (X.25 may also qualify). In practice a network large enough that a single router can not peer with all other routers is subject to the same problems, and should be addressed by the same solutions. (Thus, it is hoped that this will work on a VERY large bridged ethernet.) Subtopics to be addressed include: A) Architectural implications of relaxing the current requirement that communicating IP entites have a common NET number. B) Routing over Demand Circuits. Gerry Meyers work provides a starting point for making more effective use of the communication media when one is willing/able to peer. C) Operating IS-IS over clouds. Radia Perlman's draft on this should be reviewed. D) Routing and Address Resolution. This is an outgrowth of much previous work, including Directed ARP, Shortcut Routing, NBMA ARP, and architectural thinking by several IAB members. The current proposal (to be fleshed out on the email list, with a clear proposal soon) is based oround a query/response protocol between routers, with MAC addresses carried. Host operation is possible in several different ways (and we need to pick). [The number of individuals who have already contributed to this is too numerous to name, although some individual credits will probably appear in the proposal. Apologies to those who feel that they have contribted much and should be mentioned by name.] Note: The charter is still to be worked, so ideas for other areas should be mailed directly to me. Many people may receive multiple copies of this, but I feel the wide coverage is needed, since the formal IETF announcement of the WG may be a bit in the future. Thank you, Joel M. Halpern jmh@network.com Network Systems Corporation From owner-Big-Internet@munnari.oz.au Fri Jul 23 07:21:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07176; Fri, 23 Jul 1993 07:22:21 +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 AA07167; Fri, 23 Jul 1993 07:21:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29945; Thu, 22 Jul 93 17:21:34 -0400 Date: Thu, 22 Jul 93 17:21:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307222121.AA29945@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, wollman@uvm-gen.emba.uvm.edu Subject: Re: N^2 growth... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I guess I must have missed something here. What's the `N' in this complexity? Connected hosts? Yes. And in any case, wouldn't some sort of `flow aggregation' take place? Depends on your model. Some do, such as routing only ones such as IDPR, and some don't, particularly ones which have resource allocation as well; these more or less have to keep each flow distinguished. If my switch is handling fifty flows between here and MIT, all with similar characteristics, then I would expect any flow-based scheme to be able to hand these off to the intermediate nodes without those nodes having to keep state for more than one `meta-flow' between our switch and MIT's. In this example, the problem with resource allocation is not as obvious because the first entry switch could enforce the allocation among the flows. But it gets more complicated, if you try and aggregate meta-flows into a meta^2-flow, if the resource usage is "minimum of X bits/sec, plus whatever is to spare, shared evenly", etc, etc. Noel From owner-Big-Internet@munnari.oz.au Fri Jul 23 08:01:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08845; Fri, 23 Jul 1993 08:01:22 +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 AA08842; Fri, 23 Jul 1993 08:01:11 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (5.65/inc-1.0) id AA02823; Thu, 22 Jul 93 15:01:06 -0700 Message-Id: <9307222201.AA02823@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: N^2 growth... Phone: +1 415 390 1804, +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 22 Jul 93 10:29:42 -0400. <9307221429.AA07361@er.doe.gov> Date: Thu, 22 Jul 93 15:01:05 -0700 From: Dave Crocker X-Mts: smtp Just to re-register a point I made at the Open IAB meeting in Amsterdam, last week: Windows NT is about to ship with TCP. Are talking about 40 or 60 million machines, real quick? At this last IETF meeting, there was participation by a vendor representing a consortium in the consumer electronic business. These folks view sales of 100K units per month to be paltry. if each of those machines needs Internet connectivity... My own company is part of an interactive cable project. While the technical details are by no means locked down, we are strongly considering a design which requires that each household get its own Class C network address. Since this is only a pilot project, I'll probably only have to ask IANA for 16,000 Class C network numbers. The times, they are a changing. So are the models. The price of success is more work. Dave From owner-Big-Internet@munnari.oz.au Fri Jul 23 10:28:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15285; Fri, 23 Jul 1993 10:28:21 +1000 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15266; Fri, 23 Jul 1993 10:28:12 +1000 (from jchang@cis.ohio-state.edu) Received: from quetzal.cis.ohio-state.edu by ux1.cso.uiuc.edu with SMTP id AA16424 (5.67a8/IDA-1.5 for ); Thu, 22 Jul 1993 19:26:38 -0500 Received: by quetzal.cis.ohio-state.edu (5.61-kk/5.911008) id AA03490; Thu, 22 Jul 93 20:27:59 -0400 To: info-big-internet@ux1.cso.uiuc.edu Path: bounce-bounce From: jchang@cis.ohio-state.edu (joe chang) Newsgroups: info.big-internet Subject: QUESTION: Who runs InterNet? Date: 22 Jul 1993 20:27:57 -0400 Organization: The Ohio State University Dept. of Computer and Info. Science Lines: 4 Message-Id: <22nbadINN3cr@quetzal.cis.ohio-state.edu> Hi, Who runs InterNet? Is it run by any one organization? Someone please send me an answer. -- Thanks Joe Chang From owner-Big-Internet@munnari.oz.au Fri Jul 23 16:18:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00870; Fri, 23 Jul 1993 16:19:15 +1000 (from owner-Big-Internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00838; Fri, 23 Jul 1993 16:18:41 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA06894; Fri, 23 Jul 1993 08:18:33 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA07375; Fri, 23 Jul 1993 08:18:32 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307230618.AA07375@dxcern.cern.ch> Subject: Host count query To: Date: Fri, 23 Jul 1993 08:18:31 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 457 Hello, Can anybody help us trace several mysterious incidents on our main external gateway recently? Has anybody been running automatic host counts of some kind in the last few days (during European night hours) that might account for floods of ARPs sweeping across our whole Class B network? Thanks for any help, sorry to use this list but where better? 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 Fri Jul 23 18:08:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05307; Fri, 23 Jul 1993 18:08:31 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307230808.5307@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05304; Fri, 23 Jul 1993 18:08:11 +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 ; Fri, 23 Jul 1993 09:06:37 +0100 To: Stephen Casner Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: N^2 growth... In-Reply-To: Your message of "Wed, 21 Jul 93 16:38:34 PDT." <743297914.0.CASNER@XFR.ISI.EDU> Date: Fri, 23 Jul 93 09:06:32 +0100 From: Jon Crowcroft >> John Wroclawski of MIT and I were discussing the fact >> that the Internet is not suffering congestive collapse at the moment mostly >> because everyone has implement Van Jacobsen's TCP algorithms >And the real-time audio and video applications are about to become a >serious violation of that cooperative, distributed mechanism. Steve however, a/v applciation can be subjected to 2 complimentary approaches: 1. constant bitrate can be added according to policy which each backbone provider will have to make about what %age traffic may be a/v and what normal data enforcement throughf mechanisms about to be developed in mbone anyhow, plus through policy filters in backbone routers. 2. variable bitrate is cbr + variable bit:- subject the cosntant part to apporach 1, and variable part to approach 0 (where 0 is van's congestion approach) and you have a workable system however, getting people to state their policy w.r.t a/v in backbones is going to be quite hard... jon From owner-Big-Internet@munnari.oz.au Fri Jul 23 23:51:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18324; Fri, 23 Jul 1993 23:52:13 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18319; Fri, 23 Jul 1993 23:51:54 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA10386; Fri, 23 Jul 93 09:47:24 -0400 Date: Fri, 23 Jul 93 09:47:24 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9307231347.AA10386@er.doe.gov> To: amolitor@moink.nmsu.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: N^2 growth... Of course, only routers in the "core" of the network could have an N^2 flow scaling problem. Routers nearer the "edges" for example connecting a single site to the net probably only grow as some constant X number of local addresses because only local addresses are sources or sinks of flows. In the core you can't have O(N^2) either and have your network operate because the bandwidth per flow goes like 1/N^2 which goes to zero and causes congestive failure of the net. This may imply that the control of # of flows is tied to congestion control. And it also may put constraints on the topology of the net (perhaps a star of stars is not a good idea). DH From owner-big-internet@munnari.oz.au Sat Jul 24 02:34:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25133; Sat, 24 Jul 1993 02:35:03 +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 AA17413; Fri, 23 Jul 1993 23:26:19 +1000 (from bmanning@is.rice.edu) Received: from sabine.is.rice.edu by is.rice.edu (AA29810); Fri, 23 Jul 93 08:26:06 CDT Received: by sabine.is.rice.edu (AA05876); Fri, 23 Jul 93 08:26:05 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9307231326.AA05876@sabine.is.rice.edu> Subject: Re: N^2 growth... To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Fri, 23 Jul 93 8:26:04 CDT Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9307222201.AA02823@Mordor.Stanford.EDU>; from "Dave Crocker" at Jul 22, 93 3:01 pm X-Mailer: ELM [version 2.3 PL11] What was the "original" design point that Vint used? 10^9 networks? -- 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 Jul 24 03:21:57 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27064; Sat, 24 Jul 1993 03:22:19 +1000 (from owner-Big-Internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27040; Sat, 24 Jul 1993 03:21:57 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA29197; Fri, 23 Jul 93 13:22:13 -0400 Date: Fri, 23 Jul 93 13:22:13 -0400 Message-Id: <9307231722.AA29197@worldlink.worldlink.com> From: David Piscitello To: big-internet@munnari.oz.au Subject: how widespread, really? Noel sez... John Wroclawski of MIT and I were discussing the fact that the Internet is not suffering congestive collapse at the moment mostly because everyone has implement Van Jacobsen's TCP algorithms, Is this speculation on your part, and if so, how accurate do others feel this is. Are Van's improvements widely implemented and more to the point, widely deployed? I'm sure recent kernels/OSs have these, but does anyone have a sense for the pct. of deployed systems that participate in congestion control and avoidance? And what about systems not operating TCP/IP (I've heard such things exist, is this but a nasty rumor?) From owner-Big-Internet@munnari.oz.au Sat Jul 24 05:16:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01006; Sat, 24 Jul 1993 05:17:21 +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 AA00977; Sat, 24 Jul 1993 05:16:44 +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 AA10150; Fri, 23 Jul 93 12:16:27 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA14676; Fri, 23 Jul 93 15:16:24 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA03924; Fri, 23 Jul 93 15:16:24 EDT Date: Fri, 23 Jul 93 15:16:24 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9307231916.AA03924@fenway.andr.UB.com> To: big-internet@munnari.oz.au, dave@mail.bellcore.com Subject: Re: how widespread, really? >From: David Piscitello >To: big-internet@munnari.oz.au >Subject: how widespread, really? > > Is [widespread implementation of VJ congestion control] > speculation on your part, and if so, how accurate > do others feel this is. Are Van's improvements widely > implemented and more to the point, widely deployed? I'm > sure recent kernels/OSs have these, but does anyone > have a sense for the pct. of deployed systems that > participate in congestion control and avoidance? I believe VJCC was first deployed about four years ago, when the networks connected to the NSF backbone numbered in the hundreds. It's hard for me to believe that the congestion problems that were present in that environment would have largely disappeared without these improvements being deployed in a significant percentage of the currently connected nodes. > And what about systems not operating TCP/IP (I've heard > such things exist, is this but a nasty rumor?) Same argument -- even if they are out there now :-), how many were then? And what percentage of the traffic do they (then or now) represent? If it's not large, how much congestion could they create? If it is, the cogestion they create would be protocol-independent. -- Frank From owner-big-internet@munnari.oz.au Sat Jul 24 05:23:19 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01305; Sat, 24 Jul 1993 05:23:28 +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 AA27089; Sat, 24 Jul 1993 03:22:24 +1000 (from kasten@ftp.com) Received: by ftp.com id AA19094; Fri, 23 Jul 93 13:22:11 -0400 Date: Fri, 23 Jul 93 13:22:11 -0400 Message-Id: <9307231722.AA19094@ftp.com> To: bmanning@is.rice.edu Subject: Re: N^2 growth... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: dcrocker@mordor.stanford.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu This was the original number of ROAD/IAB/whoever-else-has-pontificated- on-the-subject Some thought has gone on that perhaps 10^12 is desirable too. > What was the "original" design point that Vint used? 10^9 networks? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Sat Jul 24 05:59:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02934; Sat, 24 Jul 1993 05:59:48 +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 AA29849; Sat, 24 Jul 1993 04:44:12 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Fri, 23 Jul 1993 11:44:03 -0700 Date: Fri, 23 Jul 1993 11:44:03 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307231844.AA17116@zephyr.isi.edu> To: big-internet@munnari.oz.au, dave@mail.bellcore.com Subject: Re: how widespread, really? *> From owner-Big-Internet@munnari.oz.au Fri Jul 23 10:44:08 1993 *> Date: Fri, 23 Jul 93 13:22:13 -0400 *> From: David Piscitello *> To: big-internet@munnari.oz.au *> Subject: how widespread, really? *> Content-Length: 640 *> X-Lines: 16 *> *> Noel sez... *> *> John Wroclawski of MIT and I were discussing the fact *> that the Internet is not suffering congestive collapse at the moment mostly *> because everyone has implement Van Jacobsen's TCP algorithms, *> *> Is this speculation on your part, and if so, how accurate *> do others feel this is. Are Van's improvements widely *> implemented and more to the point, widely deployed? I'm *> sure recent kernels/OSs have these, but does anyone *> have a sense for the pct. of deployed systems that *> participate in congestion control and avoidance? *> *> And what about systems not operating TCP/IP (I've heard *> such things exist, is this but a nasty rumor?) *> *> John and Noel are simply reporting the common wisdom. A LOT of people would be very surprised if it were not true...! Bob From owner-Big-Internet@munnari.oz.au Sat Jul 24 06:43:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04443; Sat, 24 Jul 1993 06:43:46 +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 AA04376; Sat, 24 Jul 1993 06:43:16 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA06242 (5.65/1.23); Fri, 23 Jul 93 16:41:34 -0400 Date: Fri, 23 Jul 93 16:41:34 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9307232041.AA06242@sadye.emba.uvm.edu> To: solensky@andr.ub.com (Frank T Solensky) Cc: big-internet@munnari.oz.au, dave@mail.bellcore.com Subject: Re: how widespread, really? In-Reply-To: <9307231916.AA03924@fenway.andr.UB.com> References: <9307231916.AA03924@fenway.andr.UB.com> <[Dave Piscitello wrote:] >> And what about systems not operating TCP/IP (I've heard >> such things exist, is this but a nasty rumor?) > Same argument -- even if they are out there now :-), how many were then? > And what percentage of the traffic do they (then or now) represent? Enough to swamp our puny 256-kbit Internet connection during the last IETF, until I had our feed adjust the parameters enough to prevent it. -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 Jul 24 07:26:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05870; Sat, 24 Jul 1993 07:26: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 AA05865; Sat, 24 Jul 1993 07:26:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09824; Fri, 23 Jul 93 17:26:45 -0400 Date: Fri, 23 Jul 93 17:26:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307232126.AA09824@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, braden@isi.edu, dave@mail.bellcore.com Subject: Re: how widespread, really? Cc: jnc@ginger.lcs.mit.edu John and Noel are simply reporting the common wisdom. A LOT of people would be very surprised if it were not true...! Well, it's true that it is the CW, but the CW often turns out to be wrong, so I'm quite open to the possibility that this one is wrong too. The CW can really be a double edged sword; it can save you time filtering through utter crap (e.g. one more proof of how to swaure the circle), but it can also lead you down a blind alley (and my mind is refusing to cough up an example from the history of science where people ignored experimental results that would have lead them to a big discovery, but it has happened many times). Does The Master of Congestion (i.e. Van :-) have any thoughts on this issue of "is distributed VJCC what's keeping the Internet afloat"? How about some other congestion experts? Noel From owner-big-internet@munnari.oz.au Sat Jul 24 10:13:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12572; Sat, 24 Jul 1993 10:13:44 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21333; Sat, 24 Jul 1993 00:58:01 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10942; Fri, 23 Jul 1993 16:57:54 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA04954; Fri, 23 Jul 1993 16:57:51 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307231457.AA04954@dxcern.cern.ch> Subject: IPDECIDE BOF minutes To: big-internet@munnari.oz.au Date: Fri, 23 Jul 1993 16:57:50 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9477 Minutes of IP Decision Process BOF (IPDECIDE) ============================================= July 14 1993, Amsterdam, The Netherlands Brian Carpenter/Tim Dixon Summary and Results ------------------- The IP Decision Process BOF was intended to help re-focus attention on the very important topic of making a decision between the candidates for IPng. The BOF focused on the issues of who should take the lead in making the recommendation to the community and what criteria should be used to reach the recommendation. The discussion ranged widely, but some key points emerged: 1. Vendors and operators look to the IETF to reach a clear decision. 2. It would be bad to offer the market an ambiguous decision. 3. The market will resist any IPng that does not just look like a new release of IP. Co-existence, and ease and cost of transition, should be key decision criteria. 4. It is unclear how to prove that any proposal truly scales to a billion nodes. 5. Timescales for IPv4 address depletion and for IPng deployment are not well understood. 6. The IESG needs to figure out how to pursue the decision process and avoid wasted effort on competing proposals. Making a reasonable well-founded decision earlier was preferred over taking longer to decide and allowing major deployment of competing proposals. In the end, the BOF led very productively to a follow-up discussion in the Thursday afternoon Open Plenary. During the Open Plenary, a proposal that the IESG should take the lead responsibility for recommending an IPng choice to the IETF community met with strong consensus. This proposal included a series of steps that the IESG should take, with strong community involvment, toward a recommendation. See the IETF Chair's report in these Proceedings for more details on the Thursday Open Plenary. We now give a more detailed review of the BOF discussion, in the interest of recording the wide range of opinions expressed. Meeting Goals ------------- The purpose of the BOF was to focus on the decision process for IPng rather than on technical criteria, the proposals themselves, or on the WG process. Attendance ---------- About 200 people attended, plus about 100 MBONE auditors. Members of the audience represented the IETF's typical wide community of service-providers, equipment vendors and engineers. The Need for A Decision ----------------------- The view was frequently expressed that a decision was needed. Vendors and operators looked to the IETF to reach a clear decision. The IPng issue had been widely publicised for some time and the expectation clearly was that it was the responsibility of the IETF to decide. Operators simply reacted to the demands of their customers: the IETF must set the technical standards. The IETF was doing a disservice to the community by appearing to be indecisive. The alternative of "letting the market decide" (whatever that may mean) was criticised on several grounds: - There are infrastructural issues, like DNS, which go hand-in-hand with the choice of a protocol and which cannot reasonably be expected to deal with 4 protocols - There are already enough other choices (both proprietary and otherwise) in the marketplace - The decision was too complicated for a rational market-led solution The fact that the Internet is doubling in size about every 11 months means that the cost of transition to IPng (in terms of equipment and manpower) is also increasing. The longer it takes to reach a decision, the more costly the process of transition and the more difficult it is to undertake. There were some minority views expressed, including: - The decision will inevitably be controlled by the pricing policy of vendors - Router vendors are already supporting multiple network-layer protocols; in principle it would not be significantly more difficult to support several IPng solutions at the same time. Should there be a decision to recommend ONE proposal, or simply to eliminate some of the candidates? Concern was expressed about the feasibility of conducting reasonably-sized trials of more than one selected protocol and of the confusing signals this would send the market: IETF decisions now have an enormous potential economic impact on suppliers of equipment and services. It was also likely that uncertainty would lead to customers holding back on their purchases of networking equipment until the situation was clearer. A straw poll showed a clear majority view that there should be a decision for ONE solution. The Time Scale for a Decision ----------------------------- The best guesstimates for the remaining lifetime of the IPv4 address space put the figure at around 5-7 years, assuming CIDR is widely deployed. A margin of potential error in these figures is to be expected - one suggestion was that they could be out by a factor of 4 in either direction. However, the address space is only 5 doublings away from exhaustion. It was strongly recommended that more work be done on investigating the feasible remaining lifetime of IPv4. It is also difficult to estimate the time taken to implement, test and then deploy any chosen solution: it was not clear who was best placed to do this. The ordering of the decisions also might have a different priority for customers and vendors than for the IETF. For example, it might be necessary to have a decision about DNS changes early in order to deploy the infrastructure necessary to support IPng in advance of the availability of the IPng protocol itself. The IETF work was not proceeding in this order. The Evaluation Process ---------------------- Concern was expressed that the evaluation criteria which had so far been discussed were too general to support a defensible choice on the grounds of technical adequacy. The criteria had emerged in parallel with the protocol designs, and had so far not gelled enough to eliminate any candidate. There were also potential legal difficulties if the IETF appeared to be eliminating proposals on arbitrary grounds. It was stated frequently and forcibly that the transition costs should be a significant factor in the selection criteria. Concerns were expressed by several service providers that the developers had little appreciation of the real-world networking complexities that transition would have to cope with. If the cost of transition outweighed the pain of other solutions (application gateways or address translators) customers would not deploy IPng. It was suggested a couple of times that the Working Groups should be invited to evaluate each other's proposals in order to investigate their weaknesses, or that the proposals should be vetted by disinterested parties. It was suggested that the proposals were too similar for any reasonable choice to be made on the grounds of technical strength. However there was no consensus on these points. Although one of the goals of IPng had been to use the inevitable transition required by address exhaustion and routing problems to incorporate new features, there were a number of concerns about bundling too much additional complexity into an already difficult problem. It wasn't even clear that the technology yet existed to handle some of the new features that had been touted for IPng. IPng should appear simply like a new release of IPv4; although this would not necessarily bring new features, people would still transition through enlightened self-interest - to avoid disconnection from the Global Internet in the future. There was no consensus about how to resolve this dilemma, since both smooth transition and multimedia support are musts. Various parties were identified as needing to assist in the evaluation process: - Operators, who need to understand deployment costs & scenarios - Vendors, who understand the implementation consequences The Decision Process -------------------- There is an IETF process for making a decision on protocol standards: Working Groups can be given deadlines to submit papers to the IESG which then decides which to progress as standards. It was suggested that this process has only broken down in that the deadlines had not been applied. Other suggestions included: - Urging coalitions between the different Working Groups - Forming an "IPng" WG either to make recommendations or to draw together the different proposals - Asking the IESG or even the IAB to drive the decision process On the basis of a straw poll, there was strong consensus that the decision should be made on technical grounds alone (subject to reasonable costs of implementation, deployment and transition). It was repeatedly stated that an obvious requirement was that the proposed solution should work. There were at least two components to this: inter-operability and scaling. This would be difficult to establish without large-scale piloting. There was no consensus on who might reasonably be expected to participate in such an exercise. [Editor's note: at the Thursday plenary session, a proposal that the IESG should take the responsibility of recommending an IPng choice to the IETF met with strong consensus. This proposal included a series of steps that the IESG should take to develop a progressive decision with community involvment. See the IETF Chair's report for more details.] - Minutes written by Tim Dixon and Brian Carpenter with some additional text from Phill Gross. From owner-Big-Internet@munnari.oz.au Sat Jul 24 13:58:15 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20583; Sat, 24 Jul 1993 13:58:33 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20579; Sat, 24 Jul 1993 13:58:15 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AB08371; Fri, 23 Jul 93 23:58:08 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA02791; Sat, 24 Jul 93 00:00:22 EDT Message-Id: <9307240400.AA02791@tipper> X-Really-To: gibbs.oit.unc.edu To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: amolitor@moink.nmsu.edu, big-internet@munnari.oz.au Subject: Re: N^2 growth... In-Reply-To: Your message of "Thu, 22 Jul 93 11:19:05 EDT." <9307221519.AA26081@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Jul 93 00:00:22 -0400 From: Simon E Spero Next slogan: "Routers for super-computers, not super-computers for routers" Simon From owner-Big-Internet@munnari.oz.au Sat Jul 24 14:02:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20719; Sat, 24 Jul 1993 14:03:18 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20669; Sat, 24 Jul 1993 14:02:48 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA08573; Sat, 24 Jul 93 00:02:41 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA02800; Sat, 24 Jul 93 00:04:51 EDT Message-Id: <9307240404.AA02800@tipper> X-Really-To: gibbs.oit.unc.edu To: jmh@anubis.network.com (Joel Halpern) Cc: rolc@nsco.network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us Subject: Re: Routing Over Large Clouds In-Reply-To: Your message of "Thu, 22 Jul 93 14:28:33 CDT." <9307221928.AA04227@anubis.network.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Jul 93 00:04:51 -0400 From: Simon E Spero Don't forget, you have to circle O'hare fifty times for back-compatibility From owner-big-internet@munnari.oz.au Sat Jul 24 14:22:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21503; Sat, 24 Jul 1993 14:22:54 +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 AA05633; Sat, 24 Jul 1993 07:21:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09760; Fri, 23 Jul 93 17:20:54 -0400 Date: Fri, 23 Jul 93 17:20:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307232120.AA09760@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, dave@mail.bellcore.com Subject: Re: how widespread, really? Cc: jnc@ginger.lcs.mit.edu > John Wroclawski of MIT and I were discussing the fact that the Internet > is not suffering congestive collapse at the moment mostly because > everyone has implement Van Jacobsen's TCP algorithms, Is this speculation on your part Well, yes, to some degree it is speculation, and I'm well aware it could be wrong. For all I know, there isn't any congestion because the NSF backbone guys are doing a great job keeping the available bandwidth ahead of demand, and distributed VJCC doesn't even work as well as I think it does. However, it certainly is the case that a TCP *without* VJCC will respond *very* poorly to congestion, and in fact cause congestive lockup of the network. In this kind of situation, you'd think that a transient congestion condition would trigger more of the same, leading almost inevitably to lockup. So, the fact that we don't see such lockups now indicates to me that either i) there aren't any transient congestion problems in the network, or ii) there are such transients, but the majority of TCP's have VJCC and deal with it. The second seems more likely, but who knows for sure? I mean, I don't know of any large study on congestion in the the network, and why it isn't worse, but I really wish there was one. Some complex systems defy modeling/prediction, so it might not be possible to see how much VJCC is helping the Internet as a whole without doing an experiment; i.e. turning it off everywhere! I guess another thing that drives that speculation it is the observation that Frank made, that there were observed problems with congestion some years back, which went away at about the time VJCC came down. Now, maybe it's just a coincidence, because the new NSF backbone came along about then too, but then again, you'd think there would still be transients, and with the old unstable TCP's.... if so, how accurate do others feel this is. John Nagle had some interesting observations to make in a reply to my original message, which I'll include here for general benefit (and apologies to John if I've offended): I think the big change has come from improvements in link error rates. Remember, the original purpose of retransmission was to deal with link errors. As link errors declined, this became less important. Modern TCP retransmission algorithms assume that most retransmissions reflect congestion, not errors. This leads to different policy approaches. Arguably, a constant long retranmission interval would work if everyone used it and errors were rare. Again, this could also be a factor; if you don't have many packet losses due to error, and as long as there's plenty of bandwidth (and you don't have totally crazy windows) to avoid congestion, you won't *have* retransmissions, so it doesn't matter if the algorithms aren't good. However, I still wonder about the transients; if the system as a whole is congestion unstable, you'd think that sooner or later a transient condition would get you into that mode... Are Van's improvements widely mplemented and more to the point, widely deployed? Again, here's what John has to say: I didn't think everybody would end up using the same algorithms, but once everybody started copying the Berkely code, TCP implementations seem to have converged. It's interesting to see how that worked. I can speculate that with typical workstations being able to eat Ethernets, we'd have seen congestion problems even on the local level without working, stable congestion control, so perhaps this motivated vendors to get it deployed. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 24 14:33:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21830; Sat, 24 Jul 1993 14:34:00 +1000 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21826; Sat, 24 Jul 1993 14:33:51 +1000 (from ses@tipper.oit.unc.edu) Received: from gibbs.oit.unc.edu by ux1.cso.uiuc.edu with SMTP id AA02885 (5.67a8/IDA-1.5 for ); Fri, 23 Jul 1993 23:29:48 -0500 Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA09205; Sat, 24 Jul 93 00:28:38 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA02829; Sat, 24 Jul 93 00:30:52 EDT Message-Id: <9307240430.AA02829@tipper> X-Really-To: gibbs.oit.unc.edu To: jchang@cis.ohio-state.edu (joe chang) Cc: info-big-internet@ux1.cso.uiuc.edu Subject: Re: QUESTION: Who runs InterNet? In-Reply-To: Your message of "22 Jul 93 20:27:57 EDT." <22nbadINN3cr@quetzal.cis.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 24 Jul 93 00:30:52 -0400 From: Simon E Spero Actually, I do. Sorry it's taken so long to get IP-TNG finalised - I've been holding out for someone to send me a Porche. From owner-Big-Internet@munnari.oz.au Sun Jul 25 02:05:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02912; Sun, 25 Jul 1993 02:05:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307241605.2912@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02909; Sun, 25 Jul 1993 02:05:50 +1000 (from perk@watson.ibm.com) Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5093; Sat, 24 Jul 93 12:05:42 EDT Date: Sat, 24 Jul 93 11:55:34 EDT From: perk@watson.ibm.com To: big-internet@munnari.oz.au Subject: IPng: Keeping one's options open I think we can agree on two things: - We don't know when the current addresses and routing capability of the Internet will be exhausted - We have to have a solution and transition plan in effect before the exhaustion occurs It's the tension between the immovable and the irresistible that makes everyone nervous, and (I believe) is the cause of the current push for selecting a solution NOW. In a way, I agree with this. But, I think the development of IPng could be managed more effectively. I would suggest that we follow some variant of the following plan: - Select a leading contender - Make it work great - Get a transition plan into place, including necessary testing - DON'T "switch over" until the feared exhaustion event appears imminent - Encourage academia to analyze the leading contender - Encourage developers to try to "beat" the leading contender - If another contender can surpass the leader, and put into place its separate transition place and necessary testing, then it can become the leading contender - Until the "switch over" occurs, IPng is explicitly in flux and problems that might be discovered by (say) researchers in the various academic institutions could be solved by (incrementally) modifying the leading candidate. The concerns, of course, will be to avoid fragmenting development resources and to minimize the total costs of the "switch over". However, it is my strong belief that IPng must address the issues of quality of service and autoconfiguration, and those are areas which do not have intuitively obvious answers in the context(s) of the IPng candidates. Thus I hope that the process of selection and implementation will allow for the possibility of solving those critical problem areas. Charlie P. From owner-Big-Internet@munnari.oz.au Sun Jul 25 06:44:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06616; Sun, 25 Jul 1993 06:44:49 +1000 (from owner-Big-Internet) Return-Path: Received: from iha.compuserve.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06612; Sun, 25 Jul 1993 06:44:35 +1000 (from 70724.3262@CompuServe.COM) Received: by iha.compuserve.com (5.67/5.930129sam) id AA25802; Sat, 24 Jul 93 16:44:16 -0400 Date: 24 Jul 93 16:42:13 EDT From: James McGovern <70724.3262@CompuServe.COM> To: Subject: Job Opportunities in CT Message-Id: <930724204213_70724.3262_CHG40-2@CompuServe.COM> I am interested in learning of any/all career opportunities within the Hartford CT area. I have experience in Windows Software Development, C/C++, Client Server, Relational Databases and Network Management. If anyone knows of any opportunities, please do not hesitate to contact me. James McGovern 203-242-1050 From owner-Big-Internet@munnari.oz.au Sun Jul 25 12:43:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17626; Sun, 25 Jul 1993 12:43:40 +1000 (from owner-Big-Internet) Return-Path: Received: from mcigateway.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17608; Sun, 25 Jul 1993 12:43:26 +1000 (from 0002498337@mcimail.com) Received: by MCIGATEWAY.MCIMail.com id aa00560; 25 Jul 93 2:31 GMT Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad00178; 25 Jul 93 2:20 GMT Date: Sun, 25 Jul 93 00:35 GMT From: Henry Sinnreich <0002498337@mcimail.com> To: Joel Halpern Cc: "David E. McDysan" <0002806303@mcimail.com> Cc: David Greenfield <0004020699@mcimail.com> Cc: "RND - RAD NETWORK DEVICES LTD." <0004373580@mcimail.com> Cc: Jim Mollenauer <0004787822@mcimail.com> Cc: "Michael E. Conn" <0004387451@mcimail.com> Cc: "Laszlo I. Szerenyi" <0004327219@mcimail.com> Cc: Mary Jander <0004734998@mcimail.com> Cc: Scott Brigham <0002442341@mcimail.com> Cc: rolc Cc: atm Cc: Big Internet Cc: iplpdn Subject: Re: Routing Over Large Clouds Message-Id: <13930725003531/0002498337MT1EM@mcimail.com> Please add me to the list - this is a very timely topic ! Thanks, Henry Sinnreich MCI Engineering Richardson, Texas From owner-big-internet@munnari.oz.au Sun Jul 25 15:10:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22439; Sun, 25 Jul 1993 15:10:12 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13526; Sun, 25 Jul 1993 10:25:19 +1000 (from smart@mel.dit.csiro.au) Received: from squid.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA10210 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sun, 25 Jul 1993 10:25:32 +1000 Received: by squid.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA14683; Sun, 25 Jul 93 10:25:14 EST Message-Id: <9307250025.AA14683@squid.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Fri, 23 Jul 93 16:57:50 +0200." <9307231457.AA04954@dxcern.cern.ch> Date: Sun, 25 Jul 93 10:25:13 +1000 From: Bob Smart >6. The IESG needs to figure out how to pursue the decision process > and avoid wasted effort on competing proposals. Well I'm a long way away, but my impression is that the competitors have influenced each other a lot. The moment one solution is chosen you will get some extra workers in the chosen group, but most of the people who were working on proposals that have lost will go back to their real jobs. So lets not make this happen prematurely. Also whatever else happens we are going to end up with: (a) TCP and UDP running over CLNP networks; and (b) some large and important CLNP networks almost certainly including a world-wide one on the scale of the Internet. So if we are going to have one solution it has to be TUBA. But we really need development in the network layer. At a high level the difference between the Internet and the telephone network (and other networks run by the PTTs) is that they have intelligence in the center of the network while we have most of the intelligence in the end-systems. The Internet way is right, even for real-time traffic. But current network layers (IPv4 and CLNP) don't support real-time, billing and many other things necessary for an Internet-style network for real-time applications like making a phone call. If we were going to make a decision soon then I'd pick: TUBA but using Paul Francis's IPIT transition; plus continued experiment with PIP and SIP leading to a later decision between PIP and SIP for the Internet's "real-time++" protocol. However that scheme almost guarantees a transition out of CLNP or running 2 Internet protocols for ever. We may have time to avoid that by choosing SIP or PIP to do it all. Clearly this depends on how urgent it is to make a decision, and that is something of which I'm not sure. However if at all possible I hope that the IESG/IAB will limit themselves to a "Statement of Direction" at this stage. Bob Smart From owner-Big-Internet@munnari.oz.au Sun Jul 25 16:37:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27926; Sun, 25 Jul 1993 16:37:28 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307250637.27926@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27913; Sun, 25 Jul 1993 16:37:03 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa09722; 25 Jul 93 2:36 EDT To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of Sun, 25 Jul 1993 10:25:13 +1000. <9307250025.AA14683@squid.mel.dit.CSIRO.AU> Date: Sun, 25 Jul 1993 02:36:44 -0400 From: John Curran -------- ] From: Bob Smart ] Subject: Re: IPDECIDE BOF minutes ] Date: Sun, 25 Jul 93 10:25:13 +1000 ] ... ] Also whatever else happens we are going to end up with: (a) TCP and ] UDP running over CLNP networks; and (b) some large and important ] CLNP networks almost certainly including a world-wide one on the ] scale of the Internet. I agree; this is happening already and hence "stopping it" may not be practical. It might be possible to "redirect" such efforts if there was a long-term convergence plan. ] So if we are going to have one solution it has to be TUBA. I'm not sure I agree with the above. How about: "If we're going to have one solution, then it has to be accepted as successor to both IP and TUBA." This could be because IPng is TUBA, or because IPng is something else that TUBA folks are willing to move to. ] If we were going to make a decision soon then I'd pick: TUBA but using ] Paul Francis's IPIT transition; plus continued experiment with PIP ] and SIP leading to a later decision between PIP and SIP for the ] Internet's "real-time++" protocol. Hmm. I'm not ready to cast my vote yet, but it will probably go to the first operationally mature protocol with variable length addresses and default autoconfiguration of end systems. There's a lot more functionality needed long-term (such as resource reservation and authentification) but I'd rather see such features omitted than included as unproven options. /John From owner-Big-Internet@munnari.oz.au Mon Jul 26 01:54:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22989; Mon, 26 Jul 1993 01:54:33 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22980; Mon, 26 Jul 1993 01:54:18 +1000 (from ses@tipper.oit.unc.edu) Received: from gibbs.oit.unc.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09030 Sun, 25 Jul 1993 22:14:16 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA23676; Sun, 25 Jul 93 08:11:41 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA03414; Sun, 25 Jul 93 08:13:56 EDT Message-Id: <9307251213.AA03414@tipper> X-Really-To: gibbs.oit.unc.edu To: John Curran Cc: Bob Smart , big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Sun, 25 Jul 93 02:36:44 EDT." <9307250637.27926@munnari.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 25 Jul 93 08:13:55 -0400 From: Simon E Spero John Curran writes: > >Hmm. I'm not ready to cast my vote yet, but it will probably go to the >first operationally mature protocol with variable length addresses and >default autoconfiguration of end systems. There's a lot more functionality >needed long-term (such as resource reservation and authentification) but >I'd rather see such features omitted than included as unproven options. I'd mostly agree with that except that I don't think that things like resource reservation can be left for the next go around; this is functionality which we need today (actually, last week), and if there's no place reserved for it in IP-TNG, then people who need to deliver multi-media will just roll their own, and as anybody who's spent the last 8 months trying to get Cablevision to turn on the sci-fi channel will tell you, that's _bad_ news. That said, none of the resource-reservation and flow oriented proposals are really mature enough to make a part of the TNG standards. As long as there is a place reserved for ST-III (The search for spock) or whatever, I'll be happy. One last comment; Even if TUBA is chosen, if it do everything that TNG is supposed to do, then it won't be CLNP. None of the proposed candidates have an installed base - they are all competing on a level footing. TO sum up: Isochronicity Si! ISO Crony City , Non! Simon From owner-Big-Internet@munnari.oz.au Mon Jul 26 01:54:10 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22971; Mon, 26 Jul 1993 01:54:23 +1000 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22964; Mon, 26 Jul 1993 01:54:10 +1000 (from atkinson@itd.nrl.navy.mil) Received: from itd.nrl.navy.mil by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10121 Sun, 25 Jul 1993 23:34:56 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA16497; Sun, 25 Jul 93 09:33:30 EDT Date: Sun, 25 Jul 93 09:33:30 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307251333.AA16497@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes I'm not sure I agree with the assertion that the worldwide CLNP network will be of the same order of magnitude as the Internet. TCP/IP is growing its installed base inside Europe much faster than TP4/CLNP is. TCP/IP has long been way ahead of OSI inside Australia, Canada, and Asia. TCP/IP is quite healthy and growing in Japan. In part this is because the networking research community, even in Europe (for example INRIA and UCL), mostly feeds new technology directly into the IETF and helps it get transitioned into operational systems. Rather fewer in the research community are still working closely with the OSI stack -- chiefly because the ISO process is sooo much more painful than the IETF way. The US Government buys almost all of its systems as dual-stack (TCP/IP and TP4/CLNP) but almost no one ever turns on the OSI stack. I requested CLNP addresses from the Navy (which does reportedly have a block of CLNP addresses) for my systems in May 1992 and have not received any yet. At last report, the appropriate part of the Navy had not developed a process to issue/administer permanent OSI addresses for Navy systems. So they would be willing to give me some "experimental" OSI addresses, but those would be subject to complete change at any time without prior notice (not exactly an operationally viable situation). Given the problems that I am having in getting addresses, you can certainly bet your bottom dollar that operational parts of the Navy aren't using OSI very much. So my current "OSI transition plan" is to either SIP or PIP. CLNP/TUBA is a non-starter because it lacks technical capabilities that I need, which are present in IPv4, and also lacks useful new features provided in both SIP and PIP. The ISO Network Layer Security Protocol (NLSP) spec sets new record lows in the readability of an ISO specification. The DoD's SP3 security protocol is clearly superiour to NLSP, not only in readability but also in scalability upwards to gigabit networks and downwards to low-bandwidth RF nets. The "swIPe" proposal also appears much better than NLSP. The best security protocol for IP/SIP/PIP would probably be to merge SP3 and swIPe together. I have seen substantial bidirectional cross-fertilisation of ideas between the SIP crowd and the PIP crowd. I think this has been a worthwhile exercise so far and is helping to ensure that IP:TNG will really be a significant technological improvement from IPv4. Both PIP and SIP have demonstrated their viability over IPv4-only links. Both PIP and SIP support real-time flows and multicasting. Both PIP and SIP have real working implementations (SIP appears to have more independent implementations than PIP). While many speak up for variable length addresses, not many have mulled over the security implications of them. I am beginning to think that the real attraction of variable length addresses is that it makes people "feel" better because they aren't taking the time to do math on how many address bits we really need. I would really like to see more postings with math talking about address size needs and tradeoffs. Sorry for the rambling nature of this note. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Mon Jul 26 11:31:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20453; Mon, 26 Jul 1993 11:31:54 +1000 (from owner-Big-Internet) Return-Path: Received: from POSTOFFICE.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20439; Mon, 26 Jul 1993 11:31:30 +1000 (from swb1@cornell.edu) Received: from [132.236.236.55] (CU-DIALUP-0213.CIT.CORNELL.EDU) by postoffice.mail.cornell.edu with SMTP id AA22771 (5.65c8/IDA-1.4.4 for big-internet@munnari.oz.au); Sun, 25 Jul 1993 21:31:10 -0400 Message-Id: <199307260131.AA22771@postoffice.mail.cornell.edu> Date: Sun, 25 Jul 1993 21:31:54 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au From: Scott Brim X-Sender: swb1@postoffice.mail.cornell.edu Subject: Re: N^2 growth... >So, either a) you have to provide a mandatory topology interconnection >scheme, or some similar device, which does forcibly mandate lower growth >rates, or b) give up on *any* scheme (*including* resource reservation >architectures, flow installation for special policy requirements, etc) which >require per-flow state be stored. The latter is quite a serious restriction, >and would invalidate much research currently being done. Yup. This was the basis for the "Unified" approach. It's also why I wonder how far, e.g. RSVP, can be taken. I wouldn't say it invalidates the research, but it certainly makes the research inapplicable [is that a word?] on a large scale. The issue is important for multicast routing too. There isn't any multicast routing scheme which, for the worst-case router, scales better than O(the number of groups passing through the router) -- the N^2 problem again. By the way the number I'm using these days is 20,000,000 simultaneous active wide-area groups, 20 years from now. Scott From owner-Big-Internet@munnari.oz.au Mon Jul 26 18:09:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06605; Mon, 26 Jul 1993 18:09:40 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307260809.6605@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06600; Mon, 26 Jul 1993 18:09:25 +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, 26 Jul 1993 09:09:04 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: how widespread, really? In-Reply-To: Your message of "Fri, 23 Jul 93 17:20:54 EDT." <9307232120.AA09760@ginger.lcs.mit.edu> Date: Mon, 26 Jul 93 09:09:03 +0100 From: Jon Crowcroft > > John Wroclawski of MIT and I were discussing the fact that the Internet > > is not suffering congestive collapse at the moment mostly because > > everyone has implement Van Jacobsen's TCP algorithms, > Is this speculation on your part >Well, yes, to some degree it is speculation, and I'm well aware it could be >wrong. For all I know, there isn't any congestion because the NSF backbone >guys are doing a great job keeping the available bandwidth ahead of demand, >and distributed VJCC doesn't even work as well as I think it does. this is silly - you can find out what systems are out there from dns and other stuff of course most of themn do VJCC...if they didn't we wouldnt let them on the UK nets for instance - just log a few tcp connections through a FIX and whatch them slow startings and fast rtx ing or congestion avoiding - its there.... >Again, here's what John has to say: > > I didn't think everybody would end up using the same algorithms, but once > everybody started copying the Berkely code, TCP implementations seem to > have converged. It's interesting to see how that worked. this is key - how do we get people to adopt TCP for VBR traffic, and an analogous technologuy for admision control for constant bitrate traffic (and mandate in the usualy anarchic internet way no other Wide Area use of UDP!)? the main logistical way forward is a) watch the Internet collapse badly under load when 3 conferencies like IETF try to multicast audio and video at the same time b) make sure someone like van can't get any bboard feeds becasuse the net is in such a heap c) wait for them toi write i) the code ii) the seminal paper... d) put the code up on the net in such a way that no sane vendor can refuse to add it to their release... e) more on to another area of research... jon From owner-Big-Internet@munnari.oz.au Mon Jul 26 20:01:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10660; Mon, 26 Jul 1993 20:02:18 +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 AA10652; Mon, 26 Jul 1993 20:01:51 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA18240; Mon, 26 Jul 1993 12:02:47 +0200 Message-Id: <199307261002.AA18240@mitsou.inria.fr> To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: how widespread, really? In-Reply-To: Your message of "Mon, 26 Jul 93 09:09:03 BST." <9307260809.6605@munnari.oz.au> Date: Mon, 26 Jul 93 12:02:47 +0200 From: Christian Huitema Jon, The new version of the IVS videoconference will come out with a congestion avoidance scheme similar to that of TCP -- take reported losses as congestion signals, and immediately reduce the data rate. So, maybe we will not congest the Internet after all. Note that this is easy to for video -- one can easily decrease bits per pixel or frames per second -- but much more difficult for voice. More precisely, current voice encoders are pretty much fixed speed. Maybe one first step would be for Van to implement an automatic back-off within VAT from PCM to ADPCM to GSM as a response to congestion signals... Also. These back-off procedures work well on point to point links, almost well in small groups, not so well in very large groups. If one ends up doing "Internet broadcasts", then one is pretty much reduced to open loop control! Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Jul 26 21:26:29 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13440; Mon, 26 Jul 1993 21:26:41 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307261126.13440@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13437; Mon, 26 Jul 1993 21:26:29 +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, 26 Jul 1993 12:25:42 +0100 To: Christian Huitema Cc: big-internet@munnari.oz.au Subject: Re: how widespread, really? In-Reply-To: Your message of "Mon, 26 Jul 93 12:02:47 +0100." <199307261002.AA18240@mitsou.inria.fr> Date: Mon, 26 Jul 93 12:25:41 +0100 From: Jon Crowcroft >Note that this is easy to for video -- one can easily decrease bits per pixel >or frames per second -- but much more difficult for voice. More precisely, >current voice encoders are pretty much fixed speed. Maybe one first step would >be for Van to implement an automatic back-off within VAT from PCM to ADPCM to >GSM as a response to congestion signals... i think constant bit rate stuff shouildn't back off, it should use admission ctl... >Also. These back-off procedures work well on point to point links, almost well >in small groups, not so well in very large groups. If one ends up doing >"Internet broadcasts", then one is pretty much reduced to open loop control! we need a back-ff bake-off! jon From owner-Big-Internet@munnari.oz.au Mon Jul 26 23:24:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17338; Mon, 26 Jul 1993 23:25:03 +1000 (from owner-Big-Internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17331; Mon, 26 Jul 1993 23:24:47 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA23221; Mon, 26 Jul 93 09:24:41 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA04224; Mon, 26 Jul 93 09:26:56 EDT Message-Id: <9307261326.AA04224@tipper> X-Really-To: gibbs.oit.unc.edu To: Christian Huitema Cc: Jon Crowcroft , big-internet@munnari.oz.au Subject: Re: how widespread, really? In-Reply-To: Your message of "Mon, 26 Jul 93 12:02:47 +0200." <199307261002.AA18240@mitsou.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Jul 93 09:26:56 -0400 From: Simon E Spero For audio bandwidth reduction, the most obvious way of reducing bandwidth is to reduce the number of bits used to encode the signal. I tried a few experiments with this on some talk radio files, and found that for voice you could cut down to as little as 2 bits of resolution and still be able to more or less understand what was being said. This gives you a fair amount of room to allow the signal to degrade gracefully. As for dealing with multicast over links that have different capacities; the only graceful way I can see of handling this is splitting off into multiple multi-cast groups, and slowing down the transmission for the slow-coaches. The most efficient place for this degradation would be at the interior nodes feeding the slower parts of the group; given the load which mrouted already puts on a system this probably isn't practical Simon From owner-Big-Internet@munnari.oz.au Tue Jul 27 01:56:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23887; Tue, 27 Jul 1993 01:56:45 +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 AA23871; Tue, 27 Jul 1993 01:56:18 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11640>; Mon, 26 Jul 1993 08:55:40 PDT Received: by redwing.parc.xerox.com id <57154>; Mon, 26 Jul 1993 08:55:34 -0700 Date: Mon, 26 Jul 1993 08:55:27 PDT Sender: Lixia Zhang From: Lixia Zhang To: Scott Brim Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au Subject: Re: N^2 growth... In-Reply-To: Your message of Sun, 25 Jul 1993 18:31:54 -0700 Message-Id: > >So, either a) you have to provide a mandatory topology interconnection > >scheme, or some similar device, which does forcibly mandate lower growth > >rates, or b) give up on *any* scheme (*including* resource reservation > >architectures, flow installation for special policy requirements, etc) which > >require per-flow state be stored. The latter is quite a serious restriction, > >and would invalidate much research currently being done. > > Yup. This was the basis for the "Unified" approach. It's also why I > wonder how far, e.g. RSVP, can be taken. I wouldn't say it invalidates the > research, but it certainly makes the research inapplicable [is that a > word?] on a large scale. The issue is important for multicast routing too. > There isn't any multicast routing scheme which, for the worst-case router, > scales better than O(the number of groups passing through the router) -- > the N^2 problem again. By the way the number I'm using these days is > 20,000,000 simultaneous active wide-area groups, 20 years from now. I dont have time to jump into this interesting N^2 growth discussion yet but feel that I need to clarify some (mis)conception about the work of resource-reservation, RSVP, etc. Lets look at RSVP for example, RSVP simply assists setting state in switches that says "this much resource can be used by all pkts that match this filter", where the filter is specified as a bitmask. Therefore there is NOTHING that constrains RSVP to working on per flow basis--the granularity of RSVP state is determined by your choice of the mask, not RSVP itself. From owner-Big-Internet@munnari.oz.au Tue Jul 27 02:08:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24261; Tue, 27 Jul 1993 02:08:45 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24258; Tue, 27 Jul 1993 02:08:28 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA20079; Mon, 26 Jul 93 12:08:21 EDT Date: Mon, 26 Jul 93 12:08:21 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307261608.AA20079@itd.nrl.navy.mil> To: jcurran@nic.near.net Subject: Re: addressing... Cc: big-Internet@munnari.oz.au John, Security can be MUCH harder to get working correctly when addresses are variable length. Fields whose values change during transit are even harder to secure. Before signing up to either of these, there needs to be more thoughtful consideration of all of the impacts of such a decision. I believe the embedding of technology-dependent addresses into the IP or IPng addresses to be highly undesirable. For example, I want my ATM and Frame Relay and Ethernet addresses to be distinct from my IP or IPng address. For one example, a single host might have multiple interfaces and one still needs to be able to connect to it even though one interface is down. Interface-independent addresses facilitate this, but are incompatible with embedding other addresses into IP or IPng addresses. For another example, if I swap out my Ethernet card and replace it with another Ethernet card or with an FDDI card to improve performance, my host address should remain constant (even though my MAC address will have changed). I do not want or desire to mix or mingle E.164 addresses with my IPng address space. I believe that "divide and conquer" is a better approach to routing problems than "mix and mingle". For example, one of the problems in ATM Forum "Private Network Addressing" is that those ATM addresses appear to be, but are not the same as ISO CLNP addresses. Those two addresses have similar syntax but not necessarily the same semantics. E.164 addresses (i.e. telephone numbers) are also problematic and should not be embedded in IP or IPng addresses. Large blocks of them are not at all heirarchical (e.g. US 700, 800, and 900 area codes). Even in local conventional numbers, not all addresses are heirarchical. C&P Telephone does a good business locally in selling out-of-local-area numbers to people (this includes selling "DC metro" numbers to folks outside the local DC calling area). Moreover, E.164 addresses are not available in an unbiased vendor-neutral and user-neutral manner in the US or most other countries on the planet. E.164 address control is one of the most powerful tools in the hands of de facto/de jure telephone monopolies on the planet. We don't need to get IP or IPng into that morass. Life is interesting enough with the existing technical problems. Regards, Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.oz.au Tue Jul 27 02:14:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24428; Tue, 27 Jul 1993 02:15: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 AA24423; Tue, 27 Jul 1993 02:14:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29883; Mon, 26 Jul 93 12:14:43 -0400 Date: Mon, 26 Jul 93 12:14:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307261614.AA29883@ginger.lcs.mit.edu> To: atkinson@itd.nrl.navy.mil, big-Internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes Cc: jnc@ginger.lcs.mit.edu While many speak up for variable length addresses, not many have mulled over the security implications of them. I'm not quite sure I see what you're getting at here; surely any security problems with addresses (such as spoofing, etc) exist whether the address is fixed or variable in lenght? I am beginning to think that the real attraction of variable length addresses is that it makes people "feel" better because they aren't taking the time to do math on how many address bits we really need. I would really like to see more postings with math talking about address size needs and tradeoffs. Well, addressing has been discussed extensively on this list, and I personally would be absolutely amazed if further debate brought any more agreement than we already have. There are a number of disagreements on fairly fundamental points which prevent us even getting to doing math. Some examples: - Many people don't think we can quantify future needs well enough to try and do a fixed (and thus inflexible) design. - There is disagreement on the need to have internetwork addresses contain complete physical addresses (e.g. X.121/E.164 addresses), to avoid the pain of internet->physical address translation in a WAN - There is disagreeement on the need to have addresses name abstractions about which policy statements can be made (e.g. "the Mass Pike is a toll road") Lacking agreement on these points, there's no possible way any math by one side will be taken seriously by the other side. Noel From owner-Big-Internet@munnari.oz.au Tue Jul 27 02:25:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24882; Tue, 27 Jul 1993 02:25: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 AB24879; Tue, 27 Jul 1993 02:25:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00365; Mon, 26 Jul 93 12:25:08 -0400 Date: Mon, 26 Jul 93 12:25:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307261625.AA00365@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, swb1@cornell.edu Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu > So, either a) you have to provide a ... device, which does forcibly > mandate lower growth rates, or b) give up on *any* scheme ... which > require per-flow state be stored. Yup. This was the basis for the "Unified" approach. Since there area *already* too many simultaneous debates going on on Big-I, I'm not going to start another, but let me just note (without providing my reasons, which would cause another debate :-) that I don't agree with your apparent assertion that Unified is different, and leave it at that for now... There isn't any multicast routing scheme which, for the worst-case router, scales better than O(the number of groups passing through the router) -- the N^2 problem again. You seem to be missing the point of my basic argument; I'm virtually certain it's *not* O(N^2)! In that message I was only trying to point out why it's important that we show it's not O(N^2). Noel From owner-Big-Internet@munnari.oz.au Tue Jul 27 02:30:05 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25256; Tue, 27 Jul 1993 02:30:15 +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 AA25252; Tue, 27 Jul 1993 02:30:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00416; Mon, 26 Jul 93 12:30:00 -0400 Date: Mon, 26 Jul 93 12:30:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307261630.AA00416@ginger.lcs.mit.edu> To: lixia@parc.xerox.com, swb1@cornell.edu Subject: Re: N^2 growth... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu RSVP simply assists setting state in switches that says "this much resource can be used by all pkts that match this filter", where the filter is specified as a bitmask. Therefore there is NOTHING that constrains RSVP to working on per flow basis--the granularity of RSVP state is determined by your choice of the mask, not RSVP itself. Lixia, thanks for the clarification. Let me ask one question though; to the extent that more than one flow matches an RSVP 'class' (or whatever the correct term is), RSVP can't allocate resources among those flows, right? Noel From owner-Big-Internet@munnari.oz.au Tue Jul 27 03:19:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26943; Tue, 27 Jul 1993 03:20: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 AA26933; Tue, 27 Jul 1993 03:19:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00623; Mon, 26 Jul 93 13:19:45 -0400 Date: Mon, 26 Jul 93 13:19:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307261719.AA00623@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, swb1@cornell.edu Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu On the other hand I'd like some clarification. You know me, happy to clarify until everyone's eyes/ears have fallen off in boredom! :-) You are hoping that it isn't N^2, but did I miss where you actally try to see if it is or not? No, I'm not just hoping that the number of flows through the most loaded switches isn't growing as O(N^2) (where N is the number of end-nodes in the Internet). I believe that, making what I perceive to be the reasonable assumption that the bandwidth of the average flow is not falling drastically over time (something like, say, O(1/N)), you can *prove* that the growth in flows through a switch *cannot* exceeed the growth of bandwidth through the switch. I'll finish polishing the text cobbled from the debate I had with JMH, and send it in. I believe I hear you saying that it doesn't matter if our designs are O(N^2) wrt state, since physical reality (bandwidth capability) will keep us from ever reaching the limit of the design. No; as I understand it, the argument is made that we have O(N^2) state problems, not because a particular mechanism has O(N^2) state growth *in and of itself*, but because many mechansisms have state requirements in a switch linearly related to the number of flows through a switch, and in 'hot spot' switches, *that* number is growing at O(N^2). I happen to think that latter calculation is wrong, and 'physical reality' prevents us reaching O(N^2) flow growth. It's not that we don't have an N^2 problem, but whether we do or not, we have a worse problem, right? No, I don't think we do have an O(N^2) problem, but *if we did*, it would screw all sorts of things (including Unified, but let's not get into that now :-). Noel From owner-Big-Internet@munnari.oz.au Tue Jul 27 04:00:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28372; Tue, 27 Jul 1993 04:01:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9307261801.28372@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28366; Tue, 27 Jul 1993 04:00:51 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4917; Mon, 26 Jul 93 14:00:30 EDT Date: Mon, 26 Jul 93 13:58:41 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, swb1@cornell.edu Cc: jnc@ginger.lcs.mit.edu Subject: N^2 growth... Ref: Your note of Mon, 26 Jul 93 12:25:08 -0400 >I don't agree with your apparent assertion that Unified is different... Noel, Being one of the co-authors of Unified, I would like to say that I AGREE with Scott's assertion and disagree with yours. Yakov. P.S. This is CERTAINLY NOT to start yet another discussion, but just to get records straight. From owner-big-internet@munnari.oz.au Tue Jul 27 06:29:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03375; Tue, 27 Jul 1993 06:31:07 +1000 (from owner-big-internet) Return-Path: Received: from POSTOFFICE.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25839; Tue, 27 Jul 1993 02:46:14 +1000 (from swb1@cornell.edu) Received: from [132.236.195.71] by postoffice.mail.cornell.edu with SMTP id AA15500 (5.65c8/IDA-1.4.4 for big-internet@munnari.oz.au); Mon, 26 Jul 1993 12:45:55 -0400 Message-Id: <199307261645.AA15500@postoffice.mail.cornell.edu> Date: Mon, 26 Jul 1993 12:46:38 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au From: Scott Brim X-Sender: swb1@postoffice.mail.cornell.edu Subject: Re: N^2 growth... >You seem to be missing the point of my basic argument; I'm virtually certain >it's *not* O(N^2)! In that message I was only trying to point out why it's >important that we show it's not O(N^2). Understood. I was just raising the stakes. On the other hand I'd like some clarification. You are hoping that it isn't N^2, but did I miss where you actally try to see if it is or not? I believe I hear you saying that it doesn't matter if our designs are O(N^2) wrt state, since physical reality (bandwidth capability) will keep us from ever reaching the limit of the design. It's not that we don't have an N^2 problem, but whether we do or not, we have a worse problem, right? Coming to Houston? Scott From owner-big-internet@munnari.oz.au Tue Jul 27 06:49:04 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03927; Tue, 27 Jul 1993 06:49:48 +1000 (from owner-big-internet) Received: from gateway.mitre.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26068; Tue, 27 Jul 1993 02:56:03 +1000 (from barns@cove.mitre.org) Return-Path: Received: from cove.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA16780; Mon, 26 Jul 93 12:55:32 -0400 Received: by cove.mitre.org (4.1/SMI-4.1) id AA03907; Mon, 26 Jul 93 12:55:06 EDT Message-Id: <9307261655.AA03907@cove.mitre.org> To: atkinson@itd.nrl.navy.mil (Ran Atkinson) Cc: big-Internet@munnari.oz.au, barns@cove.mitre.org Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Sun, 25 Jul 93 09:33:30 EDT." <9307251333.AA16497@itd.nrl.navy.mil> Date: Mon, 26 Jul 93 12:55:05 -0400 From: barns@cove.mitre.org Ran, I think you're mixing apples and oranges somewhat and sort of glossing over a real problem which is protocol-independent. The Navy's real address assignment problem (unfortunately not unique to the Navy) is that they haven't got anyone who understands at a global level what the Navy has got or is in the process of making, routing-topology-wise. If you can't get NSAPs out of Bob Cooney, or if the Navy forgot to tell you that you were supposed to ask Bob Cooney, then the problem is with the workings of the Navy and not with CLNP. The Navy has sources to get (legitimate, global, etc.) routing domain blocks of NSAPs from. I think they do not have an adequate infrastructure to make a coherent addressing/routing plan, and the Navy is far from alone in this. As I see it, this is a route aggregation problem, and thus SIP, PIP, and even CIDR have the same need for this kind of management infrastructure that CLNP has. Personally, I believe that existing DOD IP growth plans are enough to create serious risk of breaking the backbone (i.e., too many routes to fit in a Cisco box). So I keep pressing for the service/agency address (and routing) planning problem to be worked. Some of the S/A people have the right idea (for example, NCTS-Pensacola), but bemoan that they can't control the rest of their S/A people. The Air Force is sort of trying (successful more often than not, but haven't won the war), and I can't tell where the Army is at. /Bill Barns (speaking for no one) p.s. NCTC has probably long since forgotten that you asked for NSAPs. Cooney's shop is not an "operational" organization. If you still want NSAPs, ask again. Talk or write to Cooney personally if necessary. If that doesn't work, let me know. Much (most?) of his shop works on NIF reimburseable basis and I know some of the people who give him money. From owner-big-internet@munnari.oz.au Tue Jul 27 07:35:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05153; Tue, 27 Jul 1993 07:36:54 +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 AA26366; Tue, 27 Jul 1993 03:05:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00573; Mon, 26 Jul 93 13:05:14 -0400 Date: Mon, 26 Jul 93 13:05:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307261705.AA00573@ginger.lcs.mit.edu> To: atkinson@itd.nrl.navy.mil, jcurran@nic.near.net Subject: Re: addressing... Cc: big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Security can be MUCH harder to get working correctly when addresses are variable length. Can you please provide some examples? Fields whose values change during transit are even harder to secure. Agreed, but these are two distinct things. People who may like the former don't necessarily like the latter. Even though there may be specific designs which have both, please don't tie them together. For one example, a single host might have multiple interfaces and one still needs to be able to connect to it even though one interface is down. Interface-independent addresses facilitate this, but are incompatible with embedding other addresses into IP or IPng addresses. If the interfaces are to different nets (which is the best way to get reliability), then as long as the internet addresses contain any information about where those interfaces are (i.e. if you can route on them directly), then you can't have one address to name all the interfaces. If you really want a name which stays the same, no matter which interface you use (or where the host has moved), use an EID. I don't get it. People keep trying to have *one* thing (which they call an 'address'), which: - is direct input to the routing functionality in the router, i.e. it says where in the network this thing is, - stays the same, even when the hosts moves, or if the host has several different interfaces Aren't you bothered by the fact that you're trying to make one thing perform two diametrically opposed functions? For another example, if I swap out my Ethernet card and replace it with another Ethernet card or with an FDDI card to improve performance, my host address should remain constant (even though my MAC address will have changed). The MAC address *will* have changed, the only questions are "where is the binding from the higher level concept to the MAC address", and "how much work is it to change it". If a reasonably cheap mechanism for mobile hosts exists (and it we use it a lot, it *better* be reaonably cheap), then we can handle this *infrequent* case as an instance of that, and not have to have a whole special mechamism (ARP) which basically provides mobility only on a local basis. I do not want or desire to mix or mingle E.164 addresses with my IPng address space. I believe that "divide and conquer" is a better approach to routing problems than "mix and mingle". ... E.164 addresses are also problematic and should not be embedded in IP or IPng addresses. Large blocks of them are not at all heirarchical ... Even in local conventional numbers, not all addresses are heirarchical. This is a persistent source of confusion when I bring this up. (I talked about this in message to Big-I on Date: Wed, 7 Jul 93 11:43:57 -0400) I *don't* propose to use the structure in WAN addresses to do internet routing on (by and large, although it's possible). I am using the E.164 address in exactly the same way as an 802 address; i.e. the unique name, *in the form used by the transmission media*, of one interface among a small group of all those potentially named by that address space. Funnily enough, over in VC-Routing I've just been trying to argue them out of doing complex routing in the network layer, i.e. making use of such structure as there is in E.164 addresses... Noel From owner-Big-Internet@munnari.oz.au Tue Jul 27 08:02:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06134; Tue, 27 Jul 1993 08:02: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 AA06125; Tue, 27 Jul 1993 08:02:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28317; Mon, 26 Jul 93 18:01:56 -0400 Date: Mon, 26 Jul 93 18:01:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307262201.AA28317@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, swb1@cornell.edu, yakov@watson.ibm.com Subject: Re: N^2 growth... Your statement that O(N^2) would adversly impact Unified is nothing more than an unsubstantiated statement. And it is incorrect !!! In fact, the whole idea behind Unified is to use src/dst sensitive state ONLY when needed, and NOT for ALL possible sorts of communications. That avoids the state overhead problem. Sigh. Scott, I'm gonna strangle you! :-) Yakov, let me make sure I understand a few things. - First, I assume by 'Unified' you are referring both to Unified and SDRP? This doesn't change my analysis, I just want to be precise if you mean to exclude SDRP. - Second, as I understand it, Unified/SDRP does use per flow state *for some flows*, those which i) have policy requirements which are source specific, or otherwise not one of those supported by the 'precomputed route' part of Unified, and ii) are long enough in duration to make it economical to use the recently announced 'flow setup' mechanism of SDRP (not just the original source routed packet stuff). Is this correct? - Third, can you explain to me your model for the share of the end-end traffic streams (i.e. flows, but less formally) in the system will be using this flow setup mechanism? Will it be approximately a fixed share over time, or growing slightly, or what? With the answers in hand, I hope I can either i) see an error in my thinking, or ii) make a detailed case as to why it's correct. Noel From owner-Big-Internet@munnari.oz.au Tue Jul 27 08:23:16 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06828; Tue, 27 Jul 1993 08:26:21 +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 AA06746; Tue, 27 Jul 1993 08:23:16 +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 AA18335; Mon, 26 Jul 93 15:22:38 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA20998; Mon, 26 Jul 93 15:22:42 PDT Received: by bigriver.Eng.Sun.COM (5.0/SMI-SVR4) id AA02723; Mon, 26 Jul 1993 15:22:35 +0800 Date: Mon, 26 Jul 1993 15:22:35 +0800 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9307262222.AA02723@bigriver.Eng.Sun.COM> To: Bob Smart Cc: big-internet@munnari.oz.au In-Reply-To: <9307250025.AA14683@squid.mel.dit.CSIRO.AU> Subject: Re: IPDECIDE BOF minutes Content-Length: 493 Bob, > Also whatever else happens we are going to end up with: (a) TCP and > UDP running over CLNP networks; and (b) some large and important > CLNP networks almost certainly including a world-wide one on the > scale of the Internet. Could describe the "world-wide CLNP network on the scale of the Internet" in more detail. I am unaware of a such a network and would like to learn more about it. Please include number of sub-networks, routers, hosts, and current traffic. Thanks, Bob From owner-big-internet@munnari.oz.au Tue Jul 27 09:22:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08773; Tue, 27 Jul 1993 09:24:13 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307262324.8773@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27527; Tue, 27 Jul 1993 03:38:07 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa05391; 26 Jul 93 13:37 EDT To: Ran Atkinson Cc: big-Internet@munnari.oz.au Subject: Re: addressing... In-Reply-To: Your message of Mon, 26 Jul 1993 12:08:21 -0400. <9307261608.AA20079@itd.nrl.navy.mil> Date: Mon, 26 Jul 1993 13:37:33 -0400 From: John Curran -------- From: Ran Atkinson Subject: Re: addressing... Date: Mon, 26 Jul 93 12:08:21 EDT John, Security can be MUCH harder to get working correctly when addresses are variable length. Fields whose values change during transit are even harder to secure. Before signing up to either of these, there needs to be more thoughtful consideration of all of the impacts of such a decision. Fields who values change in transit (due to translation or rewriting) will definitely be harder to secure. On the other hand, variable-length addresses does not imply "fields whose values change in transit". How does the potential for variable-length addresses make security harder? If it turns out that security is a show-stopper for variable-length addressing, then let's document it and eliminate it as an option for IPng. I believe the embedding of technology-dependent addresses into the IP or IPng addresses to be highly undesirable. For example, I want my ATM and Frame Relay and Ethernet addresses to be distinct from my IP or IPng address. If that's what you want, great. Of course, some folks may want flexibility to use these services in other ways. /John From owner-Big-Internet@munnari.oz.au Tue Jul 27 09:38:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09196; Tue, 27 Jul 1993 09:39:57 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09176; Tue, 27 Jul 1993 09:38:24 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA28369 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 27 Jul 1993 09:38:20 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA16384; Tue, 27 Jul 93 09:38:02 EST Message-Id: <9307262338.AA16384@wanda.mel.dit.CSIRO.AU> To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Mon, 26 Jul 93 15:22:35 +0800." <9307262222.AA02723@bigriver.Eng.Sun.COM> Date: Tue, 27 Jul 93 09:38:01 +1000 From: Bob Smart >Could describe the "world-wide CLNP network on the scale of the Internet" I was thinking geographically: multiple providers, countries, etc. However if Ran doesn't need it even though he is legally supposed to use it then I won't argue with the contention that we can toss out CLNP just as lightly as SIP or PIP. It certainly won't affect me. On another subject: I'd like to see more response on billing issues. We already have the situation where some sites get extra billing if they use more than a certain amount of bandwidth (I think alternet offers such a scheme). That means that those sites are unwilling to offer services like anonymous FTP because there is no way for the client side to say "bill me for packets in both directions". Another issue is connectedness. The dream of universal connectivity grows ever remoter. At the moment if I send mail to some site in the .su domain then the DNS records will cause my mailer to send unsuccessful connection attempts for 3 days before bouncing the mail. Should the DNS tell me unhelpful things like this? Is it possible to build an Internet-style architecture where name-service and information about available connectivity combine to give reasonable results. This is not just a network layer issue, but there is a network layer issue: the architecture of a future internet network layer should include mechanisms for end-systems to get connectivity information along with name service information. Obviously it should distinguish information about long-term connection information from temporary glitches. Bob Smart From owner-big-internet@munnari.oz.au Tue Jul 27 14:13:38 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18246; Tue, 27 Jul 1993 14:16:53 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307270416.18246@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02521; Tue, 27 Jul 1993 06:08:39 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 6825; Mon, 26 Jul 93 16:08:33 EDT Date: Mon, 26 Jul 93 16:07:37 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, swb1@cornell.edu Cc: jnc@ginger.lcs.mit.edu Subject: N^2 growth... Ref: Your note of Mon, 26 Jul 93 13:19:45 -0400 >I don't think we do have an O(N^2) problem, but *we we did*, it would >screw all sorts of things (including Unified, but let's not get into that >now) Noel, Your statement that O(N^2) would adversly impact Unified is nothing more than an unsubstantiated statement. And it is incorrect !!! In fact, the whole idea behind Unified is to use src/dst sensitive state ONLY when needed, and NOT for ALL possible sorts of communications. That avoids the state overhead problem. Yakov. From owner-big-internet@munnari.oz.au Tue Jul 27 17:35:53 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25372; Tue, 27 Jul 1993 17:37:34 +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 AA06115; Tue, 27 Jul 1993 08:01:38 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-13) id ; Mon, 26 Jul 1993 15:01:23 -0700 Date: Mon, 26 Jul 1993 15:01:23 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199307262201.AA01228@zephyr.isi.edu> To: jnc@ginger.lcs.mit.edu Subject: Re: N^2 growth... Cc: big-internet@munnari.oz.au *> *> And in any case, wouldn't some sort of `flow aggregation' take place? *> *> Depends on your model. Some do, such as routing only ones such as IDPR, and *> some don't, particularly ones which have resource allocation as well; these *> more or less have to keep each flow distinguished. *> Van has been telling us for the past 2-3 years that for resource allocation, flow aggregation in the networks backbones is a necessity for scaling. We believe him. I have not seen the details worked out yet, but they probably will be. Bob Braden From owner-big-internet@munnari.oz.au Tue Jul 27 20:59:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02687; Tue, 27 Jul 1993 21:01:11 +1000 (from owner-big-internet) Return-Path: Received: from gibbs.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15433; Tue, 27 Jul 1993 12:50:35 +1000 (from ses@tipper.oit.unc.edu) Received: from tipper.oit.unc.edu by gibbs.oit.unc.edu (5.64/10.1) id AA16932; Mon, 26 Jul 93 22:50:15 -0400 Received: from localhost.oit.unc.edu by tipper (4.1/SMI-4.1) id AA05142; Mon, 26 Jul 93 22:52:30 EDT Message-Id: <9307270252.AA05142@tipper> X-Really-To: gibbs.oit.unc.edu To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, swb1@cornell.edu Subject: Re: N^2 growth... In-Reply-To: Your message of "Mon, 26 Jul 93 13:19:45 EDT." <9307261719.AA00623@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Jul 93 22:52:30 -0400 From: Simon E Spero Noel - My ears and eyes are still attached, so I'll stick my neck out and ask for a bit of clarification... When you state that the bandwidth of the average flow will not decrease as the number of hosts increases are you saying that the number of possible switches will increase by a factor of N or that the number of flows will be limited so as to allow each flow that is accepted the same average bandwidth as before? Simon From owner-big-internet@munnari.oz.au Tue Jul 27 22:34:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05882; Tue, 27 Jul 1993 22:34:54 +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 AA01029; Tue, 27 Jul 1993 20:14:04 +1000 (from old@sunbim.be) Received: from sunbim.sunbim.be by ub4b.buug.be (5.65c/ub4b_02) id AA10354; Tue, 27 Jul 1993 12:13:33 +0200 Received: from amadeus.sunbim.be by sunbim.sunbim.be (4.1/SMI-4.1) id AA20239; Tue, 27 Jul 93 12:06:12 +0200 Received: from corea.sunbim.be by amadeus.sunbim.be (4.1/SMI-4.1) id AA17073; Tue, 27 Jul 93 12:11:13 +0200 Date: Tue, 27 Jul 93 12:11:13 +0200 From: old@sunbim.be (Olivier Dubois) Message-Id: <9307271011.AA17073@amadeus.sunbim.be> To: Bob.Hinden@Eng.Sun.COM Subject: Re: IPDECIDE BOF minutes Cc: big-internet@munnari.oz.au How about the ATN, Air Traffic Network, This is not yet a real network but a serious project of the eurocontrol organisation also impliying the IATA (International Association of Transport Airline, or something like that). The ATN is a serious project network that will link ALL flying aircraft to their controlling autorities. I have a 4" thick description of it on my desk. It will be a CLNP network (an internetwork in fact). IDRP routing will be used. The description and the study is very well advanced. This is not yet a real network but it is really seriously specified (when you deal with human lifes, you don't play). Olivier. From owner-big-internet@munnari.oz.au Wed Jul 28 00:31:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10888; Wed, 28 Jul 1993 00:31:38 +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 AA05008; Tue, 27 Jul 1993 07:29:01 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11716>; Mon, 26 Jul 1993 14:28:02 PDT Received: by redwing.parc.xerox.com id <57154>; Mon, 26 Jul 1993 14:27:50 -0700 Date: Mon, 26 Jul 1993 14:27:48 PDT Sender: Lixia Zhang From: Lixia Zhang To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: swb1@cornell.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: N^2 growth... In-Reply-To: Your message of Mon, 26 Jul 1993 09:30:00 -0700 Message-Id: > RSVP simply assists setting state in switches that says "this much resource > can be used by all pkts that match this filter", where the filter is > specified as a bitmask. Therefore there is NOTHING that constrains RSVP to > working on per flow basis--the granularity of RSVP state is determined by > your choice of the mask, not RSVP itself. > > Lixia, thanks for the clarification. Let me ask one question though; to the > extent that more than one flow matches an RSVP 'class' (or whatever the correct > term is), RSVP can't allocate resources among those flows, right? Sure, for things you cannot distinguish, you cannot treat separately. This being said, some clarification of another point seems in order: presumbly different levels of control granularity is needed at different places in the net (e.g. peripharel nodes controls with finer granularity that backbone switches). Therefore if one designs filters(masks) with a hierarchical structure that can match to that of the network, then we can have different portions of a mask being checked at diff network nodes, achieving the desired control granularity at each node. (Of course these are still ideas not real implementations--not yet:-) From owner-Big-Internet@munnari.oz.au Wed Jul 28 01:02:22 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12053; Wed, 28 Jul 1993 01:02:33 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12050; Wed, 28 Jul 1993 01:02:22 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA20006; Tue, 27 Jul 93 10:57:46 -0400 Date: Tue, 27 Jul 93 10:57:46 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9307271457.AA20006@er.doe.gov> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, swb1@cornell.edu, yakov@watson.ibm.com Subject: Re: N^2 growth... Some say the world will end in fire and some in ice but both are great and would suffice (Robert Frost, I think) It seems that this argument boils down to will the network die because the number of flows overwhelms the ability of the router to keep track of them (router memory) or will the network die first because the bandwidth per flow through the router goes to zero. For a given topology this is a comparison of your guess at the rate of inc- rease of router memory, the rate of increase of bandwidth through a router, and the # of flows needing bandwidth. There are certainly topologies which guarantee the occurrence of this sort of problem (a fractal star of stars for example). Note, however, that the issue is fundamentally one of network congestion with a multi-dimensional indicator. DH From owner-big-internet@munnari.oz.au Wed Jul 28 01:13:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12428; Wed, 28 Jul 1993 01:14:07 +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 AA11024; Tue, 27 Jul 1993 10:37:46 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA20803; Mon, 26 Jul 93 20:31:25 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA19730; Mon, 26 Jul 93 20:38:01 EDT Date: Mon, 26 Jul 93 20:38:01 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307270038.AA19730@cabernet.wellfleet> To: big-internet@munnari.oz.au, perk@watson.ibm.com Subject: Re: IPng: Keeping one's options open Cc: rcallon@wellfleet.com I think we can agree on two things: - We don't know when the current addresses and routing capability of the Internet will be exhausted - We have to have a solution and transition plan in effect before the exhaustion occurs Yes. It's the tension between the immovable and the irresistible that makes everyone nervous, and (I believe) is the cause of the current push for selecting a solution NOW. In a way, I agree with this. But, I think the development of IPng could be managed more effectively. I would suggest that we follow some variant of the following plan: - Select a leading contender - Make it work great I think that folks are already trying to get whichever proposals they are working on to work well. I have personally at least being trying to make what I consider to be constructive comments to multiple of the proposals (which seem to be easier to get listened to by some proposals than by others). I don't see why identifying one leading contendor will make it easier to improve than the current situation. If anything, the opposite is true: As long as there is no agreement, then each proposal has a reason to listen to reasonable input and to try to improve as quickly as possible. - Get a transition plan into place, including necessary testing - DON'T "switch over" until the feared exhaustion event appears imminent - Encourage academia to analyze the leading contender More important, in my opinion, is analysis by the folks who actually will need to deploy the solution -- particularly routing vendors and public service providers. Sometimes things that general consensus seems to think needs to be minimized (and which would be the obvious things for academic analysis to look at) are actually less important than some things that are overlooked, but it is the folks who have to build and deploy the resulting systems which will know the best about this. Vendors also see customer situations and issues which can be easily solved by some solutions, and which would be very hard to solve with other solutions. Some of the leading proposals are accepting a lot of input from these folks, some are not. I think that it is **VERY** important that **ALL** of the proposals listen to input from routing vendors and public service providers. - Encourage developers to try to "beat" the leading contender - If another contender can surpass the leader, and put into place its separate transition place and necessary testing, then it can become the leading contender I think that this is relatively close to what it actually happening (except that some folks want a decision to be made). - Until the "switch over" occurs, IPng is explicitly in flux and problems that might be discovered by (say) researchers in the various academic institutions could be solved by (incrementally) modifying the leading candidate. Of course, I would say that problems that are discovered by the folks who need to build products should also be incrementally fixed. I don't think that identifying one leading candidate will make it more likely that such problems will actually be fixed. The concerns, of course, will be to avoid fragmenting development resources and to minimize the total costs of the "switch over". However, it is my strong belief that IPng must address the issues of quality of service and autoconfiguration, and those are areas which do not have intuitively obvious answers in the context(s) of the IPng candidates. Thus I hope that the process of selection and implementation will allow for the possibility of solving those critical problem areas. Charlie P. With the few notes above, I basically agree with you. The IETF has succeeded because we are able to allow multiple approaches to be built, and wait to see which ones actually work best. In the case of IPng, we cannot actually tell which ones work best until they have been deployed in a relatively large network, with a variety of underlying subnet types (for example, I would like to deploy a solution with some traffic over telephone networks, on the basis that if the Internet is going to be deployed to homes and/or small businesses in the near future, it is probably going to use wireing that is in place today). My fear is that political pressures will force us to make a decision which is not technically sound. I think that it will be very hard to fix a solution *after* it is agreed to. I don't care much *which* solution is chosen, but I care a lot that it works well. Ross From owner-Big-Internet@munnari.oz.au Wed Jul 28 02:06:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14172; Wed, 28 Jul 1993 02:07:42 +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 AA14140; Wed, 28 Jul 1993 02:06:20 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22962; Tue, 27 Jul 93 12:00:20 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA20012; Tue, 27 Jul 93 12:06:59 EDT Date: Tue, 27 Jul 93 12:06:59 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307271606.AA20012@cabernet.wellfleet> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, swb1@cornell.edu Subject: Re: N^2 growth... There isn't any multicast routing scheme which, for the worst-case router, scales better than O(the number of groups passing through the router) -- the N^2 problem again. What???? Never mind whether this is n-squared or not. Multicast is not going to work in a very large Internet unless it scales better than O(the number of groups passing through the router). While I agree that Multicast OSPF has this problem, it is my understanding that the core based tree approach allows a multicast group to pass through a router without that router being aware of the multicast-ness of the group. Thus (again, based on my understanding of core based tree multicast) this will require only those routers which actually "split" a packet (get one packet in, and need to send it out multiple ways) to be aware that it is multicast. We should ask Paul Francis whether this is true of the core based tree multicast. If not, then we will need yet another form of multicast. Ross From owner-Big-Internet@munnari.oz.au Wed Jul 28 03:21:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17147; Wed, 28 Jul 1993 03:22:16 +1000 (from owner-Big-Internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17104; Wed, 28 Jul 1993 03:21:39 +1000 (from medin@nsipo.nasa.gov) Received: Tue, 27 Jul 93 10:20:41 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9307271720.AA03938@cincsac.arc.nasa.gov> To: Bob Smart Cc: Bob.Hinden@eng.sun.com (Bob Hinden), big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Tue, 27 Jul 93 09:38:01 +1000." <9307262338.AA16384@wanda.mel.dit.CSIRO.AU> Date: Tue, 27 Jul 93 10:20:40 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Bob, I think you are confused about GOSIP and requirements for US Government agencies to use it. GOSIP compliance is only an issue on new systems procurements. It's administered by the ADP organizations in the agencies, which get involved when you want to buy things. There is NO requirement at all to USE any GOSIP product whatsoever, if you read the regs. The requirement is that you purchase stuff that can run GOSIP protocols, when you are trying to acquire functioanlity that the GOSIP spec. addresses. Most of the organizations I know that have bought OSI software for various systems don't bother using it; in fact, many don't even bother installing it. This is because people (even in the Government (!)) are busy, and they won't use something unless it solves a particular problem. Because of this, people in a number of circles have argued for changing the rules, recognizing the realities of how people solve problems out there, and stop wasting money like this. So, Ran isn't required to use GOSIP technology, only buy it, on new system procurements that require functionality that GOSIP addresses, and that you can't get a waiver for. Some agencies have internal requirements to do things in a particular way, but there is no Government policy of having use GOSIP, or OSI in general. :-) Thanks, Milo From owner-big-internet@munnari.oz.au Wed Jul 28 03:33:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17645; Wed, 28 Jul 1993 03:33:42 +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 AA16888; Tue, 27 Jul 1993 13:38:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29580; Mon, 26 Jul 93 23:37:55 -0400 Date: Mon, 26 Jul 93 23:37:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307270337.AA29580@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, brian@dxcern.cern.ch Subject: Re: IPDECIDE BOF minutes Cc: jnc@ginger.lcs.mit.edu A straw poll showed a clear majority view that there should be a decision for ONE solution. Yah, and if you go around and ask people in the U.S. (sorry about the North American-centric political analogy, I know this is an international show :-) how to deal with the federal budget deficit, a clear majority thinks it should be via cutting spending, not more taxes. Only problem is, as soon as you ask about specific programs, all h*&^ breaks loose. I'll bet the same is true here. Sure, we all agree that it'd be horrible to have several, and doing just one sounds fine, as long as it's the scheme *we* like, of course. Pick a protocol with variable length addresses, and the fixed length people will go bonkers. Vice versa, vice versa. Etc, etc, etc. Vendors and operators looked to the IETF to reach a clear decision. The IETF is simply unsuited to making this kind of decision, at least unless we change it so much it won't look a damn thing like the IETF. The IETF has no way to compel people to go along with a decision they don't like. Do the following thought experiment: think of some feature (v.l. addresses, whatever) that you really feel *strongly* about. Now, ask yourself "what will I do if they chose a design that does the opposite of what I think is absolutely critical?" See? The decision was too complicated for a rational market-led solution My first reaction was to say "yah, of course" - I mean, what the heck does the market know? Bunch of marketing droids... On musing about it, though, maybe the market isn't so dumb. I mean, given the choice between X.25, SNA and IP, what did it pick? It's still pretty fashionable in intellectual circles to look down on the market (and, to be fair, in some cases, it *has* make really stupid choices), but history has proven markets to be an astonishingly good judge of value. I realize it *looks* messy, and inefficient, but compared to what? Better a bit of inefficiency in developing several alternatives, than a generation of being crippled because of a too-soon choice of a bad design in the name of "efficiency". Noel From owner-big-internet@munnari.oz.au Wed Jul 28 04:07:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18732; Wed, 28 Jul 1993 04:08:17 +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 AA17433; Tue, 27 Jul 1993 13:52:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29604; Mon, 26 Jul 93 23:51:40 -0400 Date: Mon, 26 Jul 93 23:51:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307270351.AA29604@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ses@tipper.oit.unc.edu Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu When you state that the bandwidth of the average flow will not decrease as the number of hosts increases are you saying that the number of possible switches will increase by a factor of N or that the number of flows will be limited so as to allow each flow that is accepted the same average bandwidth as before? You seem to actually be asking two separate questions, of which only the second is stated concretely: 1 - What reasons do you have for thinking that the bandwidth of the average flow will not decrease? 2 - If this is true, what kind of network infrastructure will we have that will accomodate this growth? To answer the first, I just can't see the opposite (i.e. actual decrease in bandwidth) as being a realistic possibility; any system we build is going to support an increase, or we won't build it. Assuming per flow bandwidth is going to go down is like assuming the average process is going to use less memory; it just isn't going to happen in any reasonable future! As to the second, I suspect that the extra traffic load in the network is going to be handled by creating more links and switches to spread the load across (your first option). The second option (limiting the number of flows) will be used some, but only as a short-term measure. Limiting access will be so painful it will only be done whan absolutely necessary, and temporary reductions in the quality of service will be more likely, but even these will be avoided if at all possible; providing poorer and poorer service is just not a realistic option. Noel From owner-Big-Internet@munnari.oz.au Wed Jul 28 05:51:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21961; Wed, 28 Jul 1993 05:53:15 +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 AA21879; Wed, 28 Jul 1993 05:51:34 +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 AA09498; Tue, 27 Jul 93 12:49:25 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA20722; Tue, 27 Jul 93 15:49:23 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA10819; Tue, 27 Jul 93 15:49:21 EDT Date: Tue, 27 Jul 93 15:49:21 EDT From: solensky@andr.UB.com (Frank T Solensky) Message-Id: <9307271949.AA10819@fenway.andr.UB.com> To: jnc@ginger.lcs.mit.edu Subject: Re: IPDECIDE BOF minutes Cc: big-internet@munnari.oz.au >On musing about it, though, maybe the market isn't so dumb. I mean, given the >choice between X.25, SNA and IP, what did it pick? IPX. -- Frank From owner-Big-Internet@munnari.oz.au Wed Jul 28 06:38:28 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23402; Wed, 28 Jul 1993 06:39:23 +1000 (from owner-Big-Internet) Return-Path: Received: from dnlts0.research.ptt.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23394; Wed, 28 Jul 1993 06:38:28 +1000 (from A.A.Reijnierse@research.ptt.nl) Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H11XMLI50W8Y72SE@research.ptt.nl>; Tue, 27 Jul 1993 22:39:27 +0200 Date: Tue, 27 Jul 1993 22:39:27 +0200 From: Alex Reijnierse Subject: Re: IPDECIDE BOF minutes To: old@sunbim.be Cc: Bob.Hinden@Eng.Sun.COM, big-internet@munnari.oz.au Message-Id: <01H11XMLJ7LU8Y72SE@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: big-internet@munnari.oz.au X-Vms-To: IN%"old@sunbim.be" X-Vms-Cc: IN%"Bob.Hinden@Eng.Sun.COM", IN%"big-internet@munnari.oz.au" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Hi, > > How about the ATN, Air Traffic Network, > And what about the European backbones EuropaNET and Ebone? They all provide native CLNS. Not to mention the native CLNS networks in Norway, Sweden, Finland, Denmark, The Netherlands, France, Spain, Italy, Greece, Switzerland and Portugal. I think i may even have forgotten a few! - Alex From owner-big-internet@munnari.oz.au Wed Jul 28 07:16:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24586; Wed, 28 Jul 1993 07:16:38 +1000 (from owner-big-internet) Return-Path: Received: from munin.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07814; Tue, 27 Jul 1993 23:32:09 +1000 (from crawdad@munin.fnal.gov) Received: from LOCALHOST.fnal.gov by munin.fnal.gov with SMTP id AA04764 (5.65c+/IDA-1.4.4 for big-internet@munnari.oz.au); Tue, 27 Jul 1993 08:31:06 -0500 Message-Id: <199307271331.AA04764@munin.fnal.gov> To: barns@cove.mitre.org Cc: big-Internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of Mon, 26 Jul 93 12:55:05 EDT. <9307261655.AA03907@cove.mitre.org> Date: Tue, 27 Jul 93 08:31:05 -0500 From: Matt Crawford > If you can't get NSAPs out of Bob Cooney, or if the Navy forgot to tell > you that you were supposed to ask Bob Cooney, then the problem is with the > workings of the Navy and not with CLNP. I took his point to be, if they are insufficiently interested in OSI to do a better, quicker job of assigning NSAPs, then OSI isn't important to them and probably will not become important to them soon. Matt Crawford From owner-big-internet@munnari.oz.au Wed Jul 28 07:33:54 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25374; Wed, 28 Jul 1993 07:34:09 +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 AA21487; Tue, 27 Jul 1993 15:44:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29816; Tue, 27 Jul 93 01:43:27 -0400 Date: Tue, 27 Jul 93 01:43:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307270543.AA29816@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Why O(N^2) growth is implausible (note) Cc: jnc@ginger.lcs.mit.edu Here's the promised, more omplete argument (actually two separate arguments, for good measure :-), as to why the number of flows (i.e. active source- destination connection or packet exchange), and hence the amount of any state which is linearly related to that number (i.e. per flow), is likely to be bounded by something much less than O(N^2), where N is the number of hosts (or physical networks) in the Internet. (It doesn't matter which, since if the number of hosts per physical network is approximately constant over time, not a horrible assumption, since most nets are LAN's, the growth rates will be the same modulo a constant.) (I know, I know, this should be a paper/RFC, but putting together all the appropriate citations, acknowledgements, etc, etc bores me silly. Also, thanks ever so much to JMH for going back and forth on this with me.) You can't have O(N^2) flow growth through a switch unless you have either i) O(N^2) total bandwidth growth through the switch, with constant bandwidth per flow over time, or ii) less than O(N^2) total bandwidth growth, with *decreasing* bandwidth per flow over time (i.e. less bandwidth per flow, but more flows). If the bandwidth per flow is the same over time, then the growth of flows has to be linear with the growth of total bandwidth, right? I don't think the second case is plausible, since the second part of that case ('decreasing bandwidth per flow') seems pretty unlikely to me! That leaves us with the first case, if we want to produce O(N^2) growth in flows. (I've left out the case of *greater* than O(N^2) total bandwidth growth, with increasing bandwidth per flow, produced by O(N^2) flow growth, since I don't even see how we can even manage O(N^2) bandwidth growth... if that assumption is wrong, I can come back and revisit this. I actually think increasing per flow bandwidth is likely, which implies we'd have to have greater than O(N^2) total bandwidth growth if we expect to see O(N^2) flow growth.) So, let's look at the likelihood of O(N^2) traffic growth. Here's the key line from a previous message: If nothing else, the traffic load through a switch is limited by the *bandwidth* into the switch, and [link] bandwidths aren't growing at O(N^2). In other words, even though the amount of traffic in *the network as a whole* as a whole may be growing at some vast exponential rate (and it is), that doesn't mean that individual transmission paths are growing in speed at that rate (although bandwiths *are* growing faster than linearly, they are not growing as fast as total traffic.) This, together with the previous lemma (that we need O(N^2) traffic growth if we are to produce O(N^2) flow growth), shows we won't have such O(N^2) flow growth. This is what I meant by the analogy to the road network. A lot of people do an analysis where they assume that in a network there are going to be 'hot spots' where a major (fixed?) fraction of the total endpoints pass through; this would indeed run to substantial growth at those points (but still perhaps less than O(N^2), as we will see somewhat later). However, real-world experience, in roads, telephones, etc, shows that it is quite possible to build large networks where no *individual* switch point shows a traffic growth which is at all related to the growth of the size of the network as a whole, and thus to the toal traffic in it as a whole. It is perfectly possible to build a communication network in which the total traffic grows exponentially, but individual paths do not; use of more and more parallel paths is what accomodates the growth. To put it quantifiably, you can write an equation (*gasp*; quantification in networking design :-), which states that the total bits transferred by a average flow (Df) are the average packet size (S) times the average packet rate (R) times the duration (t) of the average flow. Put in algebraic form we have: Df = S*R*t To get the total user bandwidth (Bu) through the switch, you have to divide Df by the duration of the flow (so t drops out), to give you the bandwidth of the average flow, and multiply that result by the average number of simultaneously active flows through the switch (n). Thus: Bu = S*R*n You haven't lost the consideration of the duration of the average flow in this equation, because that number has to be a factor in the computation of n, right? I mean, longer flow lives would increase n, all else being constant. Now, this has to grow at a rate (G(x)) less than or equal to the rate of increase of the actual bandwidth (Ba) through the switch. So, again in algebraic form: G(Bu) <= G(Ba), or G(S*R*n) <= G(Ba) I don't know of any study of actual figures for G(Ba), but I know some networking history. In the early/mid 70's we saw initial deployment of nets with ~56Kbit/sec, in the late 70's we saw 1/3 Mbit/sec, in the early 80's 10 Mbit/sec, in the late 80's 100 MBit/sec, and in the early 90's 1Gbit/sec. So, over about 20 years, we saw an increase of 2x10^4; hardly O(N^2)! In fact, given the growth of the Internet over that time, from a couple of hundred hosts to many million (i.e. about 5x10^4), I think we can safely say that: G(Bu) <= G(Ba) <= O(N) (approximately :-) Now, if Ba is growing at less than O(N), so does Bu, so the term S*R*n has to be growing at less than O(N). *Iff* n is in fact growing at O(N^2), then the rest of the term (i.e. S*R) has to be decreasing by the reciprocal of the difference between G(Bu) and G(n), so that the whole term S*R*n is growing at only the same rate as Bu (and thus Ba). E.g. if G(Ba) (which is greater than, or equal to G(Bu)) is O(N), then it must be the case that G(S*R) = O(1/N), so that G(Bu) (or G(n)*G(S*R), in other words) is equal to O(N), i.e. O(N^2)*O(1/N) = O(N). Did I miss any steps? If not, I think I've shown that, assuming that the product of packet rates and packet sizes does not decrease (and I think that is a pretty safe bet :-), the growth in number of flows through a switch is bounded by the growth in the bandwidth through the switch. There's another way to look at the problem. Assuming that the number of flows active at any one time from each host is approximately constant over time, the total number of flows in the system as a whole should grow at only O(N). (This is probably not a bad assumption; hosts will probably show *some* flow growth, but it will be minimal, certainly not O(N)!) However, given a growth rate in the total number of flows in the whole network of O(N), how do we get hot spots growing at O(N^2)? Let's consider the worst possible 'hot spot' design, one where *all* the hosts are connected through a *single* switch. Since all flows in the network pass through this switch, and the total number of flows is only growing at O(N), this switch sees O(N) growth. I'm having a bit of a hard time coming up with a network design which has O(N^2) flow growth at some switches. It seems to me that, given an overall growth rate of O(N), you have to have a design which, over time, causes a higher and higher share of the total flows (in fact, a share growing at O(N)) to go through a single switch, and I'm having a bit of a hard time doing that. I dunno, maybe I'm missing something obvious, but I just don't see how you can have O(N^2) flow growth at a single switch. Here are a couple of obvious questions, and replies: Q: If we see flows with longer lifetimes, won't that cause an increase in the number of flows? A: Yes, but the term 'n' above (average number of flows in a switch active at the same time) already includes this. Also, even if this is true, it would have to be growing at an unlikely rate to have an impact on n; O(N^2) is a very high growth rate indeed, and any realistic growth in the lifetime of flows could not make up much of this. Q: It is true that eventually the growth of flows might be limited by the bandwidth, but that isn't the condition we are in now. Isn't there still a lot of room for growth in the number of flows? A: Yes, but a growth rate of O(N^2) will catch up to something growing at only O(N) pretty quickly, and then be limited. Q: As the Internet grows, aren't we likely to see more interleaving of packets from different flows on heavily travelled trunks? A: Yes, but to the degree that you have more flows active at any one time over a given path, it will mean a decrease in the available bandwidth for each flow, and this doesn't seem likely. You just can't increase either a) the number of flows, or b) the lifetime of each flow, without having an negative impact on the traffic rate of each flow, as shown above. More likely is that there *will* be more flows, but there will be a lot more links in the network to handle the increased traffic. Q: Actual observation in the backbone show that it takes a multi-thousand entry cache to handle the set of destionation referred to in a 5 minute period. A: I'm not suggesting that there won't be a lot of state, or that it won't have horrible growth rates, or that it will be easy. All I'm saying is that the O(N^2) observation doesn't seem to make sense; we won't have "hot-spots" that are quite that hot. Q: Even if the number of flows doesn't grow at O(N^2), if we have state per flow in the switches, isn't this going to a be a lot more state than we have now? A: Hmm, again, not too sure, because it's very apples/oranges. We currently store state for all *possible* destinations (modulo a pretty constant factor as mentioned in the intro), whereas we will be storing state for all *active* pairs. Hard to say how those two relate; the second might even grow *slower* than the first. (Note that I'm not making any observation about the differences in current *magnitude*, just speculating about the *rate of change*.) Q: If flows which reserve resources, etc are to be widely used, then it may be necessary to have a lot of per-flow state. But will most of the traffic have that property? A: Well, for the proportion of the traffic which is datagram transactions (such as DNS lookups), I don't propose that we store any state at all. I don't know what percentage of the flows will have resource requirments, but I suspect it won't be large. On the other hand, with flows, you're doing an implementation cost tradeoff over a very wide range of things. For instance, the computation (in a distributed way, for hop-by-hop routing) of policy routing appears to be fairly expensive. Flows get rid of that cost. So, in looking at the costs of flows, you have to also ask yourself "what other costs can I get rid of when I use them". One obvious cost reduction is routing table lookup. Now, most commercial routers have a cache, to speed up routing table lookups. I find it hard to believe that this cache (assuming it's a real one, tuned for real service, and not tuned to produce good numbers on limited benchmarks) is going to be remarkably less expensive, or have a lot less state, than a flow database would. What could produce a significant difference? One possibility I hear a lot is that routing caches are destination only, whereas flows are pairs. However, how likely is it to have two different streams of packets going through a router, and hitting the same routing cache entry? It must be a pretty small percentage of the traffic. The other possibility is that there are a number of long-lived flows, which don't produce a lot of traffic (e.g. TELNET connetions). This has more merit to it, but to the degree that these flows aren't very active, their state can be kept in slow memory, and slow memory is *really cheap* these days. So, overall, my sense is that the engineering is feasible. This, of course, is cold comfort, I know, so we'll have to get busy and prototype it! Well, fire away! Noel From owner-big-internet@munnari.oz.au Wed Jul 28 07:53:30 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26297; Wed, 28 Jul 1993 07:53:41 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307272153.26297@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06794; Tue, 27 Jul 1993 22:56:57 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1627; Tue, 27 Jul 93 08:56:30 EDT Date: Tue, 27 Jul 93 08:55:07 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, swb1@cornell.edu Subject: N^2 growth... Ref: Your note of Mon, 26 Jul 93 18:01:56 -0400 >First, I assume by "Unified" you are refering both to Unified >and SDRP ? Noel, SDRP is a component of Unified. >Second, as I understand it, Unified/SDRP does use flow state >*for some flows*, those which (i) have policy requirements which >are source specific or otherwise not one of those supported >by the "precomputed route" part of Unified and ii) are long >enough in duration to make it economical to use the recently >announced "flow setup" mechanism of SDRP. Is this correct ? That is certainly correct. >can you explain to me your model for the share of the end-end >traffic streams in the system will be using this flow setup >mechanism ? To answer this question observe that: (a) Unified *explicitly* claims that "supporting highly specialized routes for all source-destination pairs in an internet, or even anything close to that number is not feasible in any architecture that we can foresee" (see SIGCOMM 1992 paper) (b) SDRP is intended to support specialized routes (c) only some of specialized routes will use flow setup mechanism Flow setup is just *one way* of providing certain packets with a particular treatment by routers. There are other mechanisms, like QoS that can provide such an effect as well. Unified can support widely used QoSs, thus allowing certain packets to get a particular treatment (as determined by the semantics of that QoS), while avoiding the overhead associated with installing src/dst sensitive state on routers (flow setup). Yakov From owner-big-internet@munnari.oz.au Wed Jul 28 08:16:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27043; Wed, 28 Jul 1993 08:16:28 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307272216.27043@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10852; Wed, 28 Jul 1993 00:31:25 +1000 (from @bronze.bbn.com:jcurran@nic.near.net) Received: from BRONZE.BBN.COM by nic.near.net id aa07569; 27 Jul 93 10:31 EDT To: Ross Callon Cc: atkinson@itd.nrl.navy.mil, jnc@ginger.lcs.mit.edu, big-Internet@munnari.oz.au Subject: Re: addressing... In-Reply-To: Your message of Tue, 27 Jul 1993 10:24:31 -0400. <9307271424.AA19941@cabernet.wellfleet> Date: Tue, 27 Jul 1993 10:28:34 -0400 From: John Curran -------- ] From: Ross Callon ] Subject: Re: addressing... ] Date: Tue, 27 Jul 93 10:24:31 EDT ] ] Someone is not fully understanding the proposals which involve ] embedded addresses. I will try to write these up in detail. Some of the proposals have been written up; I believe that the ISIS working group just put "Routing over Nonbroadcast Multiaccess Links" as an ID draft-ietf-isis-nbma-00.txt. Are there working papers for the other proposals? /John From owner-big-internet@munnari.oz.au Wed Jul 28 08:36:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27665; Wed, 28 Jul 1993 08:36:57 +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 AA10523; Wed, 28 Jul 1993 00:23:55 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22446; Tue, 27 Jul 93 10:17:52 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA19941; Tue, 27 Jul 93 10:24:31 EDT Date: Tue, 27 Jul 93 10:24:31 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307271424.AA19941@cabernet.wellfleet> To: atkinson@itd.nrl.navy.mil, jcurran@nic.near.net, jnc@ginger.lcs.mit.edu Subject: Re: addressing... Cc: big-Internet@munnari.oz.au For one example, a single host might have multiple interfaces and one still needs to be able to connect to it even though one interface is down. Interface-independent addresses facilitate this, but are incompatible with embedding other addresses into IP or IPng addresses. If the interfaces are to different nets (which is the best way to get reliability), then as long as the internet addresses contain any information about where those interfaces are (i.e. if you can route on them directly), then you can't have one address to name all the interfaces. If you really want a name which stays the same, no matter which interface you use (or where the host has moved), use an EID. Someone is not fully understanding the proposals which involve embedded addresses. I will try to write these up in detail. I am not aware of any proposals which would require hosts with multiple interfaces to embed different addresses in multiple IP-level addresses. I do not want or desire to mix or mingle E.164 addresses with my IPng address space. I believe that "divide and conquer" is a better approach to routing problems than "mix and mingle". ... E.164 addresses are also problematic and should not be embedded in IP or IPng addresses. Large blocks of them are not at all heirarchical ... Even in local conventional numbers, not all addresses are heirarchical. Dealing with very large public subnets with millions or tens of millions of customers is a real problem. Doing this via buffering the packets while doing a distributed directory lookup is a technical disaster for very high speed routers (the implicit delay will do horrible things for the resources needed in the routers). Thus we need some other way to handle this problem. I think that it is a mistake to discard one possible solution which will actually work well for the one most common case in very large networks (and which is actually working well today in a few places), unless and until we have figured out some other feasible way to solve this problem. Let's look at the problem and the complete list of possible solutions before we start insulting one particular solution. Ross From owner-big-internet@munnari.oz.au Wed Jul 28 08:54:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28209; Wed, 28 Jul 1993 08:54:47 +1000 (from owner-big-internet) Return-Path: Received: from moink.NMSU.Edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11920; Wed, 28 Jul 1993 00:57:47 +1000 (from amolitor@moink.nmsu.edu) Received: by moink.nmsu.edu (5.61/eels); id AA08243; Tue, 27 Jul 93 08:54:30 -0600 Date: Tue, 27 Jul 93 08:54:30 -0600 From: amolitor@moink.nmsu.edu (Andrew Molitor) Message-Id: <9307271454.AA08243@moink.nmsu.edu> To: big-internet@munnari.oz.au Subject: Variable length addresses and security - One thing that leaps immediately to mind is the ability to do quick and efficient filtering. With IP, bitwise mask&match against the header will get you a surprising amount of flexibility in selecting classes of packets. With variable length addresses, it's harder to get the same flexibility. More generally, variable length addresses are less efficient, computationally. Does anyone have any figures to show if this is or is not significant? Andrew From owner-big-internet@munnari.oz.au Wed Jul 28 09:19:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28968; Wed, 28 Jul 1993 09:19:29 +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 AA14379; Wed, 28 Jul 1993 02:14:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04251; Tue, 27 Jul 93 12:13:57 -0400 Date: Tue, 27 Jul 93 12:13:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307271613.AA04251@ginger.lcs.mit.edu> To: braden@isi.edu, jnc@ginger.lcs.mit.edu Subject: Re: N^2 growth... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Van has been telling us for the past 2-3 years that ... flow aggregation in the networks backbones is a necessity for scaling. ... I have not seen the details worked out yet, but they probably will be. Hmm, I'd love to hear what Van's model is for the growth in the number of active flows through the switches. I do recall (as you mention) that he thinks we will need aggregation, but I don't know exactly *what* his model for flow growth is, that leads to this conclusion. Do you know what his model is? The more I think about this (and I've been putting a lot of cycles into it recently), the more I think this O(N^2) model (where N is the number of hosts or networks in the system) just can't be right; this is not to say, of course, that Van's model *is* O(N^2). Noel From owner-big-internet@munnari.oz.au Wed Jul 28 09:47:35 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29909; Wed, 28 Jul 1993 09:47:53 +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 AA14872; Wed, 28 Jul 1993 02:22:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04300; Tue, 27 Jul 93 12:22:43 -0400 Date: Tue, 27 Jul 93 12:22:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307271622.AA04300@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, yakov@watson.ibm.com Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu > can you explain to me your model for the share of the end-end > traffic streams in the system will be using this flow setup > mechanism ? ... (c) only some of specialized routes will use flow setup mechanism Flow setup is just *one way* of providing certain packets with a particular treatment by routers. ... Unified can support widely used QoSs, thus allowing certain packets to get a particular treatment ... while avoiding the overhead associated with installing src/dst sensitive state on routers (flow setup). Yes, I understand that, you have a variety of alternative mechanisms in there to avoid the necessity of flow setup (and one of them I 'borrowed' to use in Nimrod, which is the highest praise I have to offer :-), but that wasn't what I was after. What I'm looking for is your guess as to what share of future 'potential flows' will actually use the flow setup mechanism. Do you think the average host will have a fairly fixed fraction of its outbound connections use flow setup, or will it grow slightly over time, or decline slightly, or what? Noel From owner-big-internet@munnari.oz.au Wed Jul 28 10:21:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01041; Wed, 28 Jul 1993 10:22:35 +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 AA19068; Wed, 28 Jul 1993 04:18:19 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA21040 (5.65/1.23); Tue, 27 Jul 93 14:17:21 -0400 Date: Tue, 27 Jul 93 14:17:21 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9307271817.AA21040@sadye.emba.uvm.edu> To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: big-internet@munnari.oz.au Subject: N^2 growth... (NOT!) In-Reply-To: <9307271457.AA20006@er.doe.gov> References: <9307271457.AA20006@er.doe.gov> < It seems that this argument boils down to will the network die because > the number of flows overwhelms the ability of the router to keep track of > them (router memory) or will the network die first because the bandwidth > per flow through the router goes to zero. It seems to me that the latter is easier to prevent than the former. (Assumptions: most traffic either has bandwidth reserved, or is VJCC-enhanced TCP. Reserved bandwidth cannot get overcommitted, so users will have their setup requests rejected and complain to management. TCP will back down in the face of congestion, so users will have their file transfers take forever and complain to management. End result is that management gets sick of the complaints and adds bandwidth or router thrust, whichever is lacking.) > For a given topology this is a comparison of your guess at the rate of inc- > rease of router memory, the rate of increase of bandwidth through a > router, and the # of flows needing bandwidth. Well, consider: if we don't allow reserved bandwidth to be overcommitted (reservation wouldn't be terribly useful if it were), then we know that the amount of bandwidth taken up by flows with reservations will be strictly linear with the growth in total bandwidth. This leaves us with the remaining traffic, mostly TCP. Congestion control assures (we hope) that any remaining bandwidth will be divided among the competing sources in a manner which ensures that all clients will see their transfers slowly grind to a halt. So, I agree with Noel that flow state growth seems to be limited by growth in bandwidth. I feel that bandwidtth per flow would show the 1/N pattern of decline, if left to its own devices. But because the users are ultimately people, this will not be allowed to happen, unless we reach some fundamental limit to the available bandwidth. Of course, we hate to base our network planning on the vagaries of human nature... In many ways, this is similar to the argument that some people make about conferencing without resource reservation; if too many people start doing it, then eventually some group of participants will find their performance unacceptably degraded and stop. -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 Wed Jul 28 19:27:43 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21341; Wed, 28 Jul 1993 19:28:01 +1000 (from owner-Big-Internet) Return-Path: Received: from dnlts0.research.ptt.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21329; Wed, 28 Jul 1993 19:27:43 +1000 (from A.A.Reijnierse@research.ptt.nl) Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H12OHDZGHC8Y71T1@research.ptt.nl>; Wed, 28 Jul 1993 11:27:06 +0200 Date: Wed, 28 Jul 1993 11:27:06 +0200 From: Alex Reijnierse Subject: Re: IPDECIDE BOF minutes To: Christian.Huitema@sophia.inria.fr Cc: big-internet@munnari.oz.au Message-Id: <01H12OHE09EQ8Y71T1@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: big-internet@munnari.oz.au X-Vms-To: IN%"Christian.Huitema@sophia.inria.fr" X-Vms-Cc: IN%"big-internet@munnari.oz.au" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Hi, > > I believed up to now that Europanet was native X.25 with support for IP over > X.25, and I would certainly not say that Ebone is running a large native CLNP > network. EuropaNET has been running native CLNS over X.25 and LAP-B for a couple of months now. I agree that Ebone is in a startup phase. > couple similarly useful things, but speaking of a widely deployed service is > somewhat of an exageration. Similarly, you mention a "native CLNS network in > France" -- that is new to me. The French research network RENATER supports > an X.25 and an IP service; CLNP experiments, when needed, are run on top of IP. I think you are right about this. BTW, how large are the SIP, PIP or TP/IX networks in the world? Can you give me some figures about this? i.e. number of (real) routers, number of hosts, number of networks that support native SIP, PIP or TP/IX etc.. - Alex From owner-Big-Internet@munnari.oz.au Wed Jul 28 19:35:12 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21597; Wed, 28 Jul 1993 19:35:32 +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 AA21585; Wed, 28 Jul 1993 19:35:12 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA23243; Wed, 28 Jul 1993 11:36:08 +0200 Message-Id: <199307280936.AA23243@mitsou.inria.fr> To: Alex Reijnierse Cc: big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Wed, 28 Jul 93 11:27:06 +0200." <01H12OHE09EQ8Y71T1@research.ptt.nl> Date: Wed, 28 Jul 93 11:36:07 +0200 From: Christian Huitema => => BTW, how large are the SIP, PIP or TP/IX networks in the world? Can you => give me some figures about this? i.e. number of (real) routers, number => of hosts, number of networks that support native SIP, PIP or TP/IX etc.. => Neither of these claim an installed base. Their proponents believe that the Internet will be better of with a clean new design than by trying to revive something the market failed to pick for nearly 10 years. Christian Huitema From owner-big-internet@munnari.oz.au Wed Jul 28 21:16:18 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25510; Wed, 28 Jul 1993 21:16:35 +1000 (from owner-big-internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01689; Wed, 28 Jul 1993 10:47:16 +1000 (from craig@aland.bbn.com) Received: from uu2.psi.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00579 Wed, 28 Jul 1993 10:41:58 +1000 (from craig@aland.bbn.com) Received: from port13.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA22928 for big-internet@munnari.oz.au; Tue, 27 Jul 93 20:40:00 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA07151; Tue, 27 Jul 93 17:38:36 PDT Message-Id: <9307280038.AA07151@aland.bbn.com> To: Andrew Molitor Cc: big-internet@munnari.oz.au Subject: re: Variable length addresses and security - From: Craig Partridge Date: Tue, 27 Jul 93 17:38:36 -0700 Sender: craig@aland.bbn.com Andrew: I've tried to work out the computational cost of variable addresses and it is damnably hard. One has to work it out on a per-format basis, but here's the gist of my thoughts. Assume you've got a processor making the forwarding decisions. Your key problems are: 1. getting the IPtng header to the processor so you can update the header and do the routing lookup. 2. updating the header 3. doing the routing lookup 4. writing the updated header out and getting the packet sent. OK, now *variable* addresses complicate 1 and 4 only slightly, since today's faster processors typically move data in cache-line sized chunks. I.e., read 1 bit, read a whole cache line. So provided the variable addresses don't cause you cross cache line boundaries, you're OK. (*Big* addresses are a topic for another time). Variable addresses may complicate 2 iff they make it hard to find fields that have to be updated. I.e. if the a header has fields to be updated at fixed offsets followed by two variable addresses, then step 2 costs no more with variable or fixed-length addresses. Step 3 is where one fusses. In most routers, 95+% of all route lookups are actually served by hashing the address (or similar operation) to find a cached route, NOT a full routing lookup. So the question is whether the variable address is structured in such a way that computing a good hash is much harder than compute the hash on a fixed length address. IP is a snap, it is one instruction or two instructions on one word on almost every processor. Ditto for 64-bit addresses. Trekking through a variable number of bytes will take longer, but how much longer? We're in a world where tens of instructions is a lot. Van Jacobson showed code at SIGCOMM '90 that could forward an IP datagram in << 100 instructions, so an extra 10 instructions would be a 10% performance reduction (probably not a big deal) and an extra 50 instructions would be a 50% performance reduction (a big deal). Expressing this point another way, the only way to resolve the cost of variable length addresses is to propose a format, and then post a lean and mean hash function that shows good hash properties and doesn't require many instructions. If one can do that, we can stop fussing about variable length addresses. Craig From owner-big-internet@munnari.oz.au Wed Jul 28 21:38:24 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26177; Wed, 28 Jul 1993 21:38:29 +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 AA00167; Wed, 28 Jul 1993 09:55:20 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA19348 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Tue, 27 Jul 1993 16:54:48 -0700 Date: Tue, 27 Jul 1993 16:54:48 -0700 From: Tony Li Message-Id: <199307272354.AA19348@lager.cisco.com> To: amolitor@moink.nmsu.edu (Andrew Molitor) Cc: big-internet@munnari.oz.au Subject: Variable length addresses and security - One thing that leaps immediately to mind is the ability to do quick and efficient filtering. With IP, bitwise mask&match against the header will get you a surprising amount of flexibility in selecting classes of packets. With variable length addresses, it's harder to get the same flexibility. There is no reason that you can't do bitwise mask and match operations on variable length addresses. More generally, variable length addresses are less efficient, computationally. Does anyone have any figures to show if this is or is not significant? IMHO, based on data that I can't show you, as long as you have a hierarchical addressing plan, the difference is almost in the noise. Tony From owner-big-internet@munnari.oz.au Wed Jul 28 21:49:26 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26523; Wed, 28 Jul 1993 21:49:49 +1000 (from owner-big-internet) Return-Path: Received: from POSTOFFICE.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07279; Wed, 28 Jul 1993 13:42:33 +1000 (from swb1@cornell.edu) Received: from [132.236.236.51] (CU-DIALUP-0209.CIT.CORNELL.EDU) by postoffice.mail.cornell.edu with SMTP id AA20243 (5.65c8/IDA-1.4.4 for big-internet@munnari.oz.au); Tue, 27 Jul 1993 23:15:39 -0400 Message-Id: <199307280315.AA20243@postoffice.mail.cornell.edu> Date: Tue, 27 Jul 1993 23:16:18 -0400 To: rcallon@wellfleet.com (Ross Callon), big-internet@munnari.oz.au From: Scott Brim X-Sender: swb1@postoffice.mail.cornell.edu Subject: Re: N^2 growth... > There isn't any multicast routing scheme which, for the worst-case router, > scales better than O(the number of groups passing through the router) -- > the N^2 problem again. > >What???? Never mind whether this is n-squared or not. Multicast >is not going to work in a very large Internet unless it scales >better than O(the number of groups passing through the router). I phrased that wrong. It's O(the number of groups whose distribution trees pass through the router), even in CBT. Since I firmly believe there will be "hot spots" in the Internet -- if only because the Internet's manageability seems to be proportional to how controlled interconnections are -- for the worst case router this is still O(the number of active wide-area groups). On the other hand I'm not at all convinced that that means multicast routing will never work, especially if what Noel says is true. Scott From owner-Big-Internet@munnari.oz.au Wed Jul 28 22:03:34 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26878; Wed, 28 Jul 1993 22:04:24 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26870; Wed, 28 Jul 1993 22:03:34 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA04380; Wed, 28 Jul 93 08:03:26 EDT Date: Wed, 28 Jul 93 08:03:26 EDT From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9307281203.AA04380@itd.nrl.navy.mil> To: big-Internet@munnari.oz.au Subject: Re: PIP and SIP installed base The other item to note is that both PIP and SIP have been demonstrated running over the current IPv4 infrastructure with no changes needed, so deployed base of routers is a non-issue. TUBA does not even claim to have the smooth transition property that both SIP and PIP claim to have. As near as I can tell, both PIP and SIP are at least as fully baked and tested as the TUBA proposals are. SIP, in particular, has a fairly large number of independent implementations that interoperate. I have not been keeping much track of the TP/IX proposal. I'm responding to traffic on big-Internet, but I'm not at all sure that this thread belongs here. Perhaps followups belong on the main ietf list since the reason we are dicussing this is mainly the TUBA Last Call ?? Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Wed Jul 28 22:15:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27232; Wed, 28 Jul 1993 22:16:22 +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 AA08362; Wed, 28 Jul 1993 14:10:55 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA23763 (5.65c/IDA-1.4.4nsd for ); Tue, 27 Jul 1993 21:10:30 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA08070 (5.65c/IDA-1.4.4-910725 for ); Tue, 27 Jul 1993 21:10:29 -0700 Message-Id: <199307280410.AA08070@remmel.NSD.3Com.COM> To: big-internet@munnari.oz.au Subject: Re: N^2 growth... (NOT!) In-Reply-To: Your message of "Tue, 27 Jul 93 14:17:21 EDT." <9307271817.AA21040@sadye.emba.uvm.edu> Date: Tue, 27 Jul 93 21:10:28 -0700 From: tracym@NSD.3Com.COM Why do we think that the data/packet switching growth problem is any different than the telco's circuit switching problems, which seem to be reasonably under control? (Yes, major holidays and major failures occasionally result in denial of service). H, the number of networked hosts, is probably O(P, number of phones). The telcos provide t**2 services in local areas, where t is some fraction of the local population, and something else for the wide area. Just what they do for the wide area is the interesting question. I'd guess that it'll work for us too. Tracy From owner-Big-Internet@munnari.oz.au Wed Jul 28 22:56:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28406; Wed, 28 Jul 1993 22:57:16 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA28289; Wed, 28 Jul 1993 22:56:37 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08188; Wed, 28 Jul 93 08:38:51 -0400 Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10718; Wed, 28 Jul 1993 14:35:35 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA09928; Wed, 28 Jul 1993 14:35:29 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307281235.AA09928@dxcern.cern.ch> Subject: Installed bases [was: Re: IPDECIDE BOF minutes] To: Christian.Huitema@sophia.inria.fr (Christian Huitema) Date: Wed, 28 Jul 1993 14:35:28 +0200 (MET DST) Cc: A.A.Reijnierse@research.ptt.nl, big-internet@munnari.oz.au In-Reply-To: <199307280936.AA23243@mitsou.inria.fr> from "Christian Huitema" at Jul 28, 93 11:36:07 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1456 >--------- Text sent by Christian Huitema follows: > > => > => BTW, how large are the SIP, PIP or TP/IX networks in the world? Can you > => give me some figures about this? i.e. number of (real) routers, number > => of hosts, number of networks that support native SIP, PIP or TP/IX etc.. > => > > Neither of these claim an installed base. Their proponents believe that the > Internet will be better of with a clean new design than by trying to revive > something the market failed to pick for nearly 10 years. > Let's talk about that. I read the CLNP DIS 8473 document in 1984 and decided it was trivial to implement. In fact it took me about 2 weeks to get correct (but sloooow) running code, with some shortcuts of course. I still have the final listing dated October 11, 1984. That code was used operationally for quite a while... until IP code arrived for the Norsk-Data machines concerned. That crude version was used because an applications programmer just happened to need a UDP-like service and my toy CLNP package gave him that. CLNP has been dead in the water for 9 years because it has been largely application-free. A plausible conclusion from this is that TUBA should have been designed in 1985. 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 | | PIP, SIP, TP/IX, Nimrod, TUBA or anything. Really. | From owner-big-internet@munnari.oz.au Wed Jul 28 23:11:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28814; Wed, 28 Jul 1993 23:12:18 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13109; Wed, 28 Jul 1993 16:29:55 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA08234; Wed, 28 Jul 1993 08:29:37 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA13429; Wed, 28 Jul 1993 08:29:31 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307280629.AA13429@dxcern.cern.ch> Subject: Re: IPDECIDE BOF minutes To: solensky@andr.ub.com (Frank T Solensky) Date: Wed, 28 Jul 1993 08:29:30 +0200 (MET DST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: <9307271949.AA10819@fenway.andr.UB.com> from "Frank T Solensky" at Jul 27, 93 03:49:21 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 584 >--------- Text sent by Frank T Solensky follows: > > >On musing about it, though, maybe the market isn't so dumb. I mean, given the > >choice between X.25, SNA and IP, what did it pick? > > IPX. -- Frank > In other words it picked APPLICATIONS. And IP won out over X.25 and SNA (and XNS :-) in the scientific/technical market because of APPLICATIONS. In the business market SNA didn't do too bad, because of APPLICATIONS. And DECnet was very popular in several market sectors because of APPLICATIONS. The market, actually, doesn't care about network layer protocols. Brian From owner-Big-Internet@munnari.oz.au Thu Jul 29 00:12:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01268; Thu, 29 Jul 1993 00:13:07 +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 AA01265; Thu, 29 Jul 1993 00:12:51 +1000 (from kasten@ftp.com) Received: by ftp.com id AA02180; Wed, 28 Jul 93 10:12:58 -0400 Date: Wed, 28 Jul 93 10:12:58 -0400 Message-Id: <9307281412.AA02180@ftp.com> To: big-internet@munnari.oz.au Subject: Re: Installed bases [was: Re: IPDECIDE BOF minutes] From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: Christian.Huitema@sophia.inria.fr, A.A.Reijnierse@research.ptt.nl I would like to point out that if we start using claimed installed base as the justification for selecting an IPng then A) IPv4 has more than TUBA, PIP, SIP, and TPIX, and B) Novell IPX has a larger installed base than IPv4. The conclusion is intuitively obvious and left as an exercise to the interested reader. > => BTW, how large are the SIP, PIP or TP/IX networks in the world? Can you > => give me some figures about this? i.e. number of (real) routers, number > => of hosts, number of networks that support native SIP, PIP or TP/IX etc.. > > Neither of these claim an installed base. Their proponents believe that the > Internet will be better of with a clean new design than by trying to revive > something the market failed to pick for nearly 10 years. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Thu Jul 29 01:08:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02868; Thu, 29 Jul 1993 01:09: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 AA02865; Thu, 29 Jul 1993 01:08:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09369; Wed, 28 Jul 93 11:08:25 -0400 Date: Wed, 28 Jul 93 11:08:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307281508.AA09369@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, swb1@cornell.edu Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu Since I firmly believe there will be "hot spots" in the Internet -- if only because the Internet's manageability seems to be proportional to how controlled interconnections are -- for the worst case router this is still O(the number of active wide-area groups). Scott, the only way to have a hot-spot *that bad* would be to have a single switch through which all the parts of the Internet are connected. This is not only an infeasible thing technologically, it's horrendously bad design; it's a massive single point of failure. One of the whole points of the Internet, way back when in the 70's, was to design a tremendously *robust* network. (Course, the application back then was to keep running while people dropped pieces of the sun on it, and burned large holes in it, a future which now thankfully seems less likely! Still, it's a good principle.) The datanet may not yet be as important to the correct functioning of everyday life as, say, electricity, but it will get there. To take a design that has the *potential* for tremendous robustness, via replication and load-sharing (so that a dropout will cause less of an impact; losing an element carrying 1/100th of your load is going to cause less havoc than one carrying 1/2), and deploy it in such a way that it loses that property would be extremely bad engineering. It's also probably not cost effective. Current processing thinking is that the way to get massive capacity is to use many cheaper elements in parallel, rather than a few very expensive ones. This plays to the strengths of the IC industry, where economies of scale in simple elements come into play. Sure, you've got a point about controlled interconnection being easier to manage, but even keeping that it mind I can still design systems with a lot of parallelism in them; it just means it has to be controlled parallism. Noel From owner-Big-Internet@munnari.oz.au Thu Jul 29 03:40:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06540; Thu, 29 Jul 1993 03:41:10 +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 AA06523; Thu, 29 Jul 1993 03:40:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10089; Wed, 28 Jul 93 13:40:13 -0400 Date: Wed, 28 Jul 93 13:40:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307281740.AA10089@ginger.lcs.mit.edu> To: atkinson@itd.nrl.navy.mil, big-Internet@munnari.oz.au Subject: Re: PIP and SIP installed base Cc: jnc@ginger.lcs.mit.edu The other item to note is that both PIP and SIP have been demonstrated running over the current IPv4 infrastructure with no changes needed, so deployed base of routers is a non-issue. Yes, but this is achieved by wrapping them in IPv4 packets. So? We do the same thing with X.25 packets, so X.25 exhibits this property, but that doesn't make X.25 a good choice for IPng! (Parenthetically, I've always found encapsulation a process not without its innumerable fiddling problems, and one I personally abhor since the fiddling eventually gets so deep that you decide that you'd rather be dead than encapsulate. E.g. you send out a maximum size X-gram, and you wrap it in Y, only now it's too big, so you have to fragment and reassemble, etc, etc, etc.) Noel From owner-Big-Internet@munnari.oz.au Thu Jul 29 06:42:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13215; Thu, 29 Jul 1993 06:42:42 +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 AA13211; Thu, 29 Jul 1993 06:42:27 +1000 (from stev@ftp.com) Received: from stev.d-cell.ftp.com by ftp.com via PCMAIL with DMSP id AA18146; Wed, 28 Jul 93 16:42:09 -0400 Date: Wed, 28 Jul 93 16:42:09 -0400 Message-Id: <9307282042.AA18146@ftp.com> To: bill.simpson@um.cc.umich.edu Subject: From: stev@ftp.com (stev knowles) Cc: Joel Halpern rolc@network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us, iesg@cnri.reston.va.us Sender: stev@ftp.com Repository: babyoil.ftp.com Originating-Client: d-cell.ftp.com >I oppose the formation of a new working group for this area, unless it >can be shown that existing groups are incapable of handling this task. >This was the purpose of the IPLPDN WG. IPLPDN folded after amsterdam. it is not the job of a WG in the internet area to be doing work that is clearly in the routing domain. we have a very nice man (bob, hold your hand up) who deals with the routing end of the world. >Extract from IPLPDN charter: this will not be the first time that a group has selectively implemented its charter. >We never did see any *routing* work out of them. Since you were a >prominent member of that group, I don't see how making a new working >group will improve the performance. bill, even though i would not consider my interactions with joel to be as great as those i have had with others, i have found him a very strong and vocal proponent of what he feels is correct, while maintaining the dignity and respect of both himself and the others around him in a technical discussion. unfortunately, i have not found this trait in your interactions with other members of WGs i have observed you in. i woudl imagine that joel would make a wonderful chair of this working group, and i have encouraged bob, remember bob?, to let joel run this new working group. >I suspect that we will see more turf wars as the new group conflicts >with the efforts of existing WGs, and with the IPng groups, which are >also working on the broader routing questions. i have already suggested to the SIP group that any routing work it does beyond just porting existing routing protocols, should be carried out where the routing area (remember bob?) can be sure to provide them with the guideance that they surely will need, since routing is canonically a messy subject. (least, i always feel messy when i leave a routing discussion.) i woudl also imagine that most turf wars about routing will be lost by the internet area, if it finds itself one of the sides. so, this shoudl not be a concern. >I suggest that we disband the IPLPDN group, and focus on building the >desired routing features into the various IPng proposals. while i appreciate your feedback, and i have not discussed my position with my partner, i will strongly resist putting routing work in internet area WGs, other than that i outlined above (minimal changes necessary for porting to the new architecture.) i will keep your comments in mind, along with any other comments this issue generates, and will be sure to let you know if my position is changed by the weight of public opinion. as it stands now, the process for creating this WG seems to be running correctly, since it allowed you to register your complaint before the process had gone too far. if there are a substantial number of complaints, i am sure bob, dave (whom i have only mentioned obliquely as "my partner") and myself will have a discussion about the viability of our current course of action. the final resolution will, i am sure, be announced where ever you read the first announcement. stev knowles still one of the internet area directors From owner-big-internet@munnari.oz.au Thu Jul 29 07:35:52 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15452; Thu, 29 Jul 1993 07:36:16 +1000 (from owner-big-internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04907; Wed, 28 Jul 1993 12:35:18 +1000 (from hgs@research.att.com) Received: from research.att.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01625 Wed, 28 Jul 1993 11:08:56 +1000 (from hgs@research.att.com) Message-Id: <9307280108.1625@mulga.cs.mu.OZ.AU> Received: by inet; Tue Jul 27 21:06 EDT 1993 Date: Tue, 27 Jul 93 21:06:21 EDT From: hgs@research.att.com (Henning G. Schulzrinne) To: big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes It seems likely that all proposals can satisfy the basic IPng criteria (or rather, that it cannot be shown that one or the other does NOT satisfy one or the other criteria). Anything related to scaling will remain conjecture until it is too late. On the other hand, I'm surprised that (with a few exceptions) the easy engineering questions haven't been addressed. Some sample questions that would allow a better judgement about the tradeoffs between functionality and costs: 1) What is the IP-level byte overhead for 'common' packets? Will it be any larger for multimedia packets (where overall packet lengths may have to be small)? 2) What is the relative cost in terms of code size and execution speed of - fixed, small addresses with word alignment - variable-length addresses without word alignment - variable-length addresses with word alignment (Note that the relative costs may be different in a multiprotocol hardware-assisted router compared to a workstation.) 3) What is the average forwarding latency in a RISC-based processor (based on the current implementations)? It may turn out all proposal entail roughly similar costs or that the IP-level costs are insignificant in the global context (or will be by the time of widespread deployment), but then we can at least avoid the vague arguments about some feature being too 'expensive' or 'not costing anything'. After all, the analysis of actual TCP protocol processing costs did much to stem the flood of lightweight transport protocols. Henning Schulzrinne From owner-big-internet@munnari.oz.au Thu Jul 29 08:22:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17357; Thu, 29 Jul 1993 08:22:17 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307282222.17357@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16793; Wed, 28 Jul 1993 17:42:32 +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 ; Wed, 28 Jul 1993 08:42:06 +0100 To: rcallon@wellfleet.com (Ross Callon) Cc: big-internet@munnari.oz.au Subject: Re: N^2 growth... multicast... In-Reply-To: Your message of "Tue, 27 Jul 93 12:06:59 EDT." <9307271606.AA20012@cabernet.wellfleet> Date: Wed, 28 Jul 93 08:42:00 +0100 From: Jon Crowcroft >understanding that the core based tree approach allows a >multicast group to pass through a router without that router >being aware of the multicast-ness of the group. Thus (again, >based on my understanding of core based tree multicast) this >will require only those routers which actually "split" a packet >(get one packet in, and need to send it out multiple ways) to >be aware that it is multicast. it aint quite that simple...but its true CBT can scale very well in some respects with number of groups... >We should ask Paul Francis whether this is true of the core >based tree multicast. If not, then we will need yet another >form of multicast. there is a lot of debate on multicast scaling with respect to number of groups, size of groups and dispersion of groups ("sparse") people should join the IDMR list if they want the lively action on this (subsriptions to idrm-request@cs.ucl.ac.uk) it is not something we have completely resolved (i.e. RESEARCH needs to be done before we understand it!). deborah estrin has people simulating the proposed algorithms (DVMRP, MOSPF, CBT, ESL and SRPM) scott has some very interesting thoughts about group address/route aggregation going on that cross all the schemes to some extent - while topologies dependnet on minmimising link re-usage versus minimising average dfelay to members (dependnant on how many members or non-members are senders too) are being discussed... contributory discussion on idrm is welcome...but read the archive and papers/drafts first please as it is some way down the road... cheers jon From owner-big-internet@munnari.oz.au Thu Jul 29 08:47:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18335; Thu, 29 Jul 1993 08:48:08 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307282248.18335@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17533; Wed, 28 Jul 1993 17:55:18 +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 ; Wed, 28 Jul 1993 08:50:48 +0100 To: big-internet@munnari.oz.au, brian@dxcern.cern.ch Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Mon, 26 Jul 93 23:37:55 EDT." <9307270337.AA29580@ginger.lcs.mit.edu> Date: Wed, 28 Jul 93 08:50:44 +0100 From: Jon Crowcroft > A straw poll showed a clear majority view that there should be a decision > for ONE solution. hmmm...sounds like a touch of jitters... scientifically: given experimental results we propose many solutions, and test them, and would like to end up choosing single theory that fits them e results best (and simplest) but given some proposed protocols, algorithms and data structures to solve a problem, we CAN tolerate several resulkts until we have tested them and chosen the one that best (and simplest) measures up. politically/logistically: the decision is NOT a binary choice between TUBA and SIP we already have CLNP and IP we dont have TUBA products but it isn't to ohard to see how they might come along. it is a decision whether we think a) TCP/UDP can be slid on top of CLNP logisitcally/economically. versus b) SIP can be slid under TCP/UDP logistically/econmically plus some questions of i) longer term problems (e.g. very very fast routing/forwarding, flow reservations and multicast) ii) ownership - the ietf could and would "won" sip lock stock and barrel - its history of ability to _change_ a protocool and evolve it to meet new problems is rather better than other protocol "owners" - In this respect, in particular, the existence of CLNP products mitigates AGAINST itm not for it, since that implies all the logisitic inertia in trying to field flow reservation and multicast ,that we can engineer in day one in SIP.... so i vote for two solutions. jon From owner-big-internet@munnari.oz.au Thu Jul 29 09:57:03 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20947; Thu, 29 Jul 1993 09:57:23 +1000 (from owner-big-internet) Return-Path: Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19038; Wed, 28 Jul 1993 18:31:35 +1000 (from brian@dxcern.cern.ch) Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA10845; Wed, 28 Jul 1993 10:31:25 +0200 Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) id AA10866; Wed, 28 Jul 1993 10:31:23 +0200 From: brian@dxcern.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9307280831.AA10866@dxcern.cern.ch> Subject: Re: IPDECIDE BOF minutes To: big-internet@munnari.oz.au Date: Wed, 28 Jul 1993 10:31:22 +0200 (MET DST) In-Reply-To: <9307280756.AA02302@dxmint.cern.ch> from "Jon Crowcroft" at Jul 28, 93 08:50:44 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 846 >--------- Text sent by Jon Crowcroft follows: > > > A straw poll showed a clear majority view that there should be a decision > > for ONE solution. > > hmmm...sounds like a touch of jitters... > An argument made in the BOF (by Dave Sincoskie I think) was that the "market" in any case has to choose between staying with IPv4 and switching to IPng; if the IETF offers more than one IPng the "market" will be confused and will not switch at all. I think this was the argument that clinched that particular straw poll. But it was a "clear" majority, not an overwhelming one. There were quite a few dissenters. (On the other straw poll in the BOF, that the decision should be taken on engineering grounds, there were only 4 or 5 dissenters.) 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 Thu Jul 29 10:43:44 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22575; Thu, 29 Jul 1993 10:43:51 +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 AA20090; Wed, 28 Jul 1993 19:00:03 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c/IDA-1.2.8) id AA23157; Wed, 28 Jul 1993 11:00:54 +0200 Message-Id: <199307280900.AA23157@mitsou.inria.fr> To: Alex Reijnierse Cc: big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Tue, 27 Jul 93 22:39:27 +0200." <01H11XMLJ7LU8Y72SE@research.ptt.nl> Date: Wed, 28 Jul 93 11:00:53 +0200 From: Christian Huitema => Hi, => => > => > How about the ATN, Air Traffic Network, => > => => And what about the European backbones EuropaNET and Ebone? They all provide => native CLNS. Not to mention the native CLNS networks in Norway, Sweden, => Finland, Denmark, The Netherlands, France, Spain, Italy, Greece, Switzerland => and Portugal. I think i may even have forgotten a few! => => - Alex => I believed up to now that Europanet was native X.25 with support for IP over X.25, and I would certainly not say that Ebone is running a large native CLNP network. Granted, there are a dozen or so experimentors doing CLNP pings and a couple similarly useful things, but speaking of a widely deployed service is somewhat of an exageration. Similarly, you mention a "native CLNS network in France" -- that is new to me. The French research network RENATER supports an X.25 and an IP service; CLNP experiments, when needed, are run on top of IP. On a more political point -- the European "GOSIPs" do not require CLNS, but CONS. The bulk of the OSI traffic is run over X.25, sometimes over RFC-1006. CLNP usage in Europe is very marginal -- probably of the same magnitude as the 0.004% observed on NSFNET. Christian Huitema From owner-big-internet@munnari.oz.au Thu Jul 29 11:30:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24237; Thu, 29 Jul 1993 11:31:33 +1000 (from owner-big-internet) Return-Path: Received: from dnlts0.research.ptt.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22039; Wed, 28 Jul 1993 19:47:54 +1000 (from A.A.Reijnierse@research.ptt.nl) Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H12P2BLOD08Y71T1@research.ptt.nl>; Wed, 28 Jul 1993 11:49:58 +0200 Date: Wed, 28 Jul 1993 11:49:58 +0200 From: Alex Reijnierse Subject: Re: IPDECIDE BOF minutes To: Christian.Huitema@sophia.inria.fr Cc: big-internet@munnari.oz.au Message-Id: <01H12P2BLOD28Y71T1@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: big-internet@munnari.oz.au X-Vms-To: IN%"Christian.Huitema@sophia.inria.fr" X-Vms-Cc: IN%"big-internet@munnari.oz.au" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT > > => > => BTW, how large are the SIP, PIP or TP/IX networks in the world? Can you > => give me some figures about this? i.e. number of (real) routers, number > => of hosts, number of networks that support native SIP, PIP or TP/IX etc.. > => > > Neither of these claim an installed base. Their proponents believe that the > Internet will be better of with a clean new design than by trying to revive > something the market failed to pick for nearly 10 years. > You are talking about a full OSI stack like FTAM, X.400 etc. I must say that i don't use it myself. TUBA, however, only uses the network layer of this protocol stack. And this design is very efficient and flexible. On top of that, TUBA uses normal TCP and UDP with normal applications like Telnet, FTP, SMTP, SNMP etc. If the Internet folks, CCITT folks and the ISO folks can work on this layer as peers, it can even be augmented with the neccesary functionality (like autoconfiguration of NSAPs for example). And for the pure OSI fanatics, you can use a double transport layer stack in the hosts with TP4 alongside with TCP and UDP. That way you can do everything: FTP and FTAM, Telnet and VT, SMTP and X.400 etc..... If you want to do this with SIP, PIP or TP/IX, you also need TWO network layers, which you don't with TUBA. - Alex From owner-big-internet@munnari.oz.au Thu Jul 29 12:33:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26281; Thu, 29 Jul 1993 12:34:02 +1000 (from owner-big-internet) Return-Path: Received: from chsun.chuug.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25489; Wed, 28 Jul 1993 21:15:02 +1000 (from poole@magnolia.eunet.ch) Received: from magnolia.eunet.ch by chsun.eunet.ch (5.65c8/1.34) id AA09560; Wed, 28 Jul 1993 13:15:01 +0200 Message-Id: <199307281115.AA09560@chsun.eunet.ch> Received: from magnolia.eunet.ch by magnolia.eunet.ch id <14171-0@magnolia.eunet.ch>; Wed, 28 Jul 1993 13:15:47 +0200 Subject: Re: IPDECIDE BOF minutes To: A.A.Reijnierse@research.ptt.nl (Alex Reijnierse) Date: Wed, 28 Jul 1993 13:15:42 +0200 (MET DST) Cc: old@sunbim.be, Bob.Hinden@eng.sun.com, big-internet@munnari.oz.au In-Reply-To: <01H11XMLJ7LU8Y72SE@research.ptt.nl> from "Alex Reijnierse" at Jul 27, 93 10:39:27 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 915 From: Simon Poole Sender: poole@magnolia.eunet.ch > > > > How about the ATN, Air Traffic Network, > > > > And what about the European backbones EuropaNET and Ebone? They all provide > native CLNS. Not to mention the native CLNS networks in Norway, Sweden, > Finland, Denmark, The Netherlands, France, Spain, Italy, Greece, Switzerland > and Portugal. I think i may even have forgotten a few! I'll buy you a bottle/glass of your favourite drink if you can produce data showing that the -operational- CLNS usage of any of these networks gets anywhere near a promille (1/1000) of the corresponding IP networks. I'll buy you a second one if you can show that CLNS usage is not actually dropping relativly to IP usage. Naturally we provide a CLNS service just like everybody else so that it can be ticked off on check lists. -- CHUUG/EUnet Switzerland Simon Poole Zweierstrasse 35 Tel: +41 1 291 45 80 CH-8004 Zuerich Fax: +41 1 291 46 42 poole@eunet.ch From owner-big-internet@munnari.oz.au Thu Jul 29 13:40:47 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29507; Thu, 29 Jul 1993 13:42:20 +1000 (from owner-big-internet) Return-Path: Received: from dnlts0.research.ptt.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25773; Wed, 28 Jul 1993 21:25:01 +1000 (from A.A.Reijnierse@research.ptt.nl) Received: from research.ptt.nl by research.ptt.nl (PMDF V4.2-13 #2928) id <01H12SKCQT4W8Y71T1@research.ptt.nl>; Wed, 28 Jul 1993 13:27:05 +0200 Date: Wed, 28 Jul 1993 13:27:05 +0200 From: Alex Reijnierse Subject: Re: IPDECIDE BOF minutes To: poole@magnolia.eunet.ch Cc: big-internet@munnari.oz.au Message-Id: <01H12SKCRVPU8Y71T1@research.ptt.nl> Organization: PTT Research, the Netherlands X-Envelope-To: big-internet@munnari.oz.au X-Vms-To: IN%"poole@magnolia.eunet.ch" X-Vms-Cc: IN%"big-internet@munnari.oz.au" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT > I'll buy you a bottle/glass of your favourite drink if you can produce > data showing that the -operational- CLNS usage of any of these networks > gets anywhere near a promille (1/1000) of the corresponding IP networks. > I am no network operator, so i wouldn't know about that. However, i am sure that you are right about those figures. But pay attention to TUBA and watch those figures rise steadily. > I'll buy you a second one if you can show that CLNS usage is not actually > dropping relativly to IP usage. > OK, but that's due to the growth of IP, what exactly the problem is. Again, pay attention to the GROWTH of CLNP traffic (and i am not talking about the next couple of months). > Naturally we provide a CLNS service just like everybody else so that it can > be ticked off on check lists. Keep it on, you won't regret it. - Alex From owner-big-internet@munnari.oz.au Thu Jul 29 14:31:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02272; Thu, 29 Jul 1993 14:32:01 +1000 (from owner-big-internet) Return-Path: Received: from laidbak.i88.isc.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02830; Thu, 29 Jul 1993 01:06:08 +1000 (from stevea@lachman.com) Received: from ra.i88.isc.com by laidbak.i88.isc.com with SMTP (5.65/isc-mail-gw/2/23/93) id AA04981; Wed, 28 Jul 93 09:20:36 -0500 Received: from lancelot.i88.isc.com by ra.i88.isc.com (4.1/SMI-4.1) id AA21868; Wed, 28 Jul 93 09:23:08 CDT Message-Id: <9307281423.AA21868@ra.i88.isc.com> To: big-internet@munnari.oz.au Subject: Re: N^2 growth... (NOT!) In-Reply-To: Message from tracym@NSD.3Com.COM of 27 Jul 1993 21:10:28 PDT Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 28 Jul 1993 09:23:08 -0500 From: Steve Alexander tracym@NSD.3Com.COM writes: >H, the number of networked hosts, is probably O(P, number of phones). I guess this depends on whether you subscribe to the "ToasterNet" philosophy that says "all of your toasters, microwaves, TVs, VCRs, etc. will need to be IP addressable." I personally don't know whether I want the Chaos Computer Club to be able to change my radio station, but that's really a security problem I guess.... I have three computers in my cube, but only two phone lines (one is attached to a computer). It's not clear whether the average person has as much "personal technology" as most of the readers of this list. However some of the admins here have had as many as 3 computers in their offices at times, but never more than one phone. Arguably, this is due more to bad planning than a love of CPUs ;-> I guess the point I'm trying (badly) to make is that a lot of folks have an expectation that we will all be waist-deep in electronics and all of that stuff will be networked. If so, it seems that this is a much larger problem than that faced by the Telecom folks. Comments? -- Steve From owner-big-internet@munnari.oz.au Thu Jul 29 15:28:36 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04471; Thu, 29 Jul 1993 15:29:01 +1000 (from owner-big-internet) Return-Path: Received: from large.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03254; Thu, 29 Jul 1993 01:21:44 +1000 (from dkatz@cisco.com) Received: by large.cisco.com id AA07201 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Wed, 28 Jul 1993 08:20:08 -0700 Date: Wed, 28 Jul 1993 08:20:08 -0700 From: Dave Katz Message-Id: <199307281520.AA07201@large.cisco.com> To: craig@aland.bbn.com Cc: amolitor@moink.nmsu.edu, big-internet@munnari.oz.au In-Reply-To: Craig Partridge's message of Tue, 27 Jul 93 17:38:36 -0700 <9307280038.AA07151@aland.bbn.com> Subject: Variable length addresses and security - Of course, there's no requirement to hash the entire address; it is only necessary to hash a part of the address that is likely to have a high degree of entropy. Step 3 is where one fusses. In most routers, 95+% of all route lookups are actually served by hashing the address (or similar operation) to find a cached route, NOT a full routing lookup. So the question is whether the variable address is structured in such a way that computing a good hash is much harder than compute the hash on a fixed length address. IP is a snap, it is one instruction or two instructions on one word on almost every processor. Ditto for 64-bit addresses. Trekking through a variable number of bytes will take longer, but how much longer? We're in a world where tens of instructions is a lot. Van Jacobson showed code at SIGCOMM '90 that could forward an IP datagram in << 100 instructions, so an extra 10 instructions would be a 10% performance reduction (probably not a big deal) and an extra 50 instructions would be a 50% performance reduction (a big deal). From owner-big-internet@munnari.oz.au Thu Jul 29 16:43:20 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07179; Thu, 29 Jul 1993 16:43:44 +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 AA04505; Thu, 29 Jul 1993 02:05:18 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA01014 for big-internet@munnari.oz.au; Wed, 28 Jul 93 12:03:56 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA11592; Wed, 28 Jul 93 09:02:33 PDT Message-Id: <9307281602.AA11592@aland.bbn.com> To: Dave Katz Cc: amolitor@moink.nmsu.edu, big-internet@munnari.oz.au Subject: re: Variable length addresses and security - From: Craig Partridge Date: Wed, 28 Jul 93 09:02:33 -0700 Sender: craig@aland.bbn.com > Of course, there's no requirement to hash the entire address; it is > only necessary to hash a part of the address that is likely to have a > high degree of entropy. Dave: Good point! This assumes of course that the high entropy section of the variable length address is easy to find (i.e. doesn't require complex parsing to locate). Craig From owner-big-internet@munnari.oz.au Thu Jul 29 17:37:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09004; Thu, 29 Jul 1993 17:38:21 +1000 (from owner-big-internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05187; Thu, 29 Jul 1993 02:40:17 +1000 (from braden@ISI.EDU) Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 28 Jul 1993 09:40:02 -0700 Date: Wed, 28 Jul 1993 09:40:07 -0700 From: braden@ISI.EDU Posted-Date: Wed, 28 Jul 1993 09:40:07 -0700 Message-Id: <199307281640.AA22660@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id ; Wed, 28 Jul 1993 09:40:07 -0700 To: craig@aland.bbn.com Subject: re: Variable length addresses and security - Cc: big-internet@munnari.oz.au *> forward an IP datagram in << 100 instructions, so an extra 10 instructions *> would be a 10% performance reduction (probably not a big deal) and an extra *> 50 instructions would be a 50% performance reduction (a big deal). *> Craig, It is such a big deal? On another day, you have argued vigously for general-purpose CPUs instead of microcode, on the basis that processor speeds are doubling every K years (I forget what K was, but it was not >> 1 year). Bob From owner-big-internet@munnari.oz.au Thu Jul 29 18:28:11 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10654; Thu, 29 Jul 1993 18:28:39 +1000 (from owner-big-internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04787; Thu, 29 Jul 1993 02:22:54 +1000 (from braden@ISI.EDU) Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Wed, 28 Jul 1993 09:20:40 -0700 Date: Wed, 28 Jul 1993 09:20:45 -0700 From: braden@ISI.EDU Posted-Date: Wed, 28 Jul 1993 09:20:45 -0700 Message-Id: <199307281620.AA22647@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id ; Wed, 28 Jul 1993 09:20:45 -0700 To: Christian.Huitema@sophia.inria.fr, brian@dxcern.cern.ch Subject: Re: Installed bases [was: Re: IPDECIDE BOF minutes] Cc: big-internet@munnari.oz.au *> *> A plausible conclusion from this is that TUBA should have been *> designed in 1985. *> *> 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 | *> | PIP, SIP, TP/IX, Nimrod, TUBA or anything. Really. | *> Brian, In 1985, the "old boys" on the IAB believed that US government pressure would create a rising tide of CLNP that would inevitably replace IP in the US [in 1985, there was no significant non-US TCP/IP]. We looked at CLNP, "the enemy", and decided it would not be so bad. Reading the ISO documentation, written by some medieval monk, was a little hard to stomache, but CLNP was apparently just IP with variable length addresses. Well, OK, we had almost decided to have variable-length addresses in IP (in fact, left to themselves, the researchers probably would have chosen variable-length IP addresses, but the ARPA program manager, who is still among us in a three-piece suit, injected his wisdom!). So, we didn't design TUBA in 1985 because we expected the whole stack to be dropped on us, for reasons having little to do with technical merit. But times have changed since 1985. I think that Christian is overstating the case against CLNP. It seems to me that CLNP and IP are, to first order, functionally isomorphic, and that any format or encoding differences will surely be swamped by other issues and disappear into the microcode. On the other hande, I seriously hope that I retire before ISO-speak becomes a Way of Life in networking!. Bob Braden From owner-big-internet@munnari.oz.au Thu Jul 29 19:30:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12783; Thu, 29 Jul 1993 19:30:08 +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 AA03952; Thu, 29 Jul 1993 15:11:58 +1000 (from tli@cisco.com) Received: by lager.cisco.com id AA21244 (5.67a/IDA-1.5 for big-internet@munnari.oz.au); Wed, 28 Jul 1993 22:10:56 -0700 Date: Wed, 28 Jul 1993 22:10:56 -0700 From: Tony Li Message-Id: <199307290510.AA21244@lager.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Cc: big-internet@munnari.oz.au, brian@dxcern.cern.ch Subject: Re: IPDECIDE BOF minutes so i vote for two solutions. jon Another problem with n>1 solutions is that each costs money to implement. And as a result, end users are going to end up paying for each solution that gets implemented, even if they never use it. And of course, the vendors will want to make money based on this investment. So if you're seriously willing to pay for all of this development, go ahead, standardize all you want, we'll make more. ;-) Tony p.s. Are you sure two is enough? Would you like six? How about ten? pps. Did I mention that I'm a stockholder. Oh yeah, I vote for zillions of solutions.... not > >> 1 year). Bob: This is Hennessy and Patterson's argument and is somewhat more complex. It says, in general, special purpose hardware has difficulty tracking the performance improvements of general-purpose CPUs. From this argument, I take the view that usually makes sense to build around general purpose CPUs. My point about amount of code is somewhat different. It is of the form, given that Protocol U costs N instructions, and Protocol V costs 1.5 * N instructions, Protocol U is cheaper and possibly preferred, in that I either have buy 50% more hardware power to get Protocol V to run comparably with Protocol U. OK -- before the brickbats, yes this is an approximate argument. Instructions aren't the only measure -- misses out of cache, number of loads and stores, etc., all matter. And depending upon how the hardware works, it may be that one just has to change the clock crystal (and run the 486 or whatever at 50 MHz instead of 33MHz) and so the cost is a few tens of dollars. (On the other hand, if one needs to increase the memory speed clock rate and get faster memory, then....). But, in general, over a range of platforms, we should expect that significant additional processing costs can't be swept under the rug. Craig From owner-big-internet@munnari.oz.au Thu Jul 29 20:34:02 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15112; Thu, 29 Jul 1993 20:36:11 +1000 (from owner-big-internet) Return-Path: Received: from POSTOFFICE.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06182; Thu, 29 Jul 1993 03:29:42 +1000 (from swb1@cornell.edu) Received: from [132.236.195.71] by postoffice.mail.cornell.edu with SMTP id AA27327 (5.65c8/IDA-1.4.4 for big-internet@munnari.oz.au); Wed, 28 Jul 1993 13:29:07 -0400 Message-Id: <199307281729.AA27327@postoffice.mail.cornell.edu> Date: Wed, 28 Jul 1993 13:29:45 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au From: Scott Brim X-Sender: swb1@postoffice.mail.cornell.edu Subject: Re: N^2 growth... Cc: jnc@ginger.lcs.mit.edu I haven't had time to go through your 11K mail on N^2 yet. A quick look has me intrigued. Over the next few days I'll try to craft a reply with some worthwhile thought in it. Scott From owner-big-internet@munnari.oz.au Thu Jul 29 21:11:33 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16156; Thu, 29 Jul 1993 21:11:45 +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 AA06271; Thu, 29 Jul 1993 03:34:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10056; Wed, 28 Jul 93 13:33:50 -0400 Date: Wed, 28 Jul 93 13:33:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307281733.AA10056@ginger.lcs.mit.edu> To: amolitor@moink.nmsu.edu, craig@aland.bbn.com Subject: re: Variable length addresses and security - Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu So the question is whether the variable address is structured in such a way that computing a good hash is much harder than compute the hash on a fixed length address. ... the only way to resolve the cost of variable length addresses is to propose a format, and then post a lean and mean hash function that shows good hash properties and doesn't require many instructions. Craig, you have to not only consider the cost of the hash, but you also have the cost of comparing the entry(ies) at the bucket named by that tag, to make sure you got a match. Of course, if all packets contained a shortish, unique, fixed length thing which they could use for a hash key/match, and only some packets contained a longer, variable length thing which had all the nice flexibility some of us think we need in an address, we'd be all set, right? :-) Noel From owner-big-internet@munnari.oz.au Thu Jul 29 23:29:51 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20315; Thu, 29 Jul 1993 23:31:08 +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 AA05710; Thu, 29 Jul 1993 03:05:58 +1000 (from cmj@bridge2.NSD.3Com.COM) Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA12493 (5.65c/IDA-1.4.4nsd for ); Wed, 28 Jul 1993 10:05:30 -0700 Received: by jaspar.NSD.3Com.COM id AA11527 (5.65c/IDA-1.4.4-910730); Wed, 28 Jul 1993 10:05:28 -0700 Date: Wed, 28 Jul 1993 10:05:28 -0700 From: "Cyndi M. Jung" Message-Id: <199307281705.AA11527@jaspar.NSD.3Com.COM> To: Christian.Huitema@sophia.inria.fr Subject: Re: IPDECIDE BOF minutes Cc: big-internet@munnari.oz.au >=> >=> BTW, how large are the SIP, PIP or TP/IX networks in the world? Can you >=> give me some figures about this? i.e. number of (real) routers, number >=> of hosts, number of networks that support native SIP, PIP or TP/IX etc.. >=> >=> Alex Reijnierse >Neither of these claim an installed base. Their proponents believe that the >Internet will be better of with a clean new design than by trying to revive >something the market failed to pick for nearly 10 years. >Christian Huitema I don't think it was really a failure on the part of the "market" to pick up CLNP - it's been an expensive game played between vendors and users, with the technology as both the carrot and the whip, somewhat like the football that Lucy offers annually to Charlie Brown. The "universal solution" is appealing to users, but frightening to large vendors with a proprietary choke-hold on their customers. The advent of TCP/IP drove a stake in the heart of these proprietary network solutions, but it wasn't due to any great technological breakthrough the protocols had to offer, it was the breadth of products that became available at a critical time, the time of need. Most of that product development was done to supply the military - DARPA funding was critical to the success of TCP/IP, as was Berkeley Unix, ethernet, and graphics on the popular workstations. Brave users with convictions bought these products and forced them to work in a heterogeneous environment. These days, users are a little wiser, and don't attempt to mix and match as freely as they did in the beginning, plus the products are differentiated beyond simple offerings of standard applications like Telnet, FTP, SMTP, all with DNS support - there are client-server applications, distributed file systems, platforms for applications at various levels, APIs, and lots of other ways for the vendors to add value and differentiate their products (so they can charge a premium and gain some competitive advantage, dispite the hope of the user community to be able to reduce the cost through open competition!). The open market pressures have demanded more services, better products, and have created a great feedback loop that supplies those demands - it's great, it's a fine example of the good aspects of a capitalist economy. And so it goes. OSI as a concept has indeed been realized by TCP/IP - the need was filled, history cannot repeat itself because the conditions have changed. That's why the market failed to pick it up - because the market was being satisfied by TCP/IP, not because the market decided that OSI was wrong for technical reasons. And the market will continue to be satisfied by solutions with available products - they will never select a paper solution. A clean new design is not the urgent issue - IP has been running out of address space and the routing architecture is crumbling. The market wants networks and services - whatever underlying mechanism that can deliver that will be fine for them - they are concerned about other things, this is the plumbing - the less they see of it, the better they feel. The research into other modes of network service needs to continue, but the Internet needs a stable platform on which to continue research for higher level protocols as well. Cyndi Jung From owner-big-internet@munnari.oz.au Fri Jul 30 00:41:37 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23291; Fri, 30 Jul 1993 00:41:48 +1000 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06892; Thu, 29 Jul 1993 03:47:43 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws13.merit.edu by vela.acs.oakland.edu with SMTP id AA04827 (5.65c+/IDA-1.4.4); Wed, 28 Jul 1993 13:46:19 -0400 Date: Wed, 28 Jul 93 12:05:05 EDT From: "William Allen Simpson" Message-Id: <914.bill.simpson@um.cc.umich.edu> To: jmh@anubis.network.com (Joel Halpern) > Cc: rolc@network.com, atm@sun.com, Big-Internet@munnari.oz.au, > iplpdn@ietf.cnri.reston.va.us, iesg@cnri.reston.va.us Reply-to: bsimpson@morningstar.com Subject: Re: Routing Over Large Clouds > As a consequence of several discussions at the last IETF, and new > WG/BOF is being formed. > > This group will be focussed on the problems of routing over large > switched clouds. > > A charter for this group is being developed with the Routing Area > director. > I oppose the formation of a new working group for this area, unless it can be shown that existing groups are incapable of handling this task. This was the purpose of the IPLPDN WG. Extract from IPLPDN charter: The IP over Large Public Data Networks Working Group will specify the operation of the TCP/IP protocol suite over Public Data Networks (PDNs) such as SMDS, ISDN, X.25 PDNs, and Frame Relay. The Working Group will develop and define algorithms for the resolution of IP addresses and for the routing of IP datagrams over large, potentially global, public data networks. We never did see any *routing* work out of them. Since you were a prominent member of that group, I don't see how making a new working group will improve the performance. I would agree that IPLPDN has not handled the work assigned to them, but was diverted to simpler tasks outside their charter -- creating several incompatible schemes for sending multi-protocol datagrams over LPDN. This just resulted in turf wars with other multi-protocol efforts. I suspect that we will see more turf wars as the new group conflicts with the efforts of existing WGs, and with the IPng groups, which are also working on the broader routing questions. I suggest that we disband the IPLPDN group, and focus on building the desired routing features into the various IPng proposals. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Fri Jul 30 01:17:48 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24558; Fri, 30 Jul 1993 01:20:00 +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 AA07980; Thu, 29 Jul 1993 04:13:02 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27843; Wed, 28 Jul 93 14:06:51 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA20601; Wed, 28 Jul 93 14:13:34 EDT Date: Wed, 28 Jul 93 14:13:34 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307281813.AA20601@cabernet.wellfleet> To: brian@dxcern.cern.ch Subject: Re: IPDECIDE BOF minutes Cc: big-internet@munnari.oz.au In other words it picked APPLICATIONS. And IP won out over X.25 and SNA (and XNS :-) in the scientific/technical market because of APPLICATIONS. In the business market SNA didn't do too bad, because of APPLICATIONS. And DECnet was very popular in several market sectors because of APPLICATIONS. The market, actually, doesn't care about network layer protocols. Brian; I think that this is basically correct. CLNP solves a number of real customer problems which routing vendors have had to deal with for years. However, up until recently it just didn't have any applications running over it that people wanted to run. Thus optimizing CLNP performance has until recently been rather low on the list of priorities for a vendor. I wish that the IETF was better at stealing the good ideas from CLNP and feeding them into the other IPng proposals (I have been *trying* to privately convince folks to do this). Ross From owner-big-internet@munnari.oz.au Fri Jul 30 02:32:31 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26893; Fri, 30 Jul 1993 02:32:34 +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 AB09581; Thu, 29 Jul 1993 04:53:20 +1000 (from craig@aland.bbn.com) Received: from port12.sunnyvale.ca.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA18217 for big-internet@munnari.oz.au; Wed, 28 Jul 93 14:53:08 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA11967; Wed, 28 Jul 93 11:51:39 PDT Message-Id: <9307281851.AA11967@aland.bbn.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: re: Variable length addresses and security - Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu From: Craig Partridge Date: Wed, 28 Jul 93 11:51:38 -0700 Sender: craig@aland.bbn.com > Craig, you have to not only consider the cost of the hash, but you also have > the cost of comparing the entry(ies) at the bucket named by that tag, to make > sure you got a match. Noel, Yeah that's true, but I think parsing out or aligning the part of the address on which you want to do the hash is worse. Doing the compare, I can do word comparisons (new processors have 8 bytes per word) plus perhaps 2 masks to clear out the unwanted bytes at the start and end of the address. The point is, I don't have to start parsing bits in the address to find the meat of the address that I want to hash. Craig From owner-big-internet@munnari.oz.au Fri Jul 30 03:11:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28506; Fri, 30 Jul 1993 03:12:30 +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 AA07681; Thu, 29 Jul 1993 04:02:18 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA27763; Wed, 28 Jul 93 13:56:05 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA20595; Wed, 28 Jul 93 14:02:48 EDT Date: Wed, 28 Jul 93 14:02:48 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307281802.AA20595@cabernet.wellfleet> To: amolitor@moink.nmsu.edu, big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: Variable length addresses and security (actually, efficiency) Cc: rcallon@wellfleet.com More generally, variable length addresses are less efficient, computationally. Does anyone have any figures to show if this is or is not significant? (Andrew) This depends upon how it is implemented. The same is true of larger addresses. We (where "we" means pretty much all of the routing vendors, I would guess) know how to implement large and/or variable addresses very efficiently, but it takes some time and engineering resources. It will not have any appreciable effect on the cost of the resulting system (especially large fixed addresses, which are a bit easier than variable length addresses). Step 3 is where one fusses. In most routers, 95+% of all route lookups are actually served by hashing the address (or similar operation) to find a cached route, NOT a full routing lookup. So the question is whether the variable address is structured in such a way that computing a good hash is much harder than compute the hash on a fixed length address. IP is a snap, it is one instruction or two instructions on one word on almost every processor. Ditto for 64-bit addresses. Trekking through a variable number of bytes will take longer, but how much longer? We're in a world where tens of instructions is a lot. Van Jacobson showed code at SIGCOMM '90 that could forward an IP datagram in << 100 instructions, so an extra 10 instructions would be a 10% performance reduction (probably not a big deal) and an extra 50 instructions would be a 50% performance reduction (a big deal) (Craig) This is based on an assumption about how longer addresses would be handled in future routers which is not in fact correct. Tony Li sort of hinted at the same fact: Long address lookups are not going to slow down the router, nor increase the cost, provided that you wait for a little engineering to get done (and much as Tony does not want to give me the details of what they are doing, I don't want to give him the same details either). One thing that people don't seem to have gotten the point of is that processing it *NOT* a particularly important concern with high speed routers. MUCH MUCH more important is avoiding *delay* (like, while waiting for a directory lookup or ARP request to return). Also, the processing in the network/IP layer is *not* a big part of the overall processing required to forward a packet. Much more processing is required for data link layers and buffer management. The Internet is obviously growing rapidly. We can't keep growing rapidly unless we start selling to small companies and/or homes (and there are other reasons to expect that we *will* start selling to small companies and homes -- such as actual networks that are starting to appear at my neighbor's small companies and home entertainment companies which are getting into the act). This implies that we are going to have to route to many small stub domains over a large branchy public network (probably either ATM, ISDN, X.25, or the telephone network). If we have to do a directory style lookup to map from an IP-level address to a public service network address then we are going to have *delay* in the fast path. This does terrible things to the cost and performance of high speed routers. The only way around this is to very efficiently handle the 95+% case of very small stub domains tied to a single public net in one place, which involves some form of embedding the public net address somewhere in the data packet. If this is not in a longer IP-level address, then it has to be somewhere else in the packet (and probably becomes more complex to handle). I could go on, but the point is that *small* addresses, if they require directory style lookups or going to ARP servers or other *delay* sources are going to be a horrible mess for high speed routers in the anticipated Internet of 1998. Larger addresses are going to require a bit of engineering, but are not going to increase the cost nor significantly reduce the performance. Ross From owner-Big-Internet@munnari.oz.au Fri Jul 30 03:48:41 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29797; Fri, 30 Jul 1993 03:49:13 +1000 (from owner-Big-Internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29788; Fri, 30 Jul 1993 03:48:41 +1000 (from braden@ISI.EDU) Received: from can.isi.edu by venera.isi.edu (5.65c/5.61+local-12) id ; Thu, 29 Jul 1993 10:48:35 -0700 Date: Thu, 29 Jul 1993 10:48:40 -0700 From: braden@ISI.EDU Posted-Date: Thu, 29 Jul 1993 10:48:40 -0700 Message-Id: <199307291748.AA23281@can.isi.edu> Received: by can.isi.edu (5.65c/4.0.3-4) id ; Thu, 29 Jul 1993 10:48:40 -0700 To: braden@ISI.EDU, dave@mail.bellcore.com Subject: Re: Installed bases [was: Re: IPDECIDE BOF minutes] Cc: big-internet@munnari.oz.au *> From dave@mail.bellcore.com Thu Jul 29 10:29:21 1993 *> Date: Thu, 29 Jul 93 13:29:42 -0400 *> From: David Piscitello *> To: braden@ISI.EDU *> Cc: big-internet@munnari.oz.au *> Subject: Re: Installed bases [was: Re: IPDECIDE BOF minutes] *> Content-Length: 357 *> X-Lines: 12 *> *> >Reading the ISO *> >documentation, written by some medieval monk, was a little hard to *> *> excuse me, but the author of ISO 8473 objects to being *> characterized as "some medieval monk":-) *> It's not his fault. The elders from large powerful churches controlled his environment, and others designed the castle, the stool, the quill pen... and the religious framework within which he had to write his story. :-) Bob From owner-big-internet@munnari.oz.au Fri Jul 30 04:08:21 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00528; Fri, 30 Jul 1993 04:08:29 +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 AA18551; Thu, 29 Jul 1993 22:37:28 +1000 (from kasten@ftp.com) Received: by ftp.com id AA01698; Thu, 29 Jul 93 08:37:11 -0400 Date: Thu, 29 Jul 93 08:37:11 -0400 Message-Id: <9307291237.AA01698@ftp.com> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com > so i vote for two solutions. > jon Jon, What do you mean by this? If there are two, equal, primary internetworking layer protocols, wouldn't this lead to splitting the network up into two separate communities, with few points of contact between them (presuming that only a relatively few systems are dual-stacked -- if everyone were dual-stacked, then we are being just plain silly)? Or do you mean anoint two and then let the world at large decide? Sort of like CMOT and SNMP. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-big-internet@munnari.oz.au Fri Jul 30 04:47:39 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01899; Fri, 30 Jul 1993 04:47:55 +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 AA19428; Thu, 29 Jul 1993 23:04:57 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <14587>; Thu, 29 Jul 1993 09:04:33 -0400 Received: from dino.alias.com by barney.alias.com with SMTP id AA12105 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Thu, 29 Jul 93 08:56:29 -0400 Received: by dino.alias.com id AA27557 (5.65a/IDA-1.4.2 for J.Crowcroft@cs.ucl.ac.uk); Thu, 29 Jul 93 08:56:24 -0400 Date: Thu, 29 Jul 1993 08:56:24 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9307291256.AA27557@dino.alias.com> To: Jon Crowcroft Subject: Re: N^2 growth... multicast... Cc: big-internet@munnari.oz.au >people should join the IDMR list if they want the lively action on this >(subsriptions to idrm-request@cs.ucl.ac.uk) Uh Uh, The subscription address is idmr-request@cs.ucl.ac.uk From owner-big-internet@munnari.oz.au Fri Jul 30 04:57:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02179; Fri, 30 Jul 1993 04:58:56 +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 AA14347; Thu, 29 Jul 1993 07:17:39 +1000 (from rcallon@wellfleet.com) Received: from cabernet.wellfleet (cabernet.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA29039; Wed, 28 Jul 93 17:11:41 EDT Received: by cabernet.wellfleet (4.1/SMI-4.1) id AA20697; Wed, 28 Jul 93 17:18:25 EDT Date: Wed, 28 Jul 93 17:18:25 EDT From: rcallon@wellfleet.com (Ross Callon) Message-Id: <9307282118.AA20697@cabernet.wellfleet> To: atkinson@itd.nrl.navy.mil, big-Internet@munnari.oz.au Subject: Re: PIP and SIP installed base The other item to note is that both PIP and SIP have been demonstrated running over the current IPv4 infrastructure with no changes needed, so deployed base of routers is a non-issue. TUBA does not even claim to have the smooth transition property that both SIP and PIP claim to have. I very strongly disagree with this. There are only two differences between the TUBA and IPAE transition schemes that I am aware of (after looking at both in some detail): - While both use encapsulation, IPAE puts more emphasis on it - IPAE uses translation. TUBA doesn't. The first of these is really just an editorial difference. In fact I would guess that in most cases configuration of encapsulation is likely to turn out to be awkward enough in large environments that folks will try to get away from it where convenient. Translation is another issue altogether. This is in my opinion one of the most serious problems with IPAE. For example, translation does not work where there are IP addresses embedded in the application. It is not sufficient for the translating routers to "just" look in the application packets and translate addresses due to several problems: (i) since the address length changes, this throws off the TCP sequence number; (ii) there will be applications which encrypt addresses; (iii) unless you have the router understand a truely enormous number of applications, there are bound to be some which the router can't translate. This means that the IPng host will need to deal with IP addresses embedded in application packets. It is not clear that this is easier (or even equally easy) to just running dual stack. I would be somewhat surprised if translation were to turn out to work in enough situations to make it worth the trouble. In terms of SIP and PIP working over IPv4 without updating routers, unless you update *some* routers you have not gained any advantage. It would be really easy to define a new IPng if we could just run globally over the IPv4 infrastructure full time. If you update some routers but not all, then you have introduced a number of difficult questions which really should be answered before we choose this as part of the solution. TUBA claims to have a transition strategy which works. This is an important feature. [In fairness, I am sure that IPAE also claims to work, but I think that there are a lot of details which are not going to be easy to get going]. Also, the transition strategies are not really all that different -- IPAE and TUBA have been getting more similar over time. As near as I can tell, both PIP and SIP are at least as fully baked and tested as the TUBA proposals are. SIP, in particular, has a fairly large number of independent implementations that interoperate. I have not been keeping much track of the TP/IX proposal. When I looked at SIP and PIP, I didn't see a spec which was complete enough to build a router. I saw a lot of issues with SIP/IPAE which I communicated privately to some of the SIP/IPAE folks (and in fairness I think they should be given time to try to answer them). I'm responding to traffic on big-Internet, but I'm not at all sure that this thread belongs here. Perhaps followups belong on the main ietf list since the reason we are dicussing this is mainly the TUBA Last Call ?? Actually, while we seem to disagree on lots of the details, we may be in agreement on one big issue. I feel that it is too early to make a final decision as to which IPng to choose, and I suppose that it might appear to some folks that allowing one protocol to make it to proposed standard would look like we were making an IPng choice (although TUBA does have more implementation experience and more deployment than is usually required for going to proposed standard). Ross From owner-big-internet@munnari.oz.au Fri Jul 30 07:15:55 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06386; Fri, 30 Jul 1993 07:16:53 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307292116.6386@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06915; Thu, 29 Jul 1993 16:36:20 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 29 Jul 1993 07:35:38 +0100 To: Tony Li Cc: big-internet@munnari.oz.au, brian@dxcern.cern.ch Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Wed, 28 Jul 93 22:10:56 PDT." <199307290510.AA21244@lager.cisco.com> Date: Thu, 29 Jul 93 07:35:35 +0100 From: Jon Crowcroft > so i vote for two solutions. > jon > >Another problem with n>1 solutions is that each costs money to >implement. And as a result, end users are going to end up paying for >each solution that gets implemented, even if they never use it. And >of course, the vendors will want to make money based on this >investment. >So if you're seriously willing to pay for all of this development, >go ahead, standardize all you want, we'll make more. ;-) i thoughtr someone said we could choose CLNP coz it was already here so i wouldnt have to pay:-) an early point i made was that i have to pay for host implementations of clnp - routers aren't the problem compared to the number of hosts we have... >p.s. Are you sure two is enough? Would you like six? How about ten? >pps. Did I mention that I'm a stockholder. Oh yeah, I vote for >zillions of solutions.... i said it isn't a _choice_ - clnp is here. ip migrating to SIP would mean we have the SAME numnber we have now (less if all the DECNET people upgrade:-) multi-protocol is the way to go because it gets ytou into the habit of having last years system, this years system and mext years around at the same time - just lkike we do in well managed software installations - change is the only constant, so engineer for it... i was serious. jon From owner-big-internet@munnari.oz.au Fri Jul 30 10:38:14 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13907; Fri, 30 Jul 1993 10:39:09 +1000 (from owner-big-internet) Return-Path: Received: from post.demon.co.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22882; Fri, 30 Jul 1993 00:29:08 +1000 (from @tdc001.demon.co.uk:Tim.Dixon@newcastle.ac.uk) Received: from tdc001.demon.co.uk by post.demon.co.uk id aa26792; 29 Jul 93 15:19 BST Date: Thu, 29 Jul 1993 15:21:13 +0000 To: big-internet@munnari.oz.au From: Tim Dixon X-Sender: ntmd@eata.ncl.ac.uk (Unverified) Subject: Re: Variable length addresses Message-Id: <9307291520.aa26792@post.demon.co.uk> At 8:54 27/7/93 -0600, Andrew Molitor wrote: > More generally, variable length addresses are less efficient, >computationally. Does anyone have any figures to show if this is >or is not significant? > > Andrew Whereas it might be argued that variable-length addresses are more difficult to process on typical host systems, I don't think there is a general argument that they make the construction of routers any harder. It might be true that manufacturers of routers which were designed first for the IP market find it (a bit) easier to deal with fixed-length addressing. Any router based on a typical general purpose RISC processor might also find it easier. There are routers whose hardware was targetted initially at variable-length addresses, and I don't think there's much evidence that these suffer an intrinsic performance penalty. I think one could argue that in the interests of high throughput and low delay, that it is desirable to perform the address lookup as the address is arriving on the wire: having to wait for the complete address to arrive is not necessarily a desirable property of a high-speed router. In this case, the structure of the address is rather more important than either its length or whether that length is fixed or variable. The hardware will follow the needs of the architecture (and the market!), and it isn't something that has much impact on the choice of architecture. Tim PS: My biggest problem with the "fixed-length-address" proposals is that they assume, unrealistically in my view, that business customers with private networks which do not connect to the Internet, or who have other networking technologies in place (IPX has been mentioned on more than one occasion...) will be prepared to pay the additional administrative costs of officially assigning IPng addresses to their machines [or ultimately to reveal to an unofficial organisation sensitive information, such as the likely number of networked computer systems in various divisions of their company]. My belief is that the 64-bit schemes are "acceptability- challenged" purely on the grounds that they cannot contain existing Novell assignments. It is the "trivial" administrative matters such as this which control whether the cost of ownership of the technology is acceptable. Hardware costs go down; human costs go up. From owner-big-internet@munnari.oz.au Fri Jul 30 12:31:59 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB18224; Fri, 30 Jul 1993 12:32:43 +1000 (from owner-big-internet) Return-Path: Received: from worldlink.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29140; Fri, 30 Jul 1993 03:29:38 +1000 (from dave@mail.bellcore.com) Received: from localhost by worldlink.worldlink.com (5.65b/4.0.071791-Worldlink) id AA01363; Thu, 29 Jul 93 13:29:42 -0400 Date: Thu, 29 Jul 93 13:29:42 -0400 Message-Id: <9307291729.AA01363@worldlink.worldlink.com> From: David Piscitello To: braden@ISI.EDU Cc: big-internet@munnari.oz.au Subject: Re: Installed bases [was: Re: IPDECIDE BOF minutes] >Reading the ISO >documentation, written by some medieval monk, was a little hard to excuse me, but the author of ISO 8473 objects to being characterized as "some medieval monk":-) Also, in the future, please be sure to qualify "monk", as in {Jesuit, Augustinian, Franciscan...}. (I'm of the genus "Augustinian", since I was graduated from Villanova.) From owner-big-internet@munnari.oz.au Fri Jul 30 15:28:00 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25387; Fri, 30 Jul 1993 15:29:23 +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 AA10142; Fri, 30 Jul 1993 09:15:11 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA21499; Thu, 29 Jul 93 19:14:30 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9307292314.AA21499@wizard.gsfc.nasa.gov> Subject: Re: IPDECIDE BOF minutes To: kasten@ftp.com Date: Thu, 29 Jul 1993 19:14:30 -0400 (EDT) Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au In-Reply-To: <9307291237.AA01698@ftp.com> from "Frank Kastenholz" at Jul 29, 93 08:37:11 am X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2120 > Date: Thu, 29 Jul 93 08:37:11 -0400 > From: kasten@ftp.com (Frank Kastenholz) > > > so i vote for two solutions. > > jon > > Jon, > > What do you mean by this? If there are two, equal, primary internetworking > layer protocols, wouldn't this lead to splitting the network up into two > separate communities, with few points of contact between them (presuming > that only a relatively few systems are dual-stacked -- if everyone were > dual-stacked, then we are being just plain silly)? As I indicated in a separate IETF message, I think it's a fact of life that we are going to have to deal with separate IP and CLNP Internets for the foreseeable future, which to me is at least 10 years. I don't think there's anyone that's going to change that no matter what we do. > Or do you mean anoint two and then let the world at large decide? Sort > of like CMOT and SNMP. As far as the market deciding, in the case of NASA Goddard, it basically has. Even with GOSIP, there are approximately 4600 registered IP nodes (and currently adding 200 IP nodes per month) and only 40 OSI nodes and these are basically experimental. In terms of actual network usage, the difference is probably even more substantial. By contrast, there are about 1100 AppleTalk nodes, 2100 XNS nodes, 800 DECnet nodes, 500 LAT nodes, and 300 IPX nodes. There just has been no market for real operational use of OSI. There obviously has been a market for all kinds of other protocols but not for OSI. The reason for this is that there has been no compelling reason for people to use OSI protocols, and people won't make the effort unless there's a real, substantial benefit. There's nothing that they need to do that can't be handled easier, cheaper, and faster by TCP/IP. The only significant use of any OSI application is X.500 for White Pages service and some X.400 mail. As a side note, someone made a comment that IPX had the largest installed base. I don't know whether or not this is true, but it should be pointed out that these IPX sites are not joined in any kind of IPX Internet comparable to the IP Internet. -Bill From owner-big-internet@munnari.oz.au Fri Jul 30 21:14:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08171; Fri, 30 Jul 1993 21:14:45 +1000 (from owner-big-internet) Return-Path: Message-Id: <9307301114.8171@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02256; Fri, 30 Jul 1993 18:17:30 +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 ; Fri, 30 Jul 1993 09:16:58 +0100 To: kasten@ftp.com Cc: big-internet@munnari.oz.au Subject: Re: IPDECIDE BOF minutes In-Reply-To: Your message of "Thu, 29 Jul 93 08:37:11 EDT." <9307291237.AA01698@ftp.com> Date: Fri, 30 Jul 93 09:16:58 +0100 From: Jon Crowcroft > > so i vote for two solutions. >What do you mean by this? If there are two, equal, primary internetworking >layer protocols, wouldn't this lead to splitting the network up into two >separate communities, with few points of contact between them (presuming >that only a relatively few systems are dual-stacked -- if everyone were >dual-stacked, then we are being just plain silly)? I put it wrong I do not believe that there is a "choice" per se. but i dont think it is a choice of "one or 'tother" - it is a point to state a multiprotocol evolutionary strategy... since we already have clnp, let us propose TUBA as they way CLNP nets gain internet application functionaility for hosts. just like we also say you can use x.400 above tcp, why not say you _can_ use clnp under tcp, but it isn't a whole new internet... since we have an IPv4 that is slowly expiring, let us suggest a path to a new internet protocol owned lock stock and barrel by the IETF, which includes flows and multicast and other goodies we need - let this be sip or pip or whatever greeat thing the smart people build in the usualy evolutionary way,m free of any arguments about any exisiting infrastructure (e.g. existing nsap allocation schemes, host protocol costs etc) jon From owner-big-internet@munnari.oz.au Sat Jul 31 00:42:49 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16088; Sat, 31 Jul 1993 00:43:00 +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 AA13246; Fri, 30 Jul 1993 23:29:48 +1000 (from kasten@ftp.com) Received: by ftp.com id AA03738; Fri, 30 Jul 93 09:27:04 -0400 Date: Fri, 30 Jul 93 09:27:04 -0400 Message-Id: <9307301327.AA03738@ftp.com> To: bill.simpson@um.cc.umich.edu From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jmh@anubis.network.com, atm@sun.com, Big-Internet@munnari.oz.au, iplpdn@ietf.cnri.reston.va.us, iesg@cnri.reston.va.us Bill, at al. History has shown that large, broadly focussed working groups tend to be less productive than do tightly focussed, highly specific working groups. I think that this working group will be an excellent idea. Its members can concentrate on their one, well defined, task and there will be a much higher probability of them producing the right thing in a reasonable time frame. > We never did see any *routing* work out of them. Since you were a > prominent member of that group, I don't see how making a new working > group will improve the performance. These sorts of comments are completely out of order here. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.oz.au Sat Jul 31 01:28:27 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17737; Sat, 31 Jul 1993 01:28: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 AA17730; Sat, 31 Jul 1993 01:28:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27187; Fri, 30 Jul 93 11:28:11 -0400 Date: Fri, 30 Jul 93 11:28:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307301528.AA27187@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, kasten@ftp.com Subject: Re: IPDECIDE BOF minutes Cc: big-internet@munnari.oz.au, iesg@cnri.reston.va.us, jnc@ginger.lcs.mit.edu let us suggest a path to a new internet protocol owned lock stock and barrel by the IETF, which includes flows and multicast and other goodies we need ... free of any arguments about any exisiting infrastructure (e.g. existing nsap allocation schemes, host protocol costs etc) I tried to sell the view (a long time ago, when I was new on the IESG) that one way to get rid of the stupid, pointless, idiotic "IP/CLNP" wars was to: - Recognize that i) IP had a limited lifetime, and ii) CLNP was not catching on in an widespread way, and - Agree to design a whole new protocol with all the nice features, and label it *both* IP-5 and CLNP-2. This had the advantages that a) as a designer, you start with a clean slate, with the benefit of 10+ years thinking about flows, etc, and b) it would get rid of a lot of the politics, since *nobody would 'win'*. Needless to say, nobody bought it. Noel PS: I've really gotten pretty damn sick of the colossal waste of time in arguments about "CLNP versus IP". If we can't find soon some reasonable path, I'm shortly going to suggest a pretty brutal solution. It may be nasty, painful, divisive and plain unfair, *but at least it will get rid of this stupid waste of time*. From owner-Big-Internet@munnari.oz.au Sat Jul 31 03:01:56 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21243; Sat, 31 Jul 1993 03:02:21 +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 AA21231; Sat, 31 Jul 1993 03:01:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28659; Fri, 30 Jul 93 13:01:39 -0400 Date: Fri, 30 Jul 93 13:01:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307301701.AA28659@ginger.lcs.mit.edu> To: bill.simpson@um.cc.umich.edu, jmh@anubis.network.com Subject: Routing Over Large Clouds Cc: atm@sun.com, big-internet@munnari.oz.au, iesg@cnri.reston.va.us, iplpdn@ietf.cnri.reston.va.us, jnc@ginger.lcs.mit.edu, rolc@network.com We never did see any *routing* work out of them. Since you were a prominent member of that group, I don't see how making a new working group will improve the performance. I agree with your assessment that the IPLPDN group never got done what the IESG had wanted it to do when it was created, but the blame for that lies in many places, including me (as I'll explain), and I think it's really unfair to beat up one individual member about it, even a vocal and influential one. If you wanted to beat people up, you should beat up the Chair (for allowing the group to get sidetracked), the Area Director (for not seeing that the Chair followed the charter), etc, etc on up the ladder, and me (see below). Now, in all fairness, all these people are volunteers, serving without compensation, with other calls on their time, etc, etc, etc, but they are some of the ones who are supposed to see that this doesn't happen. *All* the WG members themselves also have to bear some blame; this isn't kindergarden, and they are expected to help make things work. I would agree that IPLPDN has not handled the work assigned to them, but was diverted to simpler tasks outside their charter Here's where I catch some blame. I was serving as Internet AD during the period when this happened, and I was *supposed* to set up a number of WG's to do things like define "IP over ATM", "IP over Frame Relay", "IP over ISDN", etc. I didn't. It wasn't just obviously needed, I actually discussed it with the IESG, said I would do so, and talked to potential chairs. I just never followed through (for personal reasons having nothing to do with stuff inside the IETF). I was "derelict in my duty", to use the technical phrase, and any brickbats thrown in my direction for this will be deserved. The inevitable happened: "Nature abhors a vacuum". Without the correct WG's set up to do this in, people who needed it done drifted to IPLPDN and did it there. Should 17 different people have seen this, and stepped in? Yup. Did they try? Yes, actually. Did it do any good? No. creating several incompatible schemes for sending multi-protocol datagrams over LPDN. This just resulted in turf wars with other multi-protocol efforts. Let's not get into this, but there are lots of people out there who think bridging from one type of WAN technology to another is a Good Thing, and are trying to harmonize packet formats to make this easier. I think they are wrong, but there's no way to stop people trying it. Time will tell... I suspect that we will see more turf wars as the new group conflicts with the efforts of existing WGs, and with the IPng groups, which are also working on the broader routing questions. I suggest that we disband the IPLPDN group, and focus on building the desired routing features into the various IPng proposals. I'm less concerned with turf wars, and more with getting the darn problems solved. Tying them into IPng will just create an even *bigger* ball of politics and hassle, and slow down work on these technical problems. Yes, all the IPng groups will need to make sure their schemes handle these issues, but there's no more reason to put these things in IPng groups than there is to bust up, say, multicast work and move it all to IPng groups. The Right Thing *is* to dissolve IPLPDN, and set up two WG's: one each *specifically* for i) address resolution mechanisms on large WAN's (since we have current need for this, plus at least one IPng candidate with a very determined camp of shortish-fixed-length-internetwork-address advocates), and ii) routing mechanisms for large WAN's. The charters should *specifically prohibit* any work on stuff outside the charters, and the Chair's and AD's have to enforce these. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 31 04:35:13 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24874; Sat, 31 Jul 1993 04:35:32 +1000 (from owner-Big-Internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24868; Sat, 31 Jul 1993 04:35:13 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws13.merit.edu by vela.acs.oakland.edu with SMTP id AA09527 (5.65c+/IDA-1.4.4); Fri, 30 Jul 1993 14:34:54 -0400 Date: Fri, 30 Jul 93 11:16:54 EDT From: "William Allen Simpson" Message-Id: <919.bill.simpson@um.cc.umich.edu> To: rcallon@wellfleet.com (Ross Callon) Cc: big-internet@munnari.oz.au Reply-To: bsimpson@morningstar.com Subject: Re: IPDECIDE BOF minutes > I wish that the IETF was better at stealing the good ideas from > CLNP and feeding them into the other IPng proposals (I have been > *trying* to privately convince folks to do this). > And you have been successful. Before writing the first draft of the SIP system discovery document, I studied the RFC-995 ES-IS, IS-IS, etc. (I have since learned that RFC-995 isn't right, but that's not my fault.) Also, some of the SIP group has been closely watching the PIP and TPIX groups, and stealing the interesting features. One of the great parts of this IPng effort has been the interaction of ideas! Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Sat Jul 31 07:53:25 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02997; Sat, 31 Jul 1993 07:53:47 +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 AA25873; Sat, 31 Jul 1993 04:58:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29743; Fri, 30 Jul 93 14:58:26 -0400 Date: Fri, 30 Jul 93 14:58:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9307301858.AA29743@ginger.lcs.mit.edu> To: Tim.Dixon@newcastle.ac.uk, big-internet@munnari.oz.au Subject: Re: Variable length addresses Cc: jnc@ginger.lcs.mit.edu My biggest problem with the "fixed-length-address" proposals is that they assume, unrealistically in my view, that business customers with private networks ... will be prepared to pay the additional administrative costs of officially assigning IPng addresses to their machines I'd mostly been thinking of embedding physical addresses such as E.164 to avoid the WAN address resolution hassle, but you've pointed out another good reason. Robert Moskowitz, from Chrysler, just made effectively the same point in a message to the IETF: But we have a series of problems with TCP/IP. ... What is not manageable are the following: Static System Addressing ... We constantly have users 'sneeking' systems in, copying software (instead of installing), and plugging in. Then we have to go in and clean up the mess. ... We have constant user moves. Some ... can cross the 'line of death'. This is the line drawn on the office diagram of which desks are connected to which wiring closet, thus on which subnet... [Fixing this] is VERY important for the corporate user. In other words, autoconfiguration. It's true, we could use an Appletalk-like scheme of auto-allocation, but we've heard from people that this has lots of problems. If we could simply embed 802 addresses directly, autoconfiguration of hosts addresses is trivial; it's the wire address (which you get from any router), plus the 802 address... You still have to update the DNS, but there's no way to avoid that. Noel there is > to bust up, say, multicast work and move it all to IPng groups. > No, but since it may require fundamental paradigm shifts, I think this should be delayed until we have picked IPng, and then all of the various existing IETF WGs would work on the problems in that context, the same as with multicast. The one positive thing that I note in Stev Knowles' message is that the WG will be in the Routing rather than the Internet Area. What the difference is, I don't know, but hopefully that will be more focused. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Sat Jul 31 12:05:17 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10789; Sat, 31 Jul 1993 12:05:26 +1000 (from owner-big-internet) Return-Path: Received: from vela.acs.oakland.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02917; Sat, 31 Jul 1993 07:51:13 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.ws13.merit.edu by vela.acs.oakland.edu with SMTP id AA23838 (5.65c+/IDA-1.4.4); Fri, 30 Jul 1993 17:50:50 -0400 Date: Fri, 30 Jul 93 15:43:16 EDT From: "William Allen Simpson" Message-Id: <923.bill.simpson@um.cc.umich.edu> To: stev@ftp.com (stev knowles) Cc: Big-Internet@munnari.oz.au, iesg@cnri.reston.va.us Reply-To: bsimpson@morningstar.com Subject: Routing versus Internet > i have already suggested to the SIP group that any routing work it > does beyond just porting existing routing protocols, should be > carried out where the routing area (remember bob?) can be sure to > provide them with the guideance that they surely will need, since > routing is canonically a messy subject. (least, i always feel messy > when i leave a routing discussion.) i woudl also imagine that most > Some of us don't pay much attention to which Area a WG is under. Perhaps you could enlighten us as to the difference between the Routing and Internet areas. Why would IPng efforts be classed as "internet" rather than "routing", when the fundamental problem to be solved is a routing problem? If we don't have a routing problem, why do we need IPng? Are you advocating that each IPng effort have more than one WG, split among the Areas? Why would link layer WGs, such as PPP and IPLPDN, be in the same Area as IPng WGs? Now, I will recognize that this is all your informed opinion. Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Sat Jul 31 12:55:07 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12985; Sat, 31 Jul 1993 12:55:51 +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 AA06399; Sat, 31 Jul 1993 09:33:46 +1000 (from wollman@uvm-gen.EMBA.UVM.EDU) Received: by sadye.emba.uvm.edu id AA10843 (5.65/1.23); Fri, 30 Jul 93 19:33:19 -0400 Date: Fri, 30 Jul 93 19:33:19 -0400 From: wollman@uvm-gen.EMBA.UVM.EDU Message-Id: <9307302333.AA10843@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Tim.Dixon@newcastle.ac.uk, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: Variable length addresses In-Reply-To: <9307301858.AA29743@ginger.lcs.mit.edu> References: <9307301858.AA29743@ginger.lcs.mit.edu> < If we could simply embed 802 addresses directly, autoconfiguration > of hosts addresses is trivial; it's the wire address (which you get > from any router), plus the 802 address... You still have to update > the DNS, but there's no way to avoid that. No, you don't have to update the DNS (unless you really want to). As I pointed out on the Pip list a while ago, an alternative model would be to tell the host its DNS name. It then uses a temporary address and ID (perhaps concocted out of the 802 numbers it has lying around) to find out what its information is supposed to be. This strikes me as keeping the variability where it's easier to hide. -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 Jul 31 15:55:50 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18822; Sat, 31 Jul 1993 15:55:55 +1000 (from owner-big-internet) Return-Path: Received: from Seagull.RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16531; Sat, 31 Jul 1993 14:46:02 +1000 (from rawn@Seagull.RTD.COM) Received: by Seagull.RTD.COM (4.1/SMI-4.1) id AA15834; Fri, 30 Jul 93 21:45:08 MST From: rawn@Seagull.RTD.COM (Rawn Shah) Message-Id: <9307310445.AA15834@Seagull.RTD.COM> Subject: Re: Variable length addresses To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 30 Jul 93 21:45:08 MST Cc: big-internet@munnari.oz.au In-Reply-To: <9307301858.AA29743@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jul 30, 93 2:58 pm X-Mailer: ELM [version 2.3 PL11] : : In other words, autoconfiguration. It's true, we could use an Appletalk-like : scheme of auto-allocation, but we've heard from people that this has lots of : problems. If we could simply embed 802 addresses directly, autoconfiguration : of hosts addresses is trivial; it's the wire address (which you get from any : router), plus the 802 address... You still have to update the DNS, but there's : no way to avoid that. I've been following the variable length address problem in the background and this little bit about Appletalk caught my attention. Autoconfiguration in Appletalk must have been a mistake. I figure they didn't think that address ranges could get very large. Allocation of addresses in Appletalk are by trial and error through broadcasts. This will NOT work on a larger scale. There would be so much traffic from hosts simply coming up and down that it would eat a major portion of the bandwidth. Its nice in theory but isn't scalable at all. Now MAC addresses sound plausible. With the large address length of CLNP, people won't be bothered to remember the number address like some do for IP addresses. It would simply be too confusing. Since the number involved is not really relevant the problem now lies in the address resolution entries side. How would you propagate a change to say a DNS server that you've just replaced your system board/Ethernet board? Assuming DNS can propagate it outside, or claim its area of service/domain, the problem now becomes one of a local area. People changing Ethernet or other net HW boards need to inform the DNS that the name for the physical host now maps to a different CLNP address. If you assume that hardware changes won't happen often (which you cannot absolutely), then this process becomes rare/trivial. However with the current ability to allow many Ethernet cards to use an alternate 802.3 address as opposed to the hard-wired one, this step falls apart and causes chaos. I guess a similar argument can be brought out that: So? You can modify the IP address of a machine as well? I have a question: If the 802 address is used, would we still require something like ARP? : : Noel : -- Rawn Shah RTD Systems & Networking, Inc. System Consultant 2601 N Campbell Ste 202B, Tucson AZ 85719 rawn@rtd.com (602) 318-0696 FAX: (602) 318-0695 ------------------------------------------------------------------------------- From owner-Big-Internet@munnari.oz.au Sat Jul 31 21:56:45 1993 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00499; Sat, 31 Jul 1993 21:57:02 +1000 (from owner-Big-Internet) Return-Path: Received: from concorde.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00491; Sat, 31 Jul 1993 21:56:45 +1000 (from dupont@givry.inria.fr) Received: from givry.inria.fr by concorde.inria.fr; Sat, 31 Jul 1993 13:56:32 +0200 Received: by givry.inria.fr; Sat, 31 Jul 1993 13:56:32 +0200 Message-Id: <199307311156.AA14388@givry.inria.fr> From: Francis Dupont To: big-internet@munnari.oz.au Subject: forward congestion bit Date: Sat, 31 Jul 1993 13:56:30 +0200 Sender: Francis.Dupont@inria.fr X-Charset: ASCII X-Char-Esc: 29 In the Quality of Service option, CLNP (ISO IS 8473) has a forward "congestion experienced" bit (aka DEC bit). I'd like to know: - is it a good thing (should it be recommended for TUBA) ? - how to use it for TCP (reduce peer window) ? Regards Francis.Dupont@inria.fr