So what I am suggesting is that it seems that there is evidence that one
can do an "association" protocol that is relatively lightweight in terms
of machinery, packets, packet headers, and end-node state if one leaves
the heavy lifting of reliability to the underlying TCP protocol.
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. for instance, to make the handoff efficient you
want to have the ability to say to your peer "please contact me on
this new address" and have it do so. but that message may be delayed
and meanwhile some new data might have been sent your way. so the
host that is moving might also arrange to have data which was
sent to its old location forwarded to the new location for a time -
this saves the burden of getting the peer to retransmit everything.
but the "I'm moving" message might get dropped - this is actually
likely because hosts don't usually know that they're moving and
you have to assume that hosts that are mobile will be disconnected
from time to time. so you still need a fallback way to find your
peer's connections again - and this generally means some sort
of resolution service for connection endpoints. and the resolution
service probably also needs some redundancy.
now realize that it's quite possible for two peers to be moving
on the network at the same time, with their redirect messages
crossing each other and/or being dropped. etc.
there are a lot of states that have to be dealt with if you want
the system to be both reliable and efficient.
And given that many of our applications are bursty/transactional vehicles
we're not talking about supercomputers transfering bulk files of
simulation data.
if you're talking about a general purpose facility then it probably
does need to span a wide range of applications' needs. perhaps not
supercomputers exchanging large matrices, but those are hardly the
only applications that care about performance and bandwidth.
even lowly web servers care about performance and bandwidth.
basically it's a lot more efficient to do some variant of mobile IP.
Mobility is not the issue. Rather, there is use, distinct from mobilty,
for an association that can persever longer than the underlying
transport(s), including changes of IP addresses.
if you build a level of indirection to handle this then it had better
handle mobility also.
and we don't need the kind of facility you're talking about just to
do renumbering. nor would such a facility be sufficient, because
IP addresses are kept in other places besides just TCP connection state.
In my eyes, an application that uses an association protocol to deal with
changes and faults in underlying connectivity is a lot more in accord with
end-to-end principles than if it relied on ad hoc transport/network
address juggling.
either approach is end-to-end. it's just that by putting this functionality
above the transport layer you end up duplicating the functionality that
was already implemented at lower layers, and you have to make the resulting
system fairly complex before you gain much for your trouble.
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.
Keith