Short version: Multiple critiques should be included in the RRG Report, rather than trying to jam too many and sometimes incompatible, concerns into a single 500 word critique.
Response to Lixia's comments Name Based Sockets. NBS can't work behind NAT. More questions and concerns about NBS, regarding private network space, hosts needing multiple FQDNs, and hosts without any FQDN in the DNS. Comments on Javier's critique. More concerns about Name Based Sockets. Hi Lixia, Before responding to your message, here are some other concerns about NBS which I just thought of. I have written to Christian about them in greater detail. NBS can't work, except in the local network, if the host's IP addresses are behind NAT. Hopefully NAT won't be used much with IPv6, but this can't be assumed. An NBS-aware host first needs to check if it has an FQDN in the global DNS. If it is behind NAT, it won't have this. If it is not behind NAT, and doesn't have a valid FQDN in the global DNS, then it can't function as an NBS-aware host. So all applications need to interoperate with other hosts, including NBS-aware hosts with FQDNs in the DNS - as if it was a conventional host. What if the one host, such as a server running multiple websites, has multiple FQDNs? Each application would need to behave as if each FQDN was really a separate "host", when in reality multiple such "hosts" exist on the one server. If so, then what is the "Identity of a host" in NBS? Can one physical host have multiple such Identities? If so, then when an application listens for packets which could open an NBS session, it needs to be able to accept opening packets which are intended to open a session with the host identified by any one of its FQDNs - or perhaps by only one or a subset of the FQDNs this server is using. I am still unclear how NBS would implement "round-robin DNS" where, to the outside world, one FQDN is actually implemented as multiple hosts. Again, what does "an NBS host" really mean - and how do the NBS stack and applications identify hosts, if not by a globally unique FQDN which can only apply to one physical host at any one time? How does NBS handle a situation where hosts have one or more private IP addresses? A host could have: 0, 1 or more global unicast IP addresses. 0, 1 or more private addresses, perhaps on one or more private networks. I won't attempt to list the combinations of possibilities, but two hosts might have one or more private addresses on the same private address space, and so should probably communicate with those preferentially. But they may still be able to use the global unicast address too. They can't communicate from a global unicast address to a private address, so it looks very complex to handle all the possibilities. How could this work if it was desired to keep the private addresses from being known to the outside world? The global DNS would need to return all the IP addresses, including the private ones. Otherwise, the local DNS of each host with any private IP addresses would need to return the purely global unicast IP addresses from the global DNS, plus local IP addresses of the host whose FQDN is being looked up, if that host was also on the same local address space. One potential benefit of IPv6 is to allow a host to change its global unicast address, or at least the least significant bits of it, frequently - to achieve a measure of privacy. If there were a bunch of desktop machines all browsing websites, and they frequently changed their address like this, then they can to a considerable extent, in principle, frustrate the ability of anyone on the outside to correlate the web-browsing actions with specific desktop machines and therefore individual users. Assuming each desktop machine has a stable, single, FQDN, NBS makes this impossible, since those who run websites always get that FQDN every time one of these NBS-aware hosts opens a session with a server. So, to implement this kind of privacy, each physical host needs to use an endless, pseudo-random, stream of FQDNs, as well as change its IP addresses along the same lines. Another difficulty is that FQDNs are bulky objects with lengths variable up to 253 characters. This is more difficult to store in memory - and it is *much* more difficult to use in protocols between machines, than an IP address which has a fixed size. NBS has a hard time already sending potentially two FQDNs in a Destination Options header, considering packet length limits. Application program development would be significantly complicated by the need, at any time, to piggyback IP addresses onto packets using a Destination Options extension header, at various times during the session. This complicates the packetization layer of the application. The Initial Address Exchange and any subsequent Address Exchanges would reduce the capacity of the packets - yet these are initiated by the stack. So the application would need to frequently enquire from the stack how long it could make the packets it is assembling for transmission. I am not sure how I can mention these in an updated version of my 500 word critique. You wrote: > top posting: Robin, I just sent you and Javier my comment on the prev > critique (since we three agreed to collaborate on this), without > checking RRG mailing first and hence missed this msg before sending. I have changed my mind about collaborating on a critique of Name Based Sockets. Now I have read it and written a draft critique of my own: http://www.ietf.org/mail-archive/web/rrg/current/msg05832.html I can't see how Javier and I could be happy with trying to combine our concerns into a single 500 word document. As I wrote in my previous message, I think the RRG Report should contain multiple critiques if people are motivated to contribute them. I can't see how space is at such a premium that this can't be done. It would be far easier and better to include multiple critiques than for two or three people to try to cram their concerns into a single short document we could all be happy with. > I believe your critique captured some missing issues from the prev one > (in particular the need for majority of hosts taking adoption to bring > up benefits). I also think a few points deserve further clarification: This applies to all the CEE architectures. As I wrote in: http://www.ietf.org/mail-archive/web/rrg/current/msg05769.html The relationship between adoption levels and scalable routing benefits are: (ASCII art requires fixed width fonts.) Scalable routing benefits ------------------------- Core-Edge Separation (CES) Core-Edge Elimination (CEE) ^ ^ B | * B | * e | ** e | * n | *** n | * e | **** e | * f | ***** f | * i | ****** i | * t | ******* t | * | ******** | * |********* |********* 0---------> 0---------> Effort ~= Effort ~= level of adoption level of adoption If we assume that portability, multihoming and TE for only 90% or 99% of communications is of only marginal value to end-user networks, compared to the value of it working for 100% or communications (or very close to 100%, like 99.999%), then here are the graphs for the direct benefits for end-user networks adopting the new system, again as a function of how many other networks adopt it: Benefits to each adopting network --------------------------------- Core-Edge Separation (CES) Core-Edge Elimination (CEE) ^ ^ B |********* B | * e |********* e | * n |********* n | * e |********* e | * f |********* f | * i |********* i | * t |********* t | * |********* | * |********* |********* 0---------> 0---------> Effort ~= Effort ~= level of adoption level of adoption This is because a good CES architecture provides portability, multihoming and TE for all communications, no matter how few or how many other networks have adopted it. Maybe the above assumption about benefits only occurring once a very high proportion of communications are improved is a little harsh. If we assume that the total benefit for adopting CEE scales more linearly - for instance if the total benefit for the network of 80% of their communications being enhanced is actually 40% of the value of 100% of it being enhanced, then there is a somewhat more linear relationship between benefits for each adopting network and the total rate of adoption amongst all networks: Core-Edge Elimination (CEE) ^ B | * e | * n | ** e | ** f | ** i | *** t | *** | **** |********* 0---------> Effort ~= level of adoption But this still leads to absence of compelling motives for any network to adopt CEE until most other networks have adopted it. It is possible to imagine a special subset of networks, who only communicate with each other. If they all began adopting the CEE scheme - meaning they were able to get all their applications modified (which seems unlikely), then the benefit curve might approach a linear relationship with the proportion of adopters in this special group. However, outside the Military, I can't think of such a group. Nor can I imagine how they could have the resources to convince the programmers all over the world who wrote the mainstream applications they presumably use to rewrite the apps for the CEE architecture. (They would need modified stacks for all their hosts too.) Even if such a group existed, it would not be relevant to the general level of benefits to adoptors as a function of level of adoption, because the great majority of end-user networks are engaged in communications with a broad cross-section of all other networks. My critique states this, and Javier's doesn't. While maybe we could squeeze this into Javier's text, I think Javier and I should both independently contribute what we are happy to write, rather than trying to thrash out something together - especially within a 500 word limit. Below, I will comment on Javier's critique. Folks who are getting critiqued-out should avert their eyes! > - DNS lookup: my group has done lots work on DNS performance over the > years. The results show that DNS can be, and in many places has been, > engineered to provide fast responses (thanks largely to effective DNS > caching, here I refer to caching of infrastructure RRs, NS and glue > RRs). Thus look up delay should not be a major concern. This is your view, and I think you should express it in your own critique. It is contrary to my view. All these CEE architectures involve extra lookups of at least one global mapping system, such as DNS, before one host can be sure that sending packets with a particular Locator address will actually deliver the packet to a host with the Identity it wants the packet delivered to. Furthermore, the hosts typically have to exchange names, Identifiers and/or Locators, and acknowledge their receipt and acceptance, before they can do any useful work. I argue against this in general, because it inevitably slows down the commencement of actual application-level communication compared to the current arrangement. If the lookups were instantaneous and 100% reliable (no lost packets) and if the delay time between the hosts was insignificant, and if all these extra communications were 100% immune from packet loss, then I would have fewer objections. But the delays and losses inherent in any DNS or similar global query server system, and the delays which exist between hosts which are in different continents means my concerns apply to the best-connected hosts with perfectly strong CPU resources. Being on a wireless link, running from batteries and/or being on a long latency satellite link makes these concerns all the more acute. The first lookup by host A always needs to be done. In some cases today, there is already a DNS lookup, so this is not always any worse then today. When host B gets a packet from host A, it also needs to do a lookup and get the results before it can respond to host A - if, as is typically the case, B wants to ensure it really is A which its response packet will go to. So there would typically be at least one extra lookup, and frequently two. Extra data has to flow back and forth between hosts for names, Identifiers and Locators, and ACKs for these. These exchanges typically need to be protected by nonces too, and require retries in the absence of reception of ACKs. FQDNs are potentially very long. None of this stuff is needed today - other than perhaps an initial DNS lookup of B's FQDN by A - because today's arrangement makes the IP address perform the role of Identifier and Locator. This leads to difficulties for the routing system, but it is good for hosts and applications, since when you send a packet to some IP address, you know the packet (unless it is dropped) will get to the host with the Identity which is absolutely and directly linked to that IP address. There is no need to fuss around looking up Locators and checking they really are valid for this Identifier, since the IP address functions as both simultaneously. >From the point of view of keeping the routing system simple and scalable, as Tony says, a CEE architecture is "doing it right" to use separate objects, in separate namespaces, for Identifier and Locator. But I think the hosts are more important, and are operating under greater constraints (especially hand-held devices on 3G wireless links) than the routing system. Anyway, the routing system exists only to support hosts. I think the current arrangement where the IP address performs both the Identifier and the Locator role (from the point of view of all hosts) is "doing it right". I think it is better to upgrade parts of the routing system with a CES architecture to retain the current arrangement, keeping life easy and fast for hosts, than to upgrade all host stacks and applications, and to permanently slow down the establishment of all communications, by adopting a CEE architecture. > - name-based socket removes application/host dependency on IP addresses, > not necessarily PI addresses. Network operations often have preference > of using PI addresses (network management, no renumbering, etc), > independent from what host socket is based on. I wouldn't express it this way. NBS hosts need IP addresses just as much as hosts do today. I think Javier's expression of this: Name-based sockets contribution to the routing scalability problem is to decrease the reliance on PI addresses, allowing a greater use of PA addresses, and thus a less fragmented routing table. is excellent. > - in the loc/ID separation context, name-based socket has an advantage > over random identifiers in that a DNS name can be used for look up, and > the latter can't or difficult to do (if ID lookup is needed). I think by "random identifiers" you are referring to the SPI addresses in Ivip or the EID addresses in LISP which the ITR requests mapping for. I don't think these are any more "random" than FQDNs. Each such SPI or EID address is within some micronet (Ivip) or EID prefix (LISP), and each of these is within a Mapped Address Block (Ivip DFZ-advertised prefix - there is no equivalent LISP term). Its just as structured as DNS, and as with DNS, the final control of the mapping is devolved to end-user networks all over the world. With DNS, there could be multiple depths of domains to traverse - so DNS is arguably messier and more complex than the mapping systems of either Ivip or LISP. So I don't see that the DNS lookup of NBS has any inherent advantage over the mapping systems of Ivip or LISP, except for the fact that NBS can use the existing DNS structure - which would itself need to cope with the extra load. (According to recent messages from Noel Chiappa, the LISP team will be replacing the ALT system with a DNS-based mapping system.) > So I see > name-based socket can be a long term direction to look into, even though > it does not directly address routing scalability. In the last phrase, I think you are referring to the fact that NBS can't bring substantial routing scaling benefits until it is nearly 100% adopted - which I agree with. I wouldn't express this as: "NBS does not directly address routing scalability", because NBS certainly does have the potential to achieve routing scalability, as do some or all the other CEE architectures. NBS can only work for IPv6, and it could achieve excellent routing scalability when it is adopted by pretty much all hosts and applications. I think it would be best for your critique to be separate from the one I write. Perhaps you and Javier may be able to agree on a single text which expresses both your concerns. Below are my comments on Javier's critique. - Robin !!!!! Folks at risk of critique-itis should proceed no further !!!!! Comments on Javier's critique, as in draft-irtf-rrg-recommendation-04 - originally posted to the RRG list on 2010-01-20. Name-based sockets contribution to the routing scalability problem is to decrease the reliance on PI addresses, allowing a greater use of PA addresses, and thus a less fragmented routing table. It provides end hosts with an API which makes the applications address-agnostic. I entirely agree - except that it must be mentioned that NBS is only practical for IPv6. So it can only solve the only routing scaling problem we have today if most current IPv4 users are able to migrate to IPv6 fully, and so not rely on having IPv4 addresses. There's no way this will occur in the foreseeable future. The name abstraction allows the hosts to use any type of locator, independent of format or provider. OK, provided it is recognised that in NBS, a Locator an IPv6 address. This is a re-iteration of the fact that NBS hosts can have portability (of their FQDNs), multihoming and inbound TE (with session continuity, since sessions are defined by and bound to their FQDNs) no matter whether the IP addresses they are using are PI or PA, and no matter which one or more ISPs they are using. This increases the motivation and usability of PA addresses. Some applications, in particular bootstrapping applications, may still require hard coded IP addresses, and as such will still motivate the use of PI addresses. Yes - most applications, in principle, can be written to open sessions with other hosts entirely in terms of the FQDN of the other hosts. Some, such as diagnostic utilities (ping, traceroute etc.) and others such as DNS lookup tools, will require at least some direct access to hosts specified by their IP address. Therefore, some hosts must be on IP addresses which remain stable, at least in the case of DNS lookups. I think, in principle, that only the root servers need to be on fixed addresses, which is such a small subset that "PI" is probably not the best term for these handful of IP addresses. Deployment: The main incentives and drivers are geared towards the transition of applications to the name-based sockets. I think there are insufficient compelling motivating factors for the groups of people who need to take action: 1 - Those who write IP stacks and their APIs. 2 - Those who write new and existing application programs. 3 - End-user networks which need portability, multihoming, TE and/or mobility. 4 - End-user networks which don't need these things, and are getting by find on PA addresses. This involves the great majority of hosts - those at homes and in SOHO environments which currently get a single IPv4 address and use NAT. These end-users connect by DSL, fibre, HFC cable or fixed wireless. Also, many mobile devices using 3G or WiFi get a PA address or an address behind NAT. In all cases, these end-users don't need PI space, because they don't need portability, multihoming or TE. Assuming these hosts are somehow running on IPv6 instead, and not at all on IPv6, they probably wouldn't be using NAT. Nonetheless, their service is plenty reliable and fast enough, so they don't need multihoming, TE or portability. Why should any of group 4 make any effort to adopt new stacks or applications? The only benefit they would have is that when communicating with an NBS-aware host, that when that host undergoes a multihoming failure recovery (one ISP or ISP link dies and another is used instead, with its different IP addresses) that they will be able to continue their sessions. This is a slight benefit in a very rarely occurring circumstance. Adoption by applications will be driven by benefits in terms of reduced application development cost. Legacy applications are expected to migrate to the new API in a slower pace, as the name-based sockets are backwards compatible, this can happen in an per-host fashion. Also, not all applications can be ported to a FQDN dependent infrastructure, e.g. DNS functions. This hurdle is manageable, and may not be a definite obstacle for the transition of a whole domain, but it needs to be taken into account when striving for mobility/multi-homing of an entire site. The transition of functions on individual hosts may be trivial, either through upgrades/changes to the OS or as linked libraries. This can still happen incrementally and disjoint, as compatibility is not affected by the use of name-based sockets. For anything to happen with NBS (or any other CEE architecture) there needs to be significant investment taken by groups 1 and 2 in particular - and for this to enable a hopefully growing subset of group 3 to adopt the new architecture. Later, since group 4 have almost no motivation to do anything, I guess the stacks and apps would have to percolate through to the group 4 hosts - which means they need to work reliably and not involve any extra fuss or expense. Group 1 could add a significant bunch of code to their stacks, and that is the end of what they need to do. The new code wouldn't significantly disrupt their existing code. Group 2 faces some very difficult challenges. Assuming they are to upgrade an existing application, they must to: a - Alter the way their code works to use NBS when the stack supports it, but still operate properly when the stack does not. Likewise, only use NBS when the host has global unicast addresses (is not behind NAT) and when it has a valid FQDN in the DNS. b - When the stack supports NBS, the upgraded application needs to attempt to use NBS with all hosts it communicates with - which may require a radical revision of the protocols and logic of the application. c - When the stack supports NBS, the other host may not - so the application has to work when the one or more hosts it is communicating with are any mix of NBS-aware and not. d - Cope with however NBS handles the common situation of a single physical host, such as a web server, which has multiple FQDNs. (Or a mailserver with one FQDN being implemented on the same server, with the same IP addresses, in which a web server and nameserver are also implemented - all of which have different and perhaps completely unrelated FQDNs.) e - Make the new version of the app backwards compatible with older versions. f - Do all the above for multiple operating systems, if the app runs on different OSes. g - Cope with all the combinations of this host and the others which are being communicated with having mixes of global unicast addresses and private addresses - the latter of which might be usable if the two hosts are on the same local network. Global unicast addresses on one host can't be used for communication involving the private addresses of the other host. I can't imagine how any CEE could get past this barrier. So the above critique applies equally to: v6 GLI-Split v4 hIPv4 v6 ILNP v6 Name Based Sockets v4 v6 Name Overlay Service v6 RANGI The huge effort required by application developers to adapt their code not just to NBS, but optionally to NBS when its host stack and the presence of the FQDN - and likewise in the the other host - supports it. It is probably possible for the group 1 effort (upgrade the stacks of all major OSes - and firmware-based devices, such as large routers, DSL and wireless routers etc.) to contribute open-source or public domain code to various open source kernels, and likewise let commercial stacks use the same code - that could be relatively simple and contained. However, why would any application developer do such a major rework of their application? Some apps may already work entirely from FQDNs. These would be easy to upgrade. However, many or probably most would have internal logic and external protocols which rely on IP addresses. Rewriting an app to work entirely from FQDNs would be extremely challenging. Rewriting it to do so reliably, when only a subset of other hosts are NBS-aware, sounds like a nightmare to me. The quoted text begins with: Adoption by applications will be driven by benefits in terms of reduced application development cost. The only way I could imagine NBS reducing development costs would be if an application was most easily implemented by using FQDNs to control which hosts it communicated with - and if this as a NEW application. The development would be only very slightly simplified, since at present, without NBS, the procedure would be: Look up FQDN in the DNS. If there is a valid result, choose one of the IP addresses. Open a socket with that IP address - and if this doesn't work retry with any other IP addresses from the DNS reply. This is simplified to: Open the socket with the FQDN. This is assuming the NBS stack copes with non-NBS hosts. If the application has to worry about such things - then writing for NBS will always be more expensive than without it. This would only involve a trivial decrease in development costs, which would surely be outweighed by the effort involved in understanding the NBS API and all its modes of operation, according to whether or not this host is capable of doing NBS (is on global unicast space and has a FQDN in the DNS) and to what extent the other host is capable of supporting NBS. To convert an existing application to be NBS-aware could be extremely expensive, as noted above. Many apps use IP addresses directly within themselves and in their protocols. The protocols would need to be changed and would require more bytes due to the variable and potentially long length of FQDNs. Each instance of the application may be required to speak either the old or the new protocol with other hosts, depending on whether it was running on a host with an NBS-aware stack and to what extent the stack and application programs in each other host was NBS-aware. Also, the NBS code needs to cope with NBS-aware hosts which do and don't have their own entry in the DNS. NBS can only work when both hosts are on global unicast addresses - it can't handle NAT. So there needs to be special provisions for an NBS-aware host which is behind NAT (and doesn't necessarily know it) - these can't be supported. I really doubt that NBS or any other CEE would be associated with a reduction in the cost of developing applications Edge-networks: The name-based sockets rely on the transition of individual applications, the name-based sockets are backwards compatible, hence it does not require bilateral upgrades. This does allow each host to migrate its applications independently. Name-based sockets may make an individual client agnostic to the networking medium, be it PA/PI IP-addresses or in a the future an entirely different networking medium. In broad principle, NBS could be used with another system of Locators than IPv6 addresses. But I think it would be a nightmare to try to introduce NBS to support any kind of dual-stack arrangement. As you can read from my concerns above, it is already going to be very complex to make an application NBS-aware. If every host and every application program on it was known to be fully NBS aware, so there was no need to work in the non-NBS mode, then, in principle, it would be easy to take an NBS application and run it on a stack which used a completely different kind of Locator. But to do this dual stack, where some Locators are of one type of IP address and some of another, with no communication between the two types, would require much greater complications in the NBS protocols, stack and applications. However, an entire edge-network, with internal and external services will not be able to make a complete transition in the near future. Hence, even if a substantial fraction of the hosts in an edge-network use name-based sockets, PI addresses may still be required by the edge-network. Yes, as with other CEE architectures - only when every other network has adopted it, are there significant benefits to the adopters - and only then can they relinquish their PI space and use PA space instead. In short, new services may be implemented using name-based sockets, old services may be ported. Name-based sockets provide an increased motivation to move to PA-addresses as actual provider independence relies less and less on PI-addressing. The motivation would only occur after all, or almost all, other hosts on the Internet have their stacks and all their applications upgraded to the NBS, or whatever other CEE, architecture. _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg