Catching up...
>1. complete link outage that exceeds the order of the path's RTT
>[...]
>I think/hope it is probably easy to agree that case 1 is not a networking
>problem but much rather requires more or better tuned base stations. You
>also can't expect TCP to work fine if you pull the Ethernet jack. Just as a
Yes, but. Yes, it's unreasonable to expect TCP to continue working if
you pull out the network plug. But I would like TCP to recover more
quickly when the plug is put back in. Right now, if the plug has been
out for a while TCP won't discover that the link has returned until
the next retransmission timeout. And with the exponential backoff in
effect, this can get pretty long.
I suggest something along the lines of a "ICMP Reachable" message sent
by routers to recent senders of packets it had to discard due to a
broken link that has since returned. Receipt of this packet would
cause TCP to force an immediate retransmission, or to transmit an
empty ACK if no send data is pending.
I did something like this 10 years ago in my TCP/IP package for
amateur packet radio. I called it a "remote kick" command packet and
carried it in UDP. While it had to be manually invoked, it worked very
well.
>tricky part is to define "sufficiently". As a rule of thumb I would say
>that the delay due to LL ARQ introduced per IP packet should in 95 percent
>of all cases not exceed the wireless link's RTT (maybe also including the
Right, because the vast majority of packets will get through on the
first try, and the vast majority of the remainder will get through on
the second try. Unless something is really broken, in which case you
need better FEC (or a better antenna, or more base stations).
>hand I'm convinced that e.g. the GSM circuit-switched data link
>"over-meets" those guidelines and that much higher throughput could be
>achieved by weakening the FEC (which by the way is being done in GSM) while
That's interesting. In CDMA, stronger FEC is always better, though you
do reach a point of diminishing returns. Viterbi wrote a paper on that
subject quite some time ago (it predated IS-95 CDMA). Even in GSM, I
suspect they could increase total system capacity (though not the
throughput of a single user) by keeping the strong FEC and instead
reducing transmitter power to reduce interference to other users.
>I do not agree with you, however, that semi-reliable LL ARQ is the right
>path to take (when dealing with reliable flows) but instead argue in favor
>of fully-reliable LL ARQ. The reason is simply that this will both in case
>2 and case 3 cause congestion which is exactly the right signal we want to
>give to the sender. If over the duration of a transport connection the
But wouldn't just dropping the packet after some number of
unsuccessful link-level retransmissions accomplish the very same
thing? TCP already treats timeouts as congestion indicators, right?
Again,because most packets are delivered with no retransmissions, and
the number of retransmissions decreases exponentially with number,
we're really arguing about higher-order effects here.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST