Tony Hain wrote:
SCTP seems to me to do most of what you propose in this "layer"... assumingIn 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.
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.
Yep.. and neither would a layer put under or over the transport. And I am not sure about the timely issue. In the case of moving you only have a 1 RTT time lag... that may be considered not timely enough.. I guess.
Also to handle con-current moving you need some rendevous point... aka a mobile-ip home agent or its equivalant.. this same issue would exist for any layer (upper or lower)...
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.
Yep.. it solves one part of the problem.. can we find ways to solve the other parts.. I think yes.. I know Michael Tuexen has some ideas on the referral side.. he voiced them at the last SCTP bakeoff.. if referral means sort of a proxy setup where some other host will be handling the actual connection.. Michael was kind of vague.. and we did not thrash out any details.. but I think he will be putting forward a draft somewhere down the road ... the old idea->napkin->draft :->
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.
ok.. I can agree with that.. there is ALWAYS room for improvement :>
(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.)
I think we are in FULL agreement here.. I don't see it working well above layer 4. This is why we (Qiaobing and I) only handled failover when a server broke above layer 4 in our model.. linkish related things new IP address.. multi-homing et.al is best done at or below 4...
mucking the IP header is bad.. if we could reach some solution that is NOT
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.
mucking the IP header then it might be ok... I am just not convinced yet... having
the transport aware seems to me a cleaner solution. .but of course you knew
I would say that :->
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.
ok.. but I think you are really talking about a "new" TCP... by the time you tweak this and massage that you have re-written/modified/... (fill in your choice word) TCP into something it was not before... as long as we are at it lets fix the head-of-line blocking problem too.. after all as Kacheong would say.. its just code... of course this then just becomes TCP picking up all of the ideas of SCTP and becoming it :-0
I think originally sigtran would have wanted to modify TCP if they would have been allowed.. instead of rolling a new transport.. now that we have the new transport.. how much do we back-port ?
R
Keith
-- Randall R. Stewart randall@stewart.chicago.il.us 815-342-5222 (cell phone)
