[rrg] Updating hosts

[RJ Atkinson <[e-mail]>]

On Sunday, 11 Nov 2012, Christian Huitema wrote, in part:
> I think that we are giving up too early on the feasibility 
> of updating all hosts. [...] I also think that a research group 
> should not necessarily shy away from investigations that 
> affect all hosts.

+1

Later on Sunday, 11 Nov 2012, Joel M Halpern wrote, in part:
> I can well believe we can, for a reasonable value of all, 
> update all host TCP and UDP engines with a small, migratable, 
> change.
> 
> We can't change all host applications.
> 
> And we can not make a change that does not interoperate
> with existing hosts.

+1


Indeed, ILNP does update hosts, but does so with a 
clearly documented "backwards compatibility" mechanism
and also a clearly documented "incremental deployment"
scheme.

At least one ILNP prototype already has shown an *un-modified* 
(i.e. no source code changes, no recompilation) FreeBSD ping6 
binary using ILNPv6 between a pair of ILNPv6-enabled hosts.
(NB:  I'm aware of 2 independent implementations of ILNP 
that are underway, one for Linux and one for FreeBSD.)

This is a good initial step towards showing that ILNP
will enable existing "host applications" to be used with
ILNP -- without requiring application changes.

On Monday, 12 November 2012, Tony Li wrote, in part:
> The cost of software changes to the end user are now pretty much 
> lost in the churn of maintenance releases and new devices.
> 
> Thus, the real hurdle that has to be accomplished is to woo 
> the OS providers.  Convince them to implement and distribute 
> and that solves the deployment problem.  And to convince the 
> OS providers, you have to show them the killer app.  Without 
> a value add, it's not in their interest.

+1

The market makes its own determinations about what might
be sufficient "value add" to be worthwhile to distribute.
My crystal ball ('palantir') is cloudy, but here are 
some candidates, as a thought exercise:

1) Handset Mobility

  The ability to migrate TCP (or UDP or ...) sessions of 
  a mobile handset (or Surface or iPad or similar) between
  the (usually lower cost per bit) WiFi interface and the
  (usually higher cost per bit) GSM/LTE/CDMA2000 interface,
  as desired, without losing the application-layer session,
  and without requiring deployment of special Mobile-IP
  routers, might be such a killer app.  [See MILCOM 2008
  paper and the "mobile networks" paper from MILCOM 2009
  for how this works]

2) VM migration across routed IP subnetworks

  The ability to move an entire VM across routed IP subnets
  might be another such application.  Certainly some large
  multi-site data centre operators (e.g. folks who measure
  computing in CPU-Acres or CPU-Hectares) very much would
  like that capability.  [See our MILCOM 2012 paper for how]

3) Site-Driven Multi-homing (w/o adding prefixes to DFZ)

   The ability of sites to multi-home, without having to 
   coordinate with all of their upstream providers, and
   without having to add site-specific routing prefixes
   into the world-wide DFZ RIB appeals to many.
   [See our MILCOM 2009 paper on site-Controlled multi-homing
   for how]


Yours,

Ran


PS:  All of these MILCOM papers are available from U. St Andrews,
     along with nearly all of the other ILNP papers.  :-)
     <http://ilnp.cs.st-andrews.ac.uk>