Subject: [Tsvwg] Proposing a new algorithm for recovering TCP RTOs

From: Pasi Sarolahti <[email-masked]>
Date: Fri, 1 Mar 2002 12:44:15 +0200

Hello,

I hope you can find the time to read this rather lengthy mail through and 
give your opinion about the thoughts presented below.

The recent studies have reported that especially on some wireless access 
networks there are delays that can trigger a spurious TCP RTO even though 
no packets are actually lost. Spurious RTOs result in two unwanted 
phenomena: a) the last window of segments is often unnecessarily 
retransmitted, b) the congestion window is unnecessarily reduced. The 
Eifel work has contributed to solving these problems by using the TCP 
timestamp option for detecting the spurious RTOs.

In the University of Helsinki we have recently been working on an 
alternative RTO recovery algorithm at the TCP sender that avoids the 
unnecessary retransmissions after a spurious RTO without using TCP 
timestamps. The algorithm is documented in a report available at
http://www.cs.Helsinki.FI/research/iwtcp/papers/f-rto.pdf
(*.ps and *.ps.gz are also available)

Our algorithm proposal, called "Forward RTO-Recovery" (or F-RTO) is ACK 
clocked and conforms to the TCP congestion control requirements by not 
injecting any more packets to the network than the conventional slow start 
would do. The main design motivation was to guarantee that although the 
F-RTO should improve performance after spurious RTOs, it should perform 
equally well to the conventional algorithm when RTOs are not spurious. In 
other words, there should be no reason for not using the F-RTO algorithm 
instead of the conventional go-back-N retransmissions after RTO.

The performance experiments reported in the paper indicate that when 
spurious RTOs occur, the F-RTO algorithm improves the performance over the 
standard recovery, having approximately similar throughput to Eifel. F-RTO 
also avoids problems found in Eifel performance when a burst of ACKs are 
lost. I posted a message describing the problem a few weeks earlier on 
this list.

The algorithm modifies the TCP sender behaviour after an RTO in the 
following way:
1. When RTO occurs retransmit the first unacknowledged segment and
   adjust ssthresh as specified in RFC 2581.
2. When the first ACK after RTO arrives:
   a) if ACK advances window, transmit two new previously untransmitted
      segments. Set cwnd <- ssthresh.
   b) if ACK is duplicate, revert to the conventional retransmission
      algorithm, set cwnd <- 1 * MSS.
3. When the second ACK after RTO arrives:
   a) If the ACK advances window, continue transmitting new previously
      untransmitted data and exit the recovery phase.
   b) If the ACK is duplicate, set cwnd <- 3 * MSS, and retransmit
      unacknowledged data in slow start.

If there are no new data to send, or the advertised window limits the 
transmission in branch 2a), the TCP sender reverts to the conventional 
retransmission algorithm. If the TCP sender ends up algorithm branch 3a), 
at least one non-retransmitted data segment has been acknowledged, which 
is a strong indication of a spurious RTO. If there are segments lost in 
the last window of data after entering branch 3a), the sender should be 
able to retransmit the segments by using fast recovery, because the 
(New)Reno bugfix should is not needed in this case. Obviously, using 
limited transmit improves the performance further in these cases. If 
either of the two ACKs following RTO indicate something suspicious, i.e. 
are dupacks, the TCP sender reverts to the conventional behaviour.

This algorithm should perform well when combined with Eifel or D-SACK. I 
think the retransmission logic after an RTO should be as described in the 
F-RTO algorithm, and the congestion control undoing can then be carried 
out independently of the retransmission algorithm based either on SACK 
blocks (D-SACK) or timestamps (Eifel).

Do you find any problems in the F-RTO approach?

- - Pasi

- -- 
http://www.cs.helsinki.fi/u/sarolaht/

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg