The TCP Minimum RTO Revisited

Ioannis Psaras and Vassilis Tsaoussidis

(ipsaras, vtsaousi)@ee.duth.gr

COMputer NETworks (COMNET) Group

Democritus University of Thrace, Xanthi, Greece

http://comnet.ee.duth.gr/

The TCP Minimum RTO Revisited – s.1/23

Introductory Notes

According to RFC 2988 (Computing TCP’sRetransmission Timer):

1. RTO = SRTT + 4 × RTTV AR,

2. RTO ≥ 1 second (i.e., Minimum RTO)

The Minimum RTO protects TCP against spurioustimeouts caused by:

1. coarse-grained clocks (500ms for most OSs at thattime, i.e., Nov. 2000)

2. the Delayed Acknowledgments (usually set to 200ms), RFC1122

The TCP Minimum RTO Revisited – s.2/23

Our Contribution

• We re-examine the two reasons for theconservative 1-second Minimum TCP-RTO:1. the OS clock granularity, and2. the Delayed ACKs.

• We find that reason 1 is canceled in modern OSs,• We carefully design a mechanism to deal with

reason 2.• We show (through simulations) that in next

generation’s high-speed, wireless-accessnetworks, TCP-RTO should not be limited by afixed, conservative lower bound.

The TCP Minimum RTO Revisited – s.3/23

Cost Function

We define a Cost Function to capture the impact of theMinimum RTO to TCP’s performance:

C(f) = RTOmin

RTOcurrent

• If C(f) ≤ 1, the Minimum RTO adds no extrawaiting time.

• Otherwise, the Minimum RTO will negativelyimpact TCP Throughput.

The TCP Minimum RTO Revisited – s.4/23

Clock Granularity (1/5): Motivation

We simulate a coarse-grained flow (i.e., G=500ms)over a 500ms Round-Trip Propagation Delay (RTPD)path, to observe:

1. the rationale behind the conservative 1-secondMinimum RTO setting, and

2. the impact of the Minimum RTO value relativelywith the actual TCP-RTO value.

The TCP Minimum RTO Revisited – s.5/23

Clock Granularity (2/5): Observations

We observe that:

1. C(f) < 1 (no negative impact on TCP Throughput),

2. the Minimum RTO is only needed as a safetymargin.

10

12

14

16

18

20

22

24

9.5 10 10.5 11 11.5 12 12.5 13 13.5 14

Seq

uenc

e N

umbe

r

Time (s)

DATA pktACK

RTOmin RTO

(a) G = 500ms, RTPD = 500ms

420

425

430

435

440

15 15.5 16 16.5 17 17.5

Seq

uenc

e N

umbe

r

Time (s)

DATA pktACK

RTOmin RTO

(b) G = 500ms, RTPD = 6ms

Figure 1: 500ms Clock GranularityThe TCP Minimum RTO Revisited – s.6/23

Clock Granularity (3/5): OS Details

Table 1: Details on Modern OSsOS Clock Granularity Delayed ACKWindows 15-16ms 200msSolaris 10ms 50-100msLinux ≤ 25ms Dynamically Set

• We repeat the above experiment using, this time, afiner-grained clock of 10ms.

The TCP Minimum RTO Revisited – s.7/23

Clock Granularity (4/5): Impact

• C(f) ≈ RTOmin

T (ACK Arr) ≤RTOmin

RCG+RTPD+QD≈ 62.5

1450

1455

1460

1465

1470

1475

1480

7.2 7.4 7.6 7.8 8 8.2 8.4 8.6

Seq

uenc

e N

umbe

r

Time (s)

DATA pktACK

RTOmin RTO

Figure 2: G = 10ms, RTPD = 6ms

The TCP Minimum RTO Revisited – s.8/23

Clock Granularity (5/5): Conclusions

We conclude that:

1. the clock granularity should not be a matter ofconcern for the setting of the Minimum RTO, and

2. the conservative 1-second Minimum RTO will havemajor impact on TCP’s performance, in case ofpacket losses.

The TCP Minimum RTO Revisited – s.9/23

Delayed ACKs (1/6): Notes

• TCP sends D back-to-back packets, according toRFC 2581:D = snd.una + min(cwnd, rwnd) -snd.nxt.

• TCP does not know the application’s sendingpattern.

• Only the ACK of the last packet of the "train" ofback-to-back packets may be delayed.

• Every 2nd packet will always be ACKed.

The TCP Minimum RTO Revisited – s.10/23

Delayed ACKs (2/6): An Example

• At time t0 all previously transmitted packets arealready ACKed.

• D = 4: (or generally D: even)• The client will ACK the 2nd and 4th packets.• No Delayed ACKs ⇒ no need for extended

Minimum RTO.• D = 3: (or generally D: odd)

• Client will ACK the 2nd packet and will triggerthe DelACK timer for the 3rd packet.

• The 3rd packet’s ACK may be Delayed ⇒ extendthe Minimum RTO, for the 3rd packet only.

The TCP Minimum RTO Revisited – s.11/23

Delayed ACKs (3/6): Algorithm States

The proposed mechanism operates in one of thefollowing States:

• State 1: "noMINRTO". Do not apply extendedMinimum RTO to any outgoing packet (i.e., thereceiver will always ACK the last packet of theback-to-back train of packets); set set_odd tofalse.

• State 2: "extended MINRTO". Apply extendedMinimum RTO to the last packet of the next train ofback-to-back packets; set set_odd to true.

The TCP Minimum RTO Revisited – s.12/23

Delayed ACKs (4/6): State Diagram

1st packet of the Slow-Start phase

extend MINRTOset_odd:false

noMINRTOset_odd:false

extend MINRTO for last pkt of trainset_odd:true

D:even D:odd

D:odd

D:odd

D:evenD:even

Figure 3: State Diagram

The TCP Minimum RTO Revisited – s.13/23

Delayed ACKs (5/6): Example

1476

1478

1480

1482

1484

1486

1488

1490

7 7.2 7.4 7.6 7.8 8

Seq

uenc

e N

umbe

r

Time (s)

2 pkts b2b

2 pkts b2b

3 pkts b2b

2 pkts b2b

2 pkts b2b

2 pkts b2b

The ACK of the last b2bpkt may be delayed.

Extend the Minimum RTO

DATA pktACK

RTOmin RTO

Figure 4: Modeling ACKs ArrivalThe TCP Minimum RTO Revisited – s.14/23

Delayed ACKs (6/6): Impact

RTOmin =

{

R ms, for the last pkt if set_odd = 1,

RTOcur, otherwise,

where R is a fixed, extended value for the MinimumRTO.

C(f) =

{

R msRTOcur

, for the last pkt if set_odd = 1,

1, otherwise.

The TCP Minimum RTO Revisited – s.15/23

Performance Evaluation (1/2)

• TCP version: Reno• SACK: enabled• Timestamps: enabled• Spurious response: enabled• Delayed ACK Timer: 200ms• Granularity: 10ms• Buffers use RED, Buffer size = BDP• We measure the System Goodput:

Goodput = Original_DataConnection_time

The TCP Minimum RTO Revisited – s.16/23

Performance Evaluation (2/2)

We compare the proposed algorithm with threedifferent TCP implementations:

1. Linux TCP: Minimum RTO = 200ms

2. Solaris TCP: Minimum RTO = 400ms

3. IETF Proposal (RFC 2988): Minimum RTO = 1s(probably Windows TCP)

The TCP Minimum RTO Revisited – s.17/23

Results (1/4): The Need for aStandard Mechanism (1/2)

IfSrv′s Min RTO < RTPD + QD + Clnt′s DelACK Timer

andMinimum RTO > RTOcur,then the TCP server will spuriously timeout every timean ACK is delayed and D = 1.

The TCP Minimum RTO Revisited – s.18/23

Results (2/4): The Need for aStandard Mechanism (2/2)

596

598

600

602

604

606

608

36 36.1 36.2 36.3 36.4 36.5 36.6 36.7 36.8

Seq

uenc

e N

umbe

r

Time (s)

Spurious Retransmission

DATA pktACK

RTOmin RTO

(a) Linux Server - 200ms Delayed

ACK Client (e.g., Windows client)

596

598

600

602

604

606

608

36 36.1 36.2 36.3 36.4 36.5 36.6 36.7 36.8

Seq

uenc

e N

umbe

r

Time (s)

Extended Minimum RTOto avoid spurious Timeout

DATA pktACK

RTOmin RTO

(b) Modified Linux Server - 200ms

Delayed ACK Client (e.g., Win-

dows client)

Figure 5: The Need for a Standard Mechanism

The TCP Minimum RTO Revisited – s.19/23

Results (3/4): Long FTP Flows (1/2)

Figure 6: Simulation Topology

Table 2: Experiment DetailsPER TCP Flows bw_bb

Fig. 7(a) see Fig. 3 6 MbpsFig. 7(b) 3% see Fig. 100 MbpsFig. 7(c) 3% 500 see Fig.

The TCP Minimum RTO Revisited – s.20/23

Results (4/4): Long FTP Flows (2/2)

Packet Error Rate (%)2 3 4 5

Goo

dput

(B

/s)

050000

100000150000200000250000300000350000400000

IETF Solaris Linux noMINRTO

(a) Increasing PER

Number of Participating Flows20 40 60 80 100

Goo

dput

(B

/s)

0

2e+06

4e+06

6e+06

8e+06

1e+07

IETF Solaris Linux noMINRTO

(b) Increasing TCP Contention

Backbone Bandwidth Capacity (Gbps)2 4 6 8 10

Goo

dput

(B

/s)

01e+072e+073e+074e+075e+076e+077e+07

IETF Solaris Linux noMINRTO

(c) Increasing Bandwidth Capacity

Figure 7: Impact on Long FTP FlowsThe TCP Minimum RTO Revisited – s.21/23

Conclusions

1. The conservative 1-second Minimum RTO settingcauses severe TCP performance degradation.

2. The Minimum RTO setting is not needed, since:• modern OSs use fine-grained clocks, and• the proposed algorithm deals with the Delayed

ACK response.

3. The proposed algorithm:• may improve TCP performance up to 50%,• effectively avoids spurious timeouts, and• overcomes communication inconsistencies,

caused by the absense of official instructionsregarding the Minimum RTO setting.

The TCP Minimum RTO Revisited – s.22/23

Thank you!Questions?

Ioannis Psarashttp://utopia.duth.gr/~ipsaras

The TCP Minimum RTO Revisited – s.23/23