Subject: Re: Comments to "Advice for Internet Subnetwork Designers"

From: Reiner Ludwig <[email-masked]>
Date: Tue, 01 Aug 2000 12:33:54 +0200

At 07:54 31.07.00 -0700, Phil Karn wrote:
>What you really want to avoid are the nasty interactions between TCP
>and link/physical layer retransmissions that can occur in certain link
>operating regions.

People often talk about those interactions as if there where so many of 
those. What are those interactions you are talking about?

I only know of two such interactions:
(1) spurious timeouts that lead to a go-back-N retransmisison mode in TCP, and
(2) out-of-order delivery at the link layer that falsely triggers fast 
retransmit / fast recovery.
Of course, both are nasty.

Given that PILC recommends that link layers should avoid out-of-order 
delivery (also for the sake of not causing trouble for TCP/IP header 
compression) this leaves spurious timeouts as the cardinal problem.

Two notes about that:
(1) There is a fix for that 
http://www.acm.org/sigcomm/ccr/archive/2000/jan00/ccr-200001-ludwig.html
(2) Spurious timeouts are very rare because TCP's retransmission timer is 
overly conservative 
http://www.acm.org/sigcomm/ccr/archive/2000/july00/ccr_200007-ludwig.html

>Consider a physical layer with a long latency and
>link layer ARQ. Most packets go through without link level ARQ, so
>most of the time the RTT is consistent and TCP shrinks its RTO to just
>above the RTT.

At least for BSD-derived TCP implementations this is not the case. The 
minimum difference between the RTO and the RTT is about one RTT but most of 
the times the RTO is even much higher. See the paper referenced above.

>But whenever the link layer retransmits, the RTT spikes
>and there's a spurious TCP retransmission.

This is a simply not true. You have to let things go really bad to force a 
spurious timeout in TCP. Depending on your path characteristics especially 
those of the wireless link, TCP can even "survive" link outages on the 
order of seconds without a spurious timeout. Apart from the two papers 
referenced above, here are a few more papers that confirm that:

1. P. Bhagwat, P. Bhattacharya, A. Krishna, S. K. Tripathi, Using channel 
state
dependent packet scheduling to improve TCP throughput over wireless LANs,
ACM/Baltzer Wireless Networks Journal, Vol. 3, No. 1, January 1997.

2. D. A. Eckhardt, P. Steenkiste, Improving Wireless LAN Performance via 
Adap-tive
Local Error Control, In Proceedings of IEEE ICNP 98.

3. R. Ludwig, B. Rathonyi, A. Konrad, K. Oden, A. Joseph, Multi-Layer 
Tracing of
TCP over a Reliable Wireless Link, pp. 144-154, In Proceedings of ACM 
SIGMETRICS
99.

4. M. Meyer, TCP Performance over GPRS, In Proceedings of IEEE WCNC 99.

You and I had these discussions before on this list and I don't know why 
you keep repeating these fairy tales.

>If link level retransmissions are rare, then spurious TCP
>retransmissions are also rare and their effect on performance is
>minimal.  If link level retransmissions are very frequent, TCP sees a
>high RTT variance and sets an RTO that is well above the average
>value. Again, spurious TCP retransmissions are rare. But things can
>degrade badly in the intermediate region, say, every 10th packet. Just
>when TCP has dropped its RTO to just above the average RTT, another
>link level retransmission occurs and causes TCP to spuriously
>retransmit.

Again, this is not true. I would like to see some measurements that support 
your claims.

///Reiner