> Tony Hain wrote: > > >In the ongoing saga about topology reality vs. application perception of > >stability, it occurs to me we are not working on the right problem. In > >short we have established a sacred invariant in the application / transport > >interface, and the demands on either side of that interface are the root of > >conflict. > > > >Mobile IP, and the multi6 DHT work are attempts to mitigate it through > >slight of hand at the IP layer, while SCTP attempts to mask the topology > >reality in the transport layer. (These are probably not the only examples, > >but they are the ones that come to mind this morning.) Yet none of these > >really do the job in all cases. > > > > SCTP seems to me to do most of what you propose in this "layer"... assuming > an SCTP that includes the ADD-IP extension I can (and I have done this > with the KAME stack) [...] Yes, SCTP does *most* of this. It can handle the case where one party of a connection moves, and it is able to tell its peer that it has moved. IIRC, it doesn't handle concurrent moving of both connection endpoints (even if both endpoints are in the same network), nor does it handle cases where timely notice cannot be provided. Nor does it handle rendezvous or referral because in those cases there's not a constantly-open connection over which to signal locator changes. So I don't view the SCTP approach as a complete solution, but it might be useful as part of a solution. Also, I'm not insisting on a separate layer. As far as I can tell, some of the changes needed could take the form of backward-compatible modifications to TCP and UDP and perhaps SCTP also, and I certainly think it's worth considering those techniques. Whether this is best handled by changes to layer 4 (and perhaps layer 3 also if we need support from the routers), or a new layer between 3 and 4, is not something I claim to have analyzed in detail. (OTOH, I am insisting that it's not reasonable to try to solve the entire problem above layer 4. For different reasons - mostly economic - I suspect it's not reasonable to try to solve the entire problem below layer 4 either, but I'm less sure of this.) > We could do has Keith has proposed.. put it at a layer BELOW the > transport. Now, what do we end up with? > > 1) A NAT like thing that is playing games with the IP addresses and > checksums (aka the psuedo-header) > <or> > 2) Putting a psuedo IP address (the identifier) on the machine for the > app to use apart and > seperate from the real physical IP address in use. I don't think the two are inherently that different. Say you define a new identifier that can be associated with a connection endpoint, and you build a mechanism that allows a host to map that identifier to one or more locators. Now you can tweak TCP to allow it to define either or both of its connection endpoints (what is now the pseudo-header) in terms of those identifiers rather than in terms of the locators currently in use, and you tweak the demux layer on hosts that support this extension so that it can accept multiple source,destination locator pairs and map each of them into the same TCP channel that is defined in terms of endpoint identifiers. Then you define ways of doing signalling via TCP options so that the hosts can learn about new locators and deprecated locators for their peers. I see this as a variant of your #2, but it also has a vague resemblance to NAT. However, I don't think this has any of the problems of NAT. Essentially what it would accomplish is to cleanly separate connection endpoint identifiers from locators, which people have been saying was a good idea for a long time. And I think it could be done in such a way that it is fairly compatible with existing apps that use TCP. Keith