ca-rto: a contention-adaptive retransmission timeout

CA-RTO: A Contention-Adaptive Retransmission Timeout

I. Psaras, V. Tsaoussidis, L. MamatasDemokritos University of Thrace, Xanthi, Greece

This study was presented in the International Conference on Computer Communications and Networks (ICCCN 2005)

COMputer NETworks Group (COMNET)

2

Contributions of this work Our perspective:

When contention increases, the timeout becomes the scheduler for the link

Our observations: When contention increases, timeout decreases! Congestion events cause synchronization, at least to some extend.

Our solutions: We integrate a contention adaptive parameter into the timeout

algorithm Unnecessary retransmissions are reduced

We introduce randomness to avoid synchronization


3

Research Steps We investigated the timeout behavior towards various types of contention We observed that when contention increases, RTO undertakes the role of

the transmission scheduler for the link We focused on scenarios with high contention

RTT can not always capture efficiently the network conditions RTO is a bad scheduler for the link

We fixed the timeout value to correspond to different contention levels We concluded that different levels of contention call for distinct timeout

adjustments We ran simulation results


4

TCP Retransmission Timeout The timer is adaptive to varying delay The timeout is calculated every RTT Given a sample RTT measurement M and the history of

average RTT A, the distance from the average is measured:

Diff = M – A, the average is updated:

A = A + gDiff (where g=0.125), the RTT Deviation is calculated:

Dev = Dev +d(|Diff| – Dev) (where d = 0.25) and finally, the RTO value is adjusted to:

RTO = A + 4D


5

Observations: Anomalies of the TCP

Retransmission Timer

SCENARIO Setup

Dumbbell Topology DropTail: 50 pkts BxD = 10 packets Contention Increase 0 – 250s: 1 flow 250 – 500s: 100 flows


6

Contention Grows, Timeout Shrinks Contention Increase Scenario

RTT RTO = A + 4D


7

Contention Grows, Timeout Shrinks

Contention Increase Scenario

RTO = A +4 D


8


`

Router Router’s Buffer

Some flows always find some empty space

Some flows always get rejected

√

Every arriving packet will occupy the last position, if it comes from the Lucky group of flows

X


9


In this case: 4D 0 Hence, RTO = A1. Timeout Decreases instead of Increasing (there is no

Deviation)2. Smoothed RTT (A) does not differentiate between

different flows3. Synchronization is possible (although buffers are always

full)4. Fairness is not guaranteed


10

The Proposed Algorithm (CA-RTO)

CA-RTO: RTO = A + 4D + c*p We incorporate contention: c = 1/cwnd_ cont_diff_ = max_cwnd_ - cwnd_ cont_diff_ = cont_diff_ / 100 We introduce retransmission randomness: p = Random(0, cont_diff_) CA-RTO: RTO = A + 4D + c*p


11

Behavior of theProposed Algorithm (CA-RTO)

The max_cwnd_ ever reached is 200pkts

Step 1: c = 1/cwnd_

Step 2:cont_diff_ = max_cwnd_ - cwnd_

cont_diff = cont_diff_/100

c = 1/cwnd_

0

0,02

0,04

0,06

0,08

0,1

0,12

10 20 30 40 50 60 70 80 90 100 150 200

Congestion Window

Par

amet

er c

c = 1/cwnd_

Contention Difference (max_cwnd_=200)

00,20,40,60,8

11,21,41,61,8

2

10 20 30 40 50 60 70 80 90 100 150 200

Congestion Window

con

t_d

iff_


12


Step 3:p = Random(0, cont_diff_)

Finally:

CA-RTO = RTO + c*p

Randomization Factor p (max_cwnd_=200)

0

0,5

1

1,5

2

10 20 30 40 50 60 70 80 90 100 150 200

Congestion Window

Par

amet

er p

Factor c*p (max_cwnd_=200)

00,020,040,060,080,1

0,120,140,160,180,2

10 20 30 40 50 60 70 80 90 100 150 200

Congestion Window

c*p


13


Contention Increase Scenario

CA-RTO = RTO + c*p


14

Behavior of theProposed Algorithm (CA-RTO)Small congestion window: gives big value to parameter cc = 1/cwnd_

may result in big cont_diff_cont_diff_ = max_cwnd_ - cwnd_

Big congestion window: gives small value to parameter c results in small cont_diff_

We do not want to affect RTO’s performancein low contention scenaria

We try to capture high contention

We get aware of dynamic network conditions, e.g. contention increase


15

Possible Further Enhancements The algorithm may “punish” flows with small windows by

extending their RTO value (e.g. during startup) maybe a parameter indicating the history of cwnd_ has to be integrated instead of the current cwnd_

The current mechanism used to capture contention may not be very accurate

The randomization factor used to split flows in time can be further improved


16

Evaluation Methodology We target high contented links/networks We simulate large numbers of flows transmitting in low

capacity channels

Hence: Fair-share is small Flows are operating with small windows Buffers are always full


17

Evaluation Methodology

We use the dumbbell network topology

Bandwidth x Delay = 10 or 100 packets

We use both DropTail and RED queuing policies

We implement CA-RTO in TCP-Reno and compare the two versions

We measure Goodput, Throughput, Fairness and Number of Retransmitted Packets


18

Experimental ResultsScenario 1

B x D = 10 packets Buffer size = 50 packets, DropTail

Fairness Retransmitted Packets(up to 0.2 Index Points) (up to 4000 less retransmissions)


19


Throughput (in Bps) Goodput (in Bps)


20


B x D = 100 packets Buffer size = 100 packets, DropTail

Fairness Retransmitted Packets (at least 0.15 Index Points) (25 % less retransmissions, 4500pkts)


21


bw_bb = 100Mbps, B x D = 250 pkts Buffer size = 100 packets, DropTail CA-RTO affects TCP’s performance only if needed…

Goodput


22


B x D = 10 packets Buffer size = 50 packets, DropTail Packet Error Rate: 10%

Fairness Index Retransmitted Packets


23

Conclusions Current RTO presents some behavioral anomalies

when contention increases A Contention-Adaptive RTO proves to be more

efficient in terms of successful retransmissions. That calls for further investigation of the energy potential of CA-RTO

A Randomization Factor in the RTO schedules the participating flows in a more fair manner


24

CA-RTO: A Contention-Adaptive Retransmission Timeout

Thank you!!

ca-rto: a contention-adaptive retransmission timeout

Documents