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
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
