[e2e] 10% packet loss stops TCP flow

[Cannara]

Adding to Reiner's comments -- serendipitously, I just assisted a consulting
customer with a 10% packet loss problem.  Plain TCP performance dropped by
over a factor of 3, simply because of a faulty DSLAM at the local ISP.  Riding
along on the same link was a similar amount of VPN traffic.  It was largely
unaffected by the losses, because it's transported in UDP and has its own
recovery processes that work faster than normal TCP.  The TCP traffic showed
all the proper timeout, fast-retransmit, etc. behavior, yet was brought to it
knees by the modest loss rate.  This, in an environment with RTTs around .1s. 
Having elsewhere seen less than 1% loss yield a 20% TCP slowdown on even
faster links with the same RTT, it's not at all surprising that TCP's behavior
is poor when it shouldn't be.

The arguments against perfection in lower layers are naive in a few clear
respects:  a) the RTT values TCP sees have little to do with the delays that
links in any path see; b) the recovery/prevention techniques at lower layers
can be far quicker and more effective than TCP's; c) historically, TCP's
concepts of link management exclude error sensing, thus exposing an Achille's
heel no "transport" protocol should; and d) protocol development was stopped,
for the Internet, for reasons other than perfection.

Point a) refers to how data handling in PSTNs has been well managed for
decades (flow control, error correction...).  Point b) is related to that and
how well even LAN-links handle recovery, as Ethernet does under collision loss
by retransmission within microseconds, not seconds.  Point c) simply refers to
the myopic, rushed design of TCP's 'congestion control' functions, at the
wrong layer and without proper distinguishing of loss types; and, that TCP is
not the only transport traffic.  The satellite and space-probe folks have long
done better, because they thought and did more about link and transport
problems.
--
Alex