> I remember bringing up this issue very briefly at the BOF. The effect of
>link layer retransmission can have degrading effect on TCP performance. In
>the cellular wireless context, we generally have a link layer ARQ mechanism
>active over the radio link. The remote TCP sender may timeout while local
I designed the radio link protocol for IS-95 CDMA packet data with
this issue specifically in mind. Some form of link-level ARQ is
essential in that system, because the raw physical layer frame erasure
rate (1-2% for a ~30 byte frame) is too high for end-to-end TCP
retransmission alone to give acceptable performance. But "too much"
link-level ARQ would cause the problem you describe.
My approach was to limit the number of frame-level retransmission
cycles to two, and to send two duplicate copies on the second cycle to
increase the chances of at least one getting through. This design was
somewhat ad-hoc, but they seemed to work well in field tests. Even a
single retransmission made such a dramatic improvement in TCP-level
throughput that it didn't matter much what we did beyond that. We
simply made the link "good enough" to carry TCP with reasonable
throughput. The link didn't have to be, nor should it have been,
perfect.
You can make your link layer loss rate as low as you want *if* you
don't care about latency. You just FEC code and interleave over a
sufficiently long time span. But then you *always* have to wait for
your data. With ARQ, you wait only when you have an retransmission.
Seems to me the ideal link ARQ/FEC hybrid would interleave the coding
over a time span comparable to the propagation delay of the underlying
channel. The interleaved coding would handle random errors (e.g., due
to thermal noise) and short, fast fades on time scales of less than a
link propagation time while the ARQ would kick in to handle longer
outages (e.g., slower fades). And the ARQ should give up after an
interval comparable to the TCP round trip time -- not that I know how
to do this without some extra inter-layer communication.
The IP TTL field is theoretically calibrated in seconds. In theory,
the sending TCP could set the IP TTL field based on its current
retransmission timeout so an undelivered packet delayed in the network
by an unusual number of link level retransmissions (or for any other
reason) could be dropped when TCP would retransmit anyway. The coarse
quantization of the TTL field (1 sec increments) and the minimum
per-hop decrement of 1 makes this impractical in today's Internet.
Now that GPS clocks are common, we could define an IP header option
with a precise expiration time. Can anybody think of a real link for
which this wouldn't be overkill?
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST