[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Minutes / Notes
> From: Keith Moore <moore@cs.utk.edu>
> It is essential that TCP connections be able to survive link failures.
> If you don't have this, you basically have to re-implement much of TCP
> at a higher layer. (Typically, explicit acks for application data, the
> ability to detect a lack of acknowledgment and to retransmit
> unacknowledged application data, and to gracefully handle duplicate
> transmissions of application data.)
Some of this you have to do anyway (e.g. "explicit acks for application data,
[and] the ability to detect a lack of acknowledgment") because the
application at the far end may consume your data (so you get an ACK from the
TCP layer), and then hang. TCP's happy, and if you're depending on TCP to
give you an error you'll be waiting forever.
But to more broadly discuss your point, surely you have to have some higher-
level mechanism to recover from failures anyway, for fairly terminal
situations; e.g. if the entity on the fair end crashes, or if the entity on
the far end is singly-homed, not multiply-homes, and its link fails.
So if you have to have such a mechanism anyway, I don't find the argument you
cited to be very conclusive.
However, I don't think that settles the general question, of whether the
benefit of yet another mechanism (to allow TCP connections from a multi-homed
host be able to survive having an incoming link fail) is large enough to be
worth the extra complexity.
Noel