Subject: [rrg] Name Based Sockets alternative critique

From: Robin Whittle <[email-masked]>
Date: Sat, 30 Jan 2010 01:30:20 +1100

Here is a (500 word) alternative to Javier Ubillos' critique of Name
Based Sockets:

http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-15.2

It has some things in common, but much of it is different.  For
instance, it is important to note that NBS is only practical for IPv6
and that like most or all other Core-Edge Elimination architectures,
there must be extra data transferred between any two communicating
hosts, and typically extra delays due to the need for lookups
involving a global query server system: DNS.

I have attached a Word file of the alternative critique.

I am corresponding with Christian to clarify my understanding of some
parts of NBS, in particular:

   Should the peer (page 7) do a lookup on the FQDN it gets from the
   host and verify that the source address in the initial packet is
   one of those returned by DNS, before sending the second packet
   back, with the host's FQDN and this peer's FQDN to complete the
   Initial Name Exchange?

   How is this exchange secured against the reply being spoofed by
   an attacker?  (Maybe it doesn't have to be.)

   How are the Initial Address Exchange and subsequent Address
   Exchanges secured against spoofed packets?

   In these Address Exchanges, should one host accept IP addresses
   from the other host if these do not appear in the list of
   IP addresses returned by a DNS lookup of the other host's name?

   How does NBS perform the equivalent of "round-robin DNS" - where
   a FQDN DNS lookup returns multiple IP addresses, each one being
   for a separate host?  Initially I thought that the FQDN played
   the role of both "Text name" and "Identifier", with the role of
   "Locator" being played by one or more IP addresses.  However, to
   do this load-distributing "round-robin DNS", NBS hosts must
   distinguish between other hosts not just by their FQDN, but the
   combination of a single FQDN and one or more IP addresses.

The following critique doesn't depend on the answers to these
questions - except perhaps the last.  I may update it in the next few
days.  I just want to get this alternative critique out to the list
because Javier's critique doesn't include all the points which I
think are important.

  - Robin

The following is based on: (PDF file created 2009-12-15):

 Simplifying Internet Applications Development With A Name-Based
 Sockets Interface

 Christian Vogt    preliminary  paper version

 http://christianvogt.mailup.net/pub/vogt-2009-name-based-sockets.pdf
 (PDF file created 2009-12-15)

Alternative critique
--------------------

Named Based Sockets (NBS) is a Core-Edge Elimination (CEE)
architecture intended to provide portability, multihoming, TE and
mobility for end-user networks of all sizes in a highly scalable
manner.  With ubiquitous NBS adoption there would be little or no
need for end users to use PI (edge) space.

NBS cannot be introduced for IPv4.  It could be introduced without
disruption to IPv6, using a Destination Options extension header.

An NBS-aware host - with an NBS stack and NBS-aware applications -
does not need PI space to provide portability, multihoming with
session continuity, TE or mobility for all communications with other
NBS-aware hosts, because these hosts establish and maintain their
communication sessions by way of their FQDNs.  The NBS stack handles
how these hosts use their one or more IP addresses - which may change
at any time.

As with all other CEE architectures, host stacks must be upgraded to
implement NBS.  As with most or all other CEE architectures, host
applications must be modified to use the NBS API - which uses only
FQDNs to specify the host with which communication sessions are
initiating or accepted.  For some applications, the changes would be
relatively minor - if their protocols are easy to adapt to NBS.
Other applications may only be able to adopt NBS by substantially
changing the way they operate.

As with other CEE architectures, the benefits of portability,
multihoming, inbound TE and mobility only apply to communication
sessions conducted with other hosts whose stacks and applications
have been upgraded to be NBS-aware.  This would make it difficult or
more likely impossible to achieve the wide-enough adoption necessary
for substantial routing scaling benefits - or substantial benefits to
the adopters.

Ubiquitous adoption of NBS would involve every host in greater
routing and addressing responsibilities.  These include DNS lookups
before responding to a request to open a session, in order to check
that source address of the request is one which is returned in a DNS
lookup of the FQDN supplied in the request.  Pairs of potentially
long (<=253 character) FQDNs are typically sent for one or more
initial packets in both directions.  Following that - and at any time
during the session - one or more IPv6 addresses are also exchanged.

Arguments against requiring all hosts to do this concern delays due
to the typically global nature of the DNS lookups, and the extra
delays and reliability concerns which arise from hosts being on slow,
long-latency and potentially unreliable wireless links.

In NBS, the role of Locator is performed by IPv6 addresses.  It is
not clear how the roles of text name and Identifier are performed.
If the FQDN performs both roles, then it will not be possible to do
the equivalent of "round-robin DNS".  If this is possible, then the
text name role is performed by the FQDN, and the Identifier role must
be performed by an as-yet unspecified combination of FQDN and one or
more IP addresses - which is more complex than in other CEE
architectures.

---

From: Lixia Zhang <[email-masked]>
Date: Fri, 29 Jan 2010 09:17:34 -0800

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 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:

- 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.

- 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.

- 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). So I  
see name-based socket can be a long term direction to look into, even  
though it does not directly address routing scalability.

Lixia

On Jan 29, 2010, at 6:30 AM, Robin Whittle wrote:

> <NBS-draft-critique-00- 
> RW.doc>_______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: Robin Whittle <[email-masked]>
Date: Sat, 30 Jan 2010 19:34:00 +1100

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.

> 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.

> 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!

> 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.

> 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.

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 30 Jan 2010 21:07:42 -0800

Hi Robin,

I really appreciate you spending effort to make a short version of all  
your long msgs!
It makes commenting a lot easier.

>                     single 500 word critique.

The submission of critique is roughly 500 words, but in writing the  
report, the most important thing is to collect and clarify all the  
issues about a proposal in one place. For different views, lets first  
try to resolve them; in case an agreement is not reached, then  
different views should all be listed.

>                     and hosts without any FQDN in the DNS.

I do not mean to argue for NBS, but NAT traversal seems to me an  
entirely separate issue.

Lixia