> FEC or/and Link Layer ARQ are important to protect from loss.
> Loss may also result from lack of "tracking" e.g. in a burst modem.
> Link layer ARQ is beneficial at low rates, and most useful if it
> considers the type of traffic AND does not adversely impact TCP.
> At low rates, concatenated FEC (e.g. RS) may introduce considerable
> coding delay. At high bit rates (>2 Mbps), FEC or adaptive FEC is
> probably beneficial and may be "fibre quality" (e.g. RS) or may
> still leave residual errorts in worst-case conditions (e.g. Turbo).
Using a link layer ARQ is not as simple as it seems. We have tried it
a few times with our VSAT system. Assume no lost packets. Then TCP's
RTT will be equal to the true round trip time across the satellite.
Then, if a packet gets dropped, the link layer ARQ may (and probably
won't) have time to recover the packet before TCP retransmits it.
This results in two copies of the packet being delivered and two (TCP)
acks being sent. This starts to cause minor confusion (such as
inaccuracies in the RTT calculation) and degrades even further when
more than one packet is lost. The only way a link layer ARQ helps is
if it can guarantee to recover the dropped packet before the TCP
timeout occurs. To make this work, our customers had to hand tune
their TCP stack to make this so. Hand tuning is painful so it turned
out that everything worked much better with the link layer ARQ turned
off, letting TCP do its own packet loss recovery...
John Border/Hughes Network Systems
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:38 EST