RE: Fwd: Minutes / Notes

["Christian Huitema" <huitema@windows.microsoft.com>]

> If you have two separate multi-homing mechanisms, then the cost, in system
> complexity, implementation size, amount of protocol specification work
> needed, etc, etc just seems to me out of all proportion to the benefit. Talk
> about second-system disease! Pick one.

Frankly, I am not sure about the "pick one". It supposes that we know exactly what we want to design, and that we can commit to one right now. Yet, there are very different trade-offs. For example, a fundamental design choice)  is the layer at which identifiers are maintain. Is it IP, transport or session? The 8+8 and 16+16 designs assume that the answer is IP; the SCTP design provides a transport based solution that could in fact easily be retrofitted in a TCP+; many toolkits based on HTTP or RPC provide a form of session management. It is very unclear to me that IP would in fact be the right layer for the job.
 
Another quite important design choice is the scope of the identifier. IP addresses have a well defined scope: they identify a way to send data to a specific interface in a system. They can be understoud as a contract between a transmission provider, the IP network, and the host. The scope of an identifier system, by definition, has to be wider. Yet, we don't really know how wide. Is it a host? A host is in fact a pretty loose concept. Consider clusters on one hand, multi-user systems on the other. Would you have an identifier per node in the cluster, or one per user in a multi-user system? What about process mobility? If you are running a distributed application, do you identifiy the application, an instance of it on a node, or the node that supports this instance?
 
Yet another design choice is the life-time of the identifier. There are periodic proposals of an identifier baked in a device, e.g. a unique ID for a 3G phone. But there are also identifiers based on sessions, e.g. web cookies. And there are very different privacy and reliability implications between the two variations.
 
I heard many say during the multi6 debate that applications cannot possibly handle multiple addresses well. To disprove that, I suggest you take a look at the variations of "swarmcast" implemented by P2P systems such as Kazaa or E-Donkey. These systems are about exchanging files, so they have their own identification system -- file names. The naming system can resolve file names to multiple locations of a file. The transfer system then asks slices of the file from a set of more or less randomly chosen locations.  It automatically adjust to topology by asking more from those locations that serve faster. And it automatically compensate connection losses by just repeating the slice request, or a fraction of it, to some other nodes. Such a system would handle multi-addressing beautifully.
 
But my real point when bringing up the P2P example is that innovation happens. Swarmcast is just an example. Real-time multi-media systems are investigating something similar using layered encoded stripes instead of slices. Office automation systems use transaction processing. The list goes on. What we are observing is a distributed innovation process arbitraged by the market place. I trust that much more than a identifier/location split designed by committee.
 
-- Christian Huitema