Keith Moore wrote:
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.
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...
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 is bad.. if we could reach some solution that is NOT
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(_at_)stewart(_dot_)chicago(_dot_)il(_dot_)us 815-342-5222 (cell phone)