>retransmission itself. BUT, there is always a need for the link layer to
>tell TCP NOT TO RETRANSMIT when it itself is doing retransmissions. One way
>to achieve the same goal is to stop the link layer retransmissions and let
>TCP recover. Question is when?
I still think you're trying to solve a non-problem, or at worst a
second-order problem. If link retransmissions never occur, there's
obviously no problem. If they occur infrequently, then so do the TCP
retransmissions and the overall performance is seldom affected. And if
link retransmissions occur frequently, the high RTT variance seen by
TCP will bias up its retransmission timeout, again preventing
unnecessary TCP retransmissions from happening too often.
> The link layer retransmissions should be continued to the maximum possible
>amount of time in order to get the maximum benefit out of it, making sure
My point is that on any reasonable channel, the maximum benefit from
link-level ARQ comes very quickly with the very first retransmission
or two. It just doesn't have to be carried out very far, because under
normal circumstances you don't have to retransmit very often. If you
do, something is probably broken. Just blindly hammering away
indefinitely is probably not going to help.
Look at it this way: if you routinely have to retransmit each frames
four or five times on a link, you are effectively getting only 20-25%
of that link's capacity. That's pretty bad. You could do much better
with stronger FEC and/or interleaving in the physical layer so that
ARQ retransmissions (either at the link or transport layer) just don't
have to occur as often. You pay for the FEC overhead with the reduction
in ARQ retransmissions.
You don't want to overdo the FEC either. Beyond a certain point, the
further savings in ARQ retransmissions will no longer pay for the
extra FEC overhead, so you stop. You have to look for the optimum
balance.
ARQ and FEC are complementary error control mechanisms that each have
their ideal operating environments. FEC is good at reducing a very
high raw channel error rate to a low one, while ARQ is good at
reducing a low rate to essentially zero. It's inefficient in most
cases to use FEC alone to reduce an error rate to zero, and it's also
inefficient to use ARQ directly on a channel with a very high error
rate.
Similarly, ARQ at the transport and link layers are complementary. The
purpose of link layer ARQ is to reduce the loss rate to a level that
TCP can deal with reasonably efficiently; it does not have to reduce
this loss to zero because you will always need TCP to provide the
end-to-end check.
Phil
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:20 EST