Subject: RE: Fwd: Minutes / Notes

From: "Christian Huitema" <[email-masked]>
Date: Sat, 19 Jul 2003 13:06:57 -0700

> 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

---

From: Pekka Nikander <[email-masked]>
Date: Sun, 20 Jul 2003 11:02:51 +0300

Firstly, IMHO it is very good that the WG seems to be converging
to the notion that we basically have to make the id/loc separation.
Now, if we do make that, Christian is asking a couple of very
good questions.  I also think that we already know some possible
good answers to these questions.  It is then another matter whether
we want to go with the better answers or be happy with some lesser
ones.

Christian Huitema wrote:
> Another quite important design choice is the scope of the identifier.
>  ... The scope of an identifier system, by definition, has to be 
> wider [than the scope of an IP address]. 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?

If we can design our architecture and solution in such a way that
is remains basically an *operational* choice to decide the scope
of an identifier, then I think we have reached a good solution.
This seems to reduce to a situation where one can assign an
identifier to any process group.  Then it remains a matter internal
to that process group and the underlying hosts to arrange
clustering, process group migration, etc.

In practise, we can start by saying that an identifier identifies
a host, but engineer the solution in such a way that the connection
between the identifier and the host is a relatively loose one,
allowing more flexibility in the future.

> 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.

IMHO, we need identifiers that have different lifetime and different
privacy properties.  We want to have identifiers that are short
lived and anonymous.  We need identifiers that have a longer lifetime,
act as pseudonyms, and may be assocated with some local credentials.
Finally, we probably also need long lived identifiers, associated
with credentials with more or less global scope.

The identifier name space should accomodate all these.  Furthermore,
it MUST NOT make any syntactical distinction between these three
of these.  That is, just by looking at an identifier it MUST BE
impossible to tell its lifetime and privacy status.  (Why?  Think
about collecting and correlating identifiers vs. privacy).

--Pekka Nikander

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 20 Jul 2003 23:39:52 +0200

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

> 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.

> 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?

---

From: S Woodside <[email-masked]>
Date: Wed, 23 Jul 2003 14:33:06 -0400

It's worth noting though that this is what these p2p applications do, 
it's the core of their development. one could equally argue that 
anykind of ad-hoc mesh protocol work could learn a lot from the p2p 
apps. it's a long way from that to expecting average program to do the 
same things.

simon

On Saturday, July 19, 2003, at 04:06 PM, Christian Huitema wrote:

> 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.

--
www.simonwoodside.com -- 99% Devil, 1% Angel

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 Jul 2003 15:41:52 -0400

many p2p apps do their own routing because they are forced to do so, 
not because this is a desirable or acceptable burden to impose on
applications.    also, what works acceptably well in a system to
transfer widely-replicated files does not necessarily work well in a
system where host identity is important.

Keith

> > 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.