WB-RTO: A Window-Based Retransmission Timeout Ioannis Psaras, Vassilis Tsaoussidis Demokritos University of Thrace, Xanthi, Greece

WB-RTO: A Window-Based Retransmission Timeout

Ioannis Psaras, Vassilis Tsaoussidis

Demokritos University of Thrace, Xanthi, Greece

COMputer NETworks Group (COMNET)

2

Motivation and Contribution We observe that retransmission

scheduling affects transmission scheduling

WB-RTO results in: 50% less retransmitted pkts Higher Goodput, and Better Fairness

than TCP-RTO TCP-RTO

WB-RTO


3

Motivation-Contribution

Perspective: When contention increases, the timeout becomes the scheduler for

the link.

Motivation: When contention is high, all flows measure similar RTTs. TCP-RTO should not be solely based on RTT measurements. Congestion events cause retransmission synchronization.

Algorithm: Approximation of the current level of network contention Estimation of the contribution of each flow to congestion Allowance for asynchronous retransmissions when timeout happens.


4

Motivation Queuing Policy: DropTail DBP = Buffer Size = 10 pkts 5 participating flows 1500 sec total simulation time Flows ideal rate = 2 pkts/wnd We trace: Seqno progress, RTT,

RTOSequence Number

RTT (in secs)Dumbbell Network Topology


5

Motivation

For the TCP-RTO performance, we observe: RTT stabilization Similar timeout values ~3000 retransmitted packets

in 1500 seconds Un-Fairness

We investigate the impact of retransmission synchronization on system behavior (e.g. overhead)

RTO (in secs)

TCP Performance


6

Outline of the presentation

The current Retransmission Timeout Algorithm Recent Related Work The proposed algorithm: WB-RTO

The algorithm Expected Behavior

Evaluation Plan Experimental Results


7

The current Retransmission Timeout Algorithm

Upon each ACK arrival, the sender: Calculates the RTT Variation:

Updates the expected RTT prior to calculating the timeout:

Calculates the Retransmission Timeout value:


8

Recent Related Work Eifel RTO Algorithm

Uses the timestamp option to detect a spurious timeout. Forward RTO Algorithm

Uses the first 3 ACKs after the timeout to decide if the timeout was spurious or not.

Peak-Hopper RTO Algorithm Uses 2 timers: one is aggressive and one is conservative.

Each time it decides which one to follow. CA-RTO: A Contention-Adaptive RTO

Integrates a contention-adaptive parameter and introduces random retransmission scheduling.


9

The 3 stages of WB-RTO

1. Contribution to Congestionpenalty charge

2. Estimation of Contentiondetermine the scale of possible values

3. Calculation of Timeout


10

Window-Based RTO (1/4): Proportional Timeout

Estimation of the contribution of the flow to congestion:

c = f(cwnd , max cwnd ) Compare the current cwnd_ with the max_cwnd_:

If cwnd_ < max_cwnd_ / 2, c = 1: minimal charge

If max_cwnd_ / 2 < cwnd_ < (3/4)* max_cwnd_, c = 1,5: medium charge

If (3/4)* max_cwnd_ < cwnd_ < max_cwnd_, c = 2: major charge


11

Window-Based RTO (2/4): Contention Estimation

Flow classification according to its cwnd_ history (awnd_):

ai = g(awnd , Thresholdi)where, awnd=average window, Thresholds 1 to 4 represent

different levels of network contention: Threshold 1 corresponds to very high contention Threshold 4 corresponds to low contention Example:

3. 10 < awnd_ < 30: a3 = 34. 30 < awnd_ < 50: a4 = 2

1. awnd_ < 5: a1 = 102. 5 < awnd_ < 10: a2 = 5


12

Adjust the scale


13

Window-Based RTO (3/4): Timeout Adjustment

Calculation of the Window-Based RTO:

WB − RTO = random(rtt, c × ai)or

WB − RTO = random(rtt, f(cwnd , max cwnd ) × g(awnd , Thresholdi))

1. rtt, to avoid timeout expiration prior to the estimated RTT measurement

2. Parameter c captures the contribution of the flow to congestion

3. Parameter a approximates the current level of flow contention

4. Randomization guarantees asynchronous retransmission attempts


14

Window-Based RTO (4/4): Expected Behavior

High penalties result in high timeout values.

As awnd_ increases timeout settles to smaller values.

So, Large windows do not

always mean large timeout values.

WB-RTO vs awnd_


15

Performance Evaluation Plan

WB-RTO is implemented in TCP-Reno

Evaluation ScenariosMotivation Part ScenarioScenario 1: Standard/Proposed ParametersScenario 2: Modified Parameters


16

An Important Note…

WB-RTO does not improve the Goodput performance of TCP significantly

We focus on concurrent Retransmissions

hence we pay more attention on the combination of the

retransmission effort and the Goodput performance, rather than on the Goodput performance alone.


17

Scenario 1 Queuing Policy: DropTail Bottleneck BW = 10Mbps Bottleneck Delay = 10ms Buffer Size = 50 pkts 1500 sec total simulation time

Goodput (in B/s)

Retransmitted Packets


18

Scenario 1

Contention grows->WB-RTO allows for better multiplexing

Behavior Captured by fairness index

More flows are getting service

Fairness

Goodput per Flow (B/s)


19

Scenario 2 Queuing Policy: DropTail Bottleneck BW = 10Mbps Bottleneck Delay = 10ms Buffer Size = 50 pkts 1500 sec total simulation time Scale now different

Goodput (in B/s)

Retransmitted Packets


20

Scenario 2

Fairness initially drops when the scale is not adjusted appropriately

Fairness

Goodput per Flow (B/s)


21

Interaction with AQM (i.e. RED) (1)

Topology: Dumbbell Queuing Policy: RED DBP = Buffer Size = 40 pkts min_thresh = 4 pkts max_thresh = 12 pkts 1500 sec total simulation time Goodput (in B/s)

Retransmitted PacketsNumber of Timeouts


22

Interaction with AQM (i.e. RED) (2)

We observe: Similar Goodput Significant difference in

Retransmission Effort (50%) WB-RTO results in 66% less

timeout expirations TCP-RTO causes inefficient

queue utilization The average queue length

always overcomes the max_thresh, when using TCP-RTO

TCP-RTO

WB-RTO


23

Satellite Scenario (1)

Topology: Cross-Traffic Bottleneck Queuing Policy: RED The rest of the buffers use DT bw_bottleneck = 20Mbps bw_delay = 300ms Buffer Size = 200 pkts min_thresh = 20 pkts max_thresh = 60 pkts 150 sec total simulation time PER = 0,0001 3 blackouts on the backbone link

No blackout

After 3 blackouts


24

Satellite Scenario (2)

We observe that: TCP-RTO interprets the

blackout as a congestion signal

WB-RTO does not extend the timeout, due to low contention and hence exploits bandwidth faster

TCP still waits for the extended timeout to expire,

while WB-RTO resumes

transmission immediately

TCP-RTO

WB-RTO


25

Traffic Diversity (Mice and Elephants) (1)

Topology: Dumbbell Bottleneck Queuing Policy: RED bw_bottleneck = 10Mbps bw_delay = 30ms Buffer Size = 40 pkts

Goodput (KB/s)

Retransmitted PacketsGoodput per flow (KB/s)


26

Traffic Diversity (Mice and Elephants) (2) We observe:

Simultaneous timeout events for TCP-RTO

All flows timeout during the Slow-Start

Flows 7-9 timeout simultaneously 10 times during the experiment

Short flows: 83 vs 50 timeouts Long flows: 43 vs 12 timeouts

We conclude that: most of the timeouts are

spurious WB-RTO achieves an

important goal: it reduces the number of timeouts

TCP-RTO

WB-RTO


27

Conclusions RTT measurements cannot always reflect the level of network

contention TCP-RTO should not be solely based on RTT samples A contention-aware RTO proves to be more efficient, since it

is aware of current network conditions. A randomization factor in the RTO schedules retransmissions

in a fairer manner WB-RTO cancels some of TCP miss-responses with non-

congestion errors


28

Other References

[1] “CA-RTO: A Contention-Adaptive Retransmission Timeout for TCP”, Ioannis Psaras, Vassilis Tsaoussidis,

IEEE ICCCN 05

[2] “Why TCP Timers (still) Don’t Work Well”, Ioannis Psaras, Vassilis Tsaoussidis,

Computer Networks (COMNET), Elsevier Science, to appear 2007

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

Documents

WB-RTO: A Window-Based Retransmission Timeout Ioannis Psaras, Vassilis Tsaoussidis Demokritos University of Thrace, Xanthi, Greece