Re: Minutes / Notes

[Iljitsch van Beijnum <iljitsch@muada.com>]

On zaterdag, jul 19, 2003, at 22:06 Europe/Amsterdam, Christian Huitema 
wrote:

> > 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.
Christian, did you see my message with subject "More random and not so 
random thoughts" from a few days ago? Here I address these issues. I 
would very much like your input on my reasoning there.

> 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.
Yes, this is true even today in IPv4: the locator function of the 
address concerns itself with the interface. At the same time, the 
identifier function works host-wide: when a packet is received over 
another interface than the one the packet is addressed to, and often 
even if this interface is down, the packet processed as the host 
recognizes it is addressed to it.

> 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?
I don't pretend to have all the answers here (hmmm, does this mean I 
normally do pretend to have all the answers?) but I have a hard time 
coming up with a reason why this would matter. Does the nature of that 
which is identified really change the identifiyng process and whatever 
else depends on this process?

> I heard many say during the multi6 debate that applications cannot 
> possibly handle multiple addresses well.
I'm not sure if you're referring to anything I've said, but if so: 
that's not what I meant. Well-designed applications could in fact 
handle this well, in some cases maybe even better than a generic 
mechanism as the application has better knowledge of what is a good 
idea for the task it needs to accomplish. But see my list of issues in 
the message I mentioned earlier for why having the applications do this 
as a rule is still a bad idea, IMO. And there is of course the fact 
that an application can't make TCP switch addresses in mid-session.

> 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.
Are you saying multihoming as we know it today, where we try to 
maintain (amongst others) running TCP sessions across rehoming events, 
is of no value?