[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Minutes / Notes
On zaterdag, jul 19, 2003, at 22:06 Europe/Amsterdam, Christian Huitema
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.
If you have two separate multi-homing mechanisms, then the cost, in
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.
complexity, implementation size, amount of protocol specification work
needed, etc, etc just seems to me out of all proportion to the
about second-system disease! Pick one.
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
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?