Subject: RE: Consensus on identifier/locator split?

From: "Christian Huitema" <[email-masked]>
Date: Wed, 6 Aug 2003 21:14:38 -0700

> However, if you want to keep the existing TCP (and I would think that's a
> good idea, if you want to try and keep within the bounds of what's vaguely
> feasible), then I suppose you have a point.

I am not sure that I want to keep the existing TCP, and in fact I wrote a draft back in 1995 explaining how TCP could be rather simply upgraded to make sure that connections can survive address changes. The trick is simple: create an identifier inside TCP, and then associate several addresses/locators to the connection. I actually like the fact that TCP can see and manage "locators", because the transport is one of the best places to maintain short term knowledge about the relative performance of a specific path, and thus arbitrage between the various paths.

The idea of an optional upgrade to TCP is interesting because it allows hosts to "opt in" the new facility. I would expect that many hosts would actually opt out, either because they only use short lived sessions and thus don't care for an exceptional failure, or because their applications know how to manage sessions and patch together multiple connections. Indeed, this is a generic requirement for any identifier scheme: hosts that don't see the point should be able to opt-out and not bear the burden associated with the "layer of indirection."

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 7 Aug 2003 11:47:37 +0200

On donderdag, aug 7, 2003, at 06:14 Europe/Amsterdam, Christian Huitema 
wrote:

> create an identifier inside TCP, and then associate several 
> addresses/locators to the connection. I actually like the fact that 
> TCP can see and manage "locators", because the transport is one of the 
> best places to maintain short term knowledge about the relative 
> performance of a specific path, and thus arbitrage between the various 
> paths.

Yes, this way I want it to happen too, for the cases where the 
transport is TCP.

I believe that the current approach by the design team is compatible 
with this goal.

> Indeed, this is a generic requirement for any identifier scheme: hosts 
> that don't see the point should be able to opt-out and not bear the 
> burden associated with the "layer of indirection."

Obviously any and all mechanisms we come up with are going to be 
optional.

The problem is that the usefulness of these mechanisms is probably 
something that differs more from application to application rather than 
from host to host and we must be able to make existing applications 
support it.