[rrg] Objections to burdening hosts with more RA responsibilities

[Robin Whittle <[e-mail]>]

Short version:  Even if it were easy to change host stack and
                application software (and I think it is very
                difficult to change every host, except over decades)
                here is an argument directly against what I think
                some RRG people prefer.

                There is an ideal of "dumb network - smart hosts"
                which has served the Internet well, at least in
                comparison to the telephone network.

                However, extending this principle to *require* that
                sophisticated scalable, routing and addressing
                functions be performed in hosts is a bad idea.

                Its fine to make such functions optionally
                implemented in hosts, but burdening *all* end-user
                hosts with Routing and Addressing responsibilities,
                beyond the current DNS lookup and IP address stuff,
                is undesirable since it causes major problems for
                hosts which either must be simple and minimal
                and/or which connect via slow, unreliable and/or
                expensive links.

                Even where the hosts are well-connected and
                have plenty of CPU resources, these new schemes
                typically involve complex interchanges of packets
                so two hosts can identify and authenticate each
                other's application level identity or address or
                whatever.

                At present, a packet can be sent directly and incur
                only the delay inherent in the physical network path.
                With the proposed protocols in which the end-user
                host must perform new routing and addressing
                functions, there typically needs to be multiple
                packets, including to and from each host, before
                user-level communications can occur. So the inherent
                physical delays are multiplied by 2 or more.

                Such proposals, while conceptually elegant, would
                slow down the establishment of user communications
                in general, and be unworkably expensive, slow and
                less reliable if one or both hosts relies on a slow,
                unreliable and/or expensive WiFi, 3G or GEO/LEO
                satellite link.


Further to Christian Vogt's message:

  Host changes vs. network changes
  http://www.ietf.org/mail-archive/web/rrg/current/msg05467.html

it is possible to imagine a global network in which every physical
address for end-user networks and their publicly accessible hosts is
PA space.  Then only ISPs get PI space and the BGP system keeps
working, with a scaling problem limited to the number of PI prefixes
the ISPs advertise.

In order to do this, either the host networks or the hosts themselves
need to do extra work to create logical addresses to which
applications are bound, where these addresses are not at all tied to
the particular one or more PA addresses the host uses for physical
connection to the Net.

The core-edge separation schemes (LISP, APT, Ivip and TRRP) provide
scalable routing without changing host responsibilities at all.

LISP-CONS/ALT and TRRP frequently involve significant delays to
initial packets, sometimes equivalent to dropping the packets for a
some time like a second or two, while the ITR waits for a map reply
from their global query server networks.  APT and Ivip use
full-database local query servers so mapping replies come quickly and
reliably - in a few tens of milliseconds which is typically an
insignificant delay to the commencement of a new communication session.

Other than these delays, the core-edge separation schemes involve no
new delays - and no new responsibilities or management packets - for
hosts.

The idea of moving all new RA functionality to hosts is to do away
with the need for ITRs, ETRs etc. - though there still may need to be
a mapping database with either local query servers or a global system
to handle map requests.

No-one seems to be advocating such a "change hosts so they do all the
new work" approach for IPv4, but there are various proposals to adapt
IPv6 to this approach, or to develop new addressing regimes.  I think
most of these involve new stack <-> application interfaces - and
therefore completely rewritten application software.

Conceptually, this is simple and elegant.  I can't imagine how such
as system could be widely adopted on a voluntary basis, but this
message is about the in-principle objections to the outcome, not
about how difficult it would be to have such a scheme widely adopted.


As long as the extra work must be done by the hosts themselves, then
there are some fundamental problems:

   1 - This significantly raises the minimum complexity of any
       host, in terms of CPU capacity, software requirements and
       storage.  This is bad for mobile devices and embedded
       devices such as electricity meters and the famed IPv6 light
       switch.

   2 - AFAIK, in every potentially practical scheme, a lot of the
       burden is in complex cryptographic exchanges which are needed
       in order for hosts to be able to reliably identify and
       authenticate each other.

   3 - There is extra management traffic between the hosts and
       probably between each host and some network-centric
       support system, such as PKI or a mapping system.

   4 - Since no user communications can take place before these
       extra tasks are performed, and since these tasks involve
       exchange of packets, these proposals mean that it will
       generally take longer to begin a communication session
       than it does now.

   5 - All delays in these packets required for session
       establishment - and worse-still, loss of these packets -
       will further delay the establishment of user-level
       communication.


I propose that in any scalable routing system or clean-slate network
redesign, that it better not to require host functionality beyond the
what is currently expected of all hosts:

  1 - Except where configuration, software or a previous packet
      provides an IP address, use a DNS lookup to get an IP
      address of the other host.

  2 - Send and receive packets using that IP address and one of the
      potentially multiple IP addresses of the current host.

The core-edge separation schemes (LISP, APT, Ivip and TRRP - except
draft-meyer-lisp-mn-00) preserve existing host responsibilities.

Some, such as Ivip, make it possible for sending hosts to perform
their own ITR function, but this is not required of any host.  This
is a low-cost and generally efficient approach, except for when the
host is on a slow, expensive or unreliable last-mile link.  It would
work ten in principle, but it would tend to slow the establishment of
new sessions due to the delays and packet losses in the local link.

LISP mobile draft-meyer-lisp-mn-00 involves the MN being its own ETR.
 The MN does not need to be an ITR, and the ETR function is purely
for decapsulating packets - AFAIK it is not an authoritative query
server for mapping querys sent over the ALT network.   Although
draft-meyer-lisp-mn-00 involves this extra ETR responsibility, AFAIK,
this doesn't involve much extra management traffic or delay - so in
terms of this critique, it is fine.  The problem is that the MN's CoA
(care of - physical - address) can't be behind NAT.  Maybe that's not
such a limitation in IPv6 if IPv6 turns out to be NAT-free.  A
critique is at:

  http://www.ietf.org/mail-archive/web/lisp/current/msg00749.html
  http://www.ietf.org/mail-archive/web/lisp/current/msg00772.html

The TTR approach to mobility:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

retains conventional DNS and IP address host responsibilities, but
has an extra piece of software to provide tunnels to one or more
Translating Tunnel Routers which perform ITR and ETR functions.  The
TTRs and potentially some other servers also communicate with this
extra piece of software to find out where the MN is and to coordinate
how it establishes two-way encrypted tunnels to (typically) nearby TTRs.

These are extra host responsibilities, but they do not alter the main
stack or the application software at all.  Furthermore, while there
is some overhead of management traffic, such as that required to
ensure full delivery of packets in both directions between the TTR
and the MN, these extra packets do not delay the establishment of new
communication sessions.  (Note: this proposal could be adapted to
allow non-retry of some classes of packets, such as streaming media
and VoIP packets.)


What I am arguing against is proposals of the "dumb network, smart
host" variety which require *all* hosts to do some additional complex
things in order to make the whole network more elegant, immune to
scaling problems or whatever.

With hosts today, or with the hosts using a core-edge separation
scheme, each host can send or receive a packet with no extra delay or
traffic on its link (other than the initial packet delays of
LISP-CONS/ALT and TRRP).


We could design a conceptually elegant Internet, with perfectly good
scaling properties, simple routers and PA space for all end-user
hosts, by making every host behave like a MN with its own portable
application layer address (or multiple such addresses) which it
maintains no matter what one or more physical address or addresses it
is physically using.  The physical address and logical (application
layer) address could be separate namespaces, or separate sections of
the one addressing range in a single namespace.

HIP is an adaptation of IPv6 which does this.  However, it requires
packets flow back and forth between two hosts, and I think packets to
and from other network-based systems, before the two hosts can
establish a communication session upon which actual application-level
packets can travel.

Even if if every host had plenty of CPU power etc. and had fast,
reliable, low-cost links, it would still be unacceptable since it
slows the establishment of every communication, including the
equivalent of a send-and-forget UDP packet, due to the need for
complex cryptographic exchanges.   Whatever the delay time due to the
physical separation of the hosts, the speed of light in fibre, or of
radio waves in air, the delay in establishing communications will be
some multiple of the physical delay time, whereas today, there is no
such multiplication of delays beyond the DNS lookup and the TCP
handshake.


Even if we weren't forced to rely on voluntary adoption to solve the
routing scaling problem, I would still probably favour, for the
"Ideal Internet" design, a system like that of the core-edge
separation schemes, with distinct ITR and ETR functions.

The system would not require any host to perform the ITR function.
However, the ITR function should be optionally possible to implement
in the sending host, since this will often be possible and desirable,
and can be done for no hardware cost whatsoever.  (Ivip has this,
though not if the sending host is behind NAT.  It would be possible
to extend this to sending hosts behind one or more layers of NAT.)

Maybe a host could be its own ETR, but I the system should never
require this (LISP-MN does require this).

To require every host on the Net to perform all its functions on the
shifting sands of one or more essentially transient PA addresses,
like the CoA addresses of mobile hosts, with no special
transformation of packets in the network itself, is at odds with the
need for mobile devices to be inexpensive, simple and robust when
packets are lost or the link is slow or expensive.

Let the network support the hosts by centrally (such as within each
ISP or end-user network) transforming packets, including tunnelling
them between ITRs and ETRs, so all end-user hosts can just get on
with being hosts - so they do not need to be involved in the complex
business of portability, multihoming and inbound traffic engineering.

 - Robin