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:
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.
<NBS-draft-critique-00-
RW.doc>_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
