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