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