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 rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg