>What CAN be detected (and signaled) are delimited *periods* of
>link difficulties. This can be a link-outage (i.e., you've lost
>a link-lock, are hunting in the noise to resync after a deep
>enough fade, had a hand-off, etc.) or detection of a significant
>fade on the channel. FEC may get you a pristine channel in some
>environments if you can pay the appropriate price - but that price
>can also mean that you lose access to the channel for periods of time.
I fully agree with everything you said, and I think we're on the same
track. The common theme to all these problems (flaky links, mobility,
etc) is to make TCP's retransmission mechanisms work better over paths
that go away for a while and then come back.
What do you think of the "ICMP Destination Reachable" message to
complement the existing ICMP Unreachable? Routers would cache the
senders to whom they had recently sent unreachable messages due to
links going down, and they would try to send "reachable" messages to
these same senders when the link comes back up.
On getting a "reachable" message when there is unacknowledged data,
TCP would act as though the retransmission timer had just expired: it
restarts slow start, retransmits the oldest unacknowledged packet,
backs off the retransmit timeout and restarts the timer. If the timer
isn't running (i.e., no outstanding data), TCP sends a single empty
ACK in case the other end had been trying to reach us.
Many wireless links are slow and "thin" routes with very few hosts
(often just one) so caching the unreachable messages and later
generating the reachable messages shouldn't be much of a burden on the
routers that drive them. There's no obligation that they do so; TCP
will eventually recover on its own, but these messages can speed up
the process considerably.
I proposed this idea to the IETF many years ago, but I don't think
anyone ever implemented it. In the ham packet radio world, I did
implement a manual "tcp kick" feature. Hit a key (I think it was F7)
in my KA9Q NOS stack and the TCP for the current session behaved as I
just described. I also implemented a "kick server" so you could send a
special UDP packet to a remote host and have it "kick" any TCP
connections it might have to you (or to someone else, there were
address fields in the kick message.) The security implications of this
feature were minimal, since you could only cause a TCP to do what it
would have done on its own eventually.
On ham packet links, packet losses *are* often due to noise or
collisions, as opposed to link status changes, so there wasn't an
obvious place to hook the generation of the reachable message. At
least hitting the F7 key gave you something to do while you were
waiting. :-)
Phil
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:42 EST