the on-the-wire protocol overhead is not that great. the computational
overhead to the host and application, and the resulting loss in maximum
bandwidth, are fairly expensive.
I tend to disagree. An association protocol only really does its work on
connect/reconnect - hopefully a rear event -- and when the application
says "let's establish a work-mark here".
no, that's not the bulk of the work. the bulk of the work is just in
managing the extra copies of data (applications don't want to deal
with this explicitly, they want it handled by lower layers), in
detecting failures, distinguishing one kind of failure from another,
and in recovery.
You are describing a super-transport, a TCP on TCP.
I don't want a super-transport.
All I'm trying to do is to create a means by which an aware application
can recognize transport (TCP) connection failures in a way that allows the
communicating parts of that aware application to resynchronize their
activity over a new TCP connection. That's hardly the heavyweight engine
that you are positing, and there is no need for the protocol to retain
data or do anyting other than allow the communicating applications to
declare to one-another that they have reached a namable point in their
interaction.
Need Freed has pointed me to some interesting drafts that might do the
trick (or might be a good headstart)
draft-xie-stewart-sigtran-ddp-00.txt
OTOH, by putting the mobility at the IP layer, you can let TCP take care of
the sequencing etc. and you don't have to implement it again in a higher
layer.
Sure, IP address shell games do frequently work. So does NAT.
By putting long-distance mobility at the IP layer we force the packet
path mechanisms to engage in a game of patting its head while rubbing its
tummy and reciting the alphabet backwards.
That's sometimes the right thing to do, other times it is not - the choice
is application dependent.
Sometimes it is easier to simply break a TCP connection and later create a
new TCP connection - and that's not just for mobility; it has many other
uses.
--karl--