delayed congestion response protocols

1

Delayed Congestion Response Protocols

Thesis By Sumitha BhandarkarUnder the Guidance of Dr. A. L. N. Reddy

2

Layout of the presentation

• Introduction to “TCP-Friendliness”

• Motivation for Delayed Congestion Response Protocols

• Delayed Congestion Response Protocols

• Conclusions And Future Work

• Related Work

3

Introduction to “TCP-Friendliness”

• Stability of internet depends on protocols that respond to congestion

• Congestion Control Algorithm of TCP results in drastic changes in sending rate

• When used with real-time audio/video application, this will cause drastic changes in user perceived quality

• UDP looks like a good alternative for such applications

4

Introduction to “TCP-Friendliness” (contd.)

• Extensive use of UDP could result in

• Extreme unfairness to existing TCP applications

• Congestion collapse of the internet

• Lot of interest in new class of protocols called “TCP-Friendly” Protocols

• “TCP-Friendliness” indicates that the protocol chooses to send at a rate no higher than TCP under similar conditions of round trip delays and packet losses

5


An analytical model for TCP was developed by J. Padhye et. al. which shows -

T = S

R 2p/3 + TRTO (3 3p/8) p ( 1 + 32p2)

T : Throughput

S : Packet Size

R : Round Trip Time

TRTO : Retransmission Timeout

p : Loss Rate

6


• Simplified Throughput Equation

3/2T =

R * p

• In a very general sense a protocol which maintain the sending rate to at most some constant over the square root of the packet loss rate is said to be “TCP-friendly”.

7

Motivation For Delayed Congestion Response Protocols

• Congestion in the network is notified to the protocol, in most cases, through packet drops.

• TCP as well as most of the TCP-friendly protocols reduce the sending rate once and as soon as allowed by protocol design, when a packet drop is noticed.

• By delaying congestion response by ‘’ RTTs, the transport protocol can provide application with an early warning regarding an impending reduction in sending rate.

8

Motivation For Delayed Congestion Response Protocols (contd.)

• Smart applications can be designed to combine Early Notification with buffering techniques to provide smooth output.

• For applications that cannot take advantage of early notification, smooth sending rate can be provided by reducing the congestion window smoothly, during the period ‘’ after a packet drop.

• By studying the time scales over which we can delay the congestion response insight can be gained regarding the time scales for defining “TCP-Friendliness”.

9

C w

n d

Delayed Congestion Response Protocols

• Protocols where response to congestion is deliberately delayed by ‘’ RTTs when a congestion is notified.

• Congestion control dynamics characterized by (f1(t), f2(t), , ).

f1(t)

f2(t)Pkt Drop

Time

10

DCR-I• f2(t) is an increasing function

• For simplicity of implementation and analysis we set

• f1(t) as an additive function.

• f2(t) = f1(t).

C w

n d

f1(t)

f2(t)Pkt Drop

Time

11

DCR-I

• Thus we have,

f1(t) : wt+R wt + ; > 0

f2(t) : wt+R wt + ; > 0 , tdrop < t < tdrop +

wtdrop + * wtdrop + - ; < 1

wt is the congestion window at time tR is the RTT

, and are constants

12

C w

n d

f1(t)

f2(t)Pkt Drop

Time

DCR-ISteady State Analysis

A

Throughput = Number of packets between two successive drops

Time between two successive drops

t2+t1 t2

13

DCR-ISteady State Analysis (contd.)

( /2 ) ( 1 + ) / ( 1 - )

= R p

Comparing with the TCP-equation, the condition of TCP-Friendliness is :

3 ( 1 - ) =

( 1 + )

Infinite number of values can be chosen for and that satisfy the above condition . We chose = 1 and = 1/2 since it is makes DCR-I very similar to TCP-reno.

14

DCR-IImplementation

• Testing platform was ns-2

• Modifications were made to the existing TCP-reno.

• When congestion in the network was notified, the time-to-response was noted.

• Congestion window was continuously increased until the time-to-response, at which time it was cut down by half.

15

DCR-D

• Primary aim of DCR-D is to provide smooth response.

• f2(t) is thus chosen to be a decreasing function and is set to1.

C w

n d

f1(t) f2(t)

Pkt Drop

Time

16

DCR-D

•We have,

f1(t) : wt+R wt + ; > 0

f2(t) : wt+R * wt ; 0 < < 1, tdrop < t <tdrop +


, and are constants

17

t2+

C w

n d

f1(t) f2(t)

Pkt Drop

Time

DCR-DSteady State Analysis

Throughput = Number of packets between two successive drops

Time between two successive drops

N1 N2

t1 t2

18

DCR-DSteady State Analysis (contd.)

• Set K = , the factor by which the congestion window is decreased over the period of ‘’ RTTs

1

• = R (2p(1-K)/(1+K) + p ([2(1-K)/lnK(1+K)] +

1))

• The above equation is TCP-Friendly if second term in the denominator is negligible

19


• Condition for TCP-Friendliness is :

p 2 . (1-K) + 1 = 0lnK (1+K)

• For different values of K, the results of the above equation is given as follows -

K f(K)0.9 0.0009

0.8 0.0041

0.7 0.0105

0.6 0.02120.5 0.03820.4 0.0646

0.3 0.10550.2 0.1716

0.1 0.2893

20


• With K = 0.8, the throughput equation can be written as1

= R (2p(1-K)/(1+K) + 0.0041* p)

• Second term in the denominator is negligible.

• Comparing the above equation with TCP equation we have,

3 ( 1-K) =

(1+K)

• With K = 0.8, = 0.333

21

DCR-DImplementation

• Testing platform was ns-2 with modifications made to the existing TCP-reno.

• Two modes of operation

• Increase mode : seeking bandwidth using f1(t)

• Decrease mode : reducing bandwidth using f2(t)

• On congestion notification start a delay timer for ‘’ RTTs and get into decrease mode.

• When the delay timer expires return to Increase mode.

22

DCR-DImplementation(contd.)

• While entering the decrease mode note down the target value of the congestion window to be achieved at the end of decrease mode.

• If packet is dropped in decrease mode,

• Reset the delay timer.

• Reduce the congestion window to its target value drastically.

• Set a new delay timer to take care of latest congestion.

• Note down the current target value.

Reasoning: Packet drop during decrease mode indicates high level of congestion. Thus drastic reduction in congestion window is required as compared to the smooth reduction using f2(t) .

23

DCR-DCongestion Window Evolution at High Droprates

C w

n d

TargetValue

Pkt Drop

Time

Pkt Drop

Original Timer New

Timer

24

DCR-C

• f2(t) is an constant functionC

w n

d

f1(t)

Pkt Drop

Time

f2(t)

25

DCR-C

• We have,

f1(t) : wt+R wt + ; > 0

f2(t) : wt+R wt ; tdrop < t <tdrop +

wtdrop + * wtdrop + - ; < 1


, and are constants

• Analysis shows this protocol cannot be TCP-Friendly. So simulations were not conducted for this protocol.

26

Simulation Topology

R1

Src 1

R2

Sink 1

Sink 2

Sink n

Src 2

Src n

.

.

.

.

.

.

.

.

.

.

Bottleneck Link

B MbpsD ms

27

Simulation ResultsDCR-I

Fairness Index at Different Droprates

Fairness Index of DCR-I at different droprates.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0 5 10 15 20 25

tau (in RTT)

Fairn

ess

Inde

x

1.3 - 1.5% 3.4 - 3.7%

5.4 - 6.0% 7.8 - 8.5%

10.1 -10.8% 12.1 - 12.8%

13.8 - 14.4%

28

Simulation Results DCR-I

Fairness Index at Different Buffer SizesFairness Index of DCR-I different bufersizes.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0 5 10 15 20 25

tau (in RTT)

Fairn

ess

Inde

x 0.5*Delay*BW (12.5 packets)

1*Delay*BW (25.0 packets)





29


Fairness Index with mixed workloadFairness Index of DCR-I with mixed workload.

00.20.40.60.8

11.21.41.61.8

0 5 10 15 20 25

tau (in RTT)

Fai

rnes

s In

dex

1 Reno + 15 DCR-I

3 Reno + 13 DCR-I

6 Reno + 10 DCR-I

8 Reno + 8 DCR-I

10 Reno + 6 DCR-I

13 Reno + 3 DCR-I

15 Reno + 1 DCR-I

30


Sample per-flow droprates for mixed workload

1 Reno + 15 DCR-I 8 Reno + 8 DCR-I 15 Reno + 1 DCR-Itau TCP-reno

perflowdroprate (%)

DCR-Iperflow

droprate (%)

TCP-renoperflow

droprate (%)

DCR-Iperflow

droprate (%)

TCP-renoperflow

droprate (%)

DCR-Iperflow

droprate (%)

2 1.669 2.381 1.755 1.719 1.632 1.330

4 1.662 3.060 1.739 1.667 1.607 1.256

6 1.719 3.101 1.711 1.676 1.618 1.0678 1.608 3.294 1.787 1.707 1.657 1.209

10 1.646 3.391 1.886 1.699 1.642 1.343

15 1.365 3.300 1.749 1.729 1.639 1.063

20 1.253 3.117 1.849 1.755 1.630 1.288

31


Fairness Index at Different Droprates with Drop Tail Router

Fairness Index of DCR-I at different droprates.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

2.2

0 5 10 15 20 25

tau (in RTT)

Fairn

ess

Inde

x

1.00% 2.7 - 3.0%

4.5 - 5.0% 6.2 - 6.6%

7.6 - 8.0% 8.8 - 9.3%

32


Sample values of per-flow droprates (Drop Tail Router)

Bottleneck Link Droprate: 4.5 - 5.0%tau reno perflow

droprate(%)DCR-I

perflowdroprate(%)

linkdroprate(%)

2 5.013 4.286 4.5864 5.793 4.099 4.7486 5.639 4.206 4.7588 5.807 4.142 4.75910 5.867 4.147 4.77415 6.127 4.181 4.86720 6.487 4.214 4.977

33


Effects of Clock Resolution

DCR-I Effects of TCP Clock Resolution.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

0 2 4 6 8 10 12

tau (in RTT)

Fairn

ess

Inde

x

100ms clk res

10ms clk res

34

DCR-D (alpha = 0.333, K = 0.8 )Fairness Index at varying tau for Different Droprates.

0

0.2

0.4

0.6

0.8

1

1.2

0 2 4 6 8 10 12

tau (in RTT)

Fai

rnes

s In

dex

1.0 - 1.3% 2.4 - 3.1%

4.1 - 5.1% 6.2 - 7.5%

9.4 - 10.4% 11.5 - 12.7%14.4 - 14.7%

Simulation Results DCR-D

Fairness Index at Different Droprates

35

DCR-D (alpha = 0.333, K = 0.8)Fairness Index at Varying tau for Different Buffer Sizes.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

0 2 4 6 8 10 12

tau (in RTT)

Fairn

ess

Inde

x

1 * Delay * BW (10.0 packets)3 * Delay * BW (30.0 packets)5 * Delay * BW (50.0 packets)

8 * Delay * BW (80.0 packets)10 * Delay * BW (100.0 packets)


Fairness Index at Different Buffer Sizes

36

DCR-D (alpha = 0.333, K = 0.8 )Fairness Index at varying tao with mixed workload

00.20.40.60.8

11.21.41.61.8

22.22.4

0 2 4 6 8 10 12

tau (in RTT)

Fairn

ess

Inde

x

1 reno + 15 DCR-D

3 reno + 13 DCR-D

6 reno + 10 DCR-D

8 reno + 8 DCR-D

10 reno + 6 DCR-D

13 reno + 3 DCR-D

15 reno + 1 DCR-D


Fairness Index with mixed workload

37


Sample per-flow droprates for mixed workload

1 reno + 15 DCR-D 8 reno + 8 DCR-D 15 reno + 1 DCR-Dtau TCP-reno

perflowdroprate (%)

DCR-Dperflow

droprate (%)

TCP-renoperflow

droprate (%)

DCR-Dperflow

droprate (%)

TCP-renoperflow

droprate (%)

DCR-Dperflow

droprate (%)

2 1.683 1.571 1.641 1.373 1.733 0.550

3 1.491 1.419 1.527 1.307 1.693 0.582

4 1.234 1.332 1.459 1.240 1.696 0.5335 1.150 1.270 1.387 1.206 1.679 0.556

6 1.139 1.195 1.308 1.183 1.652 0.615

7 1.072 1.153 1.300 1.136 1.675 0.493

8 1.040 1.097 1.239 1.106 1.669 0.485

9 1.030 1.055 1.211 1.108 1.691 0.425

10 0.919 1.011 1.180 1.068 1.661 0.473

38


Fairness Index at Different Droprates with Drop Tail RouterDCR-D (alpha = 0.333, K = 0.8)

Fairness Index at varying tao for Different Droprates (DropTail Router)

0

1

2

3

4

5

6

0 2 4 6 8 10 12

tau (in RTT)

Fairn

ess

Inde

x

0.9 - 1.1% 2.0 - 2.6%

3.4 - 4.3% 4.5 - 5.7%5.8 - 7.2% 7.8 - 9.2%

39


Sample values of per-flow droprates (Drop Tail Router)Bottleneck Link Droprate: 4.5 - 5.7%

tau TCP-reno perflowdroprate (%)

DCR-D perflowdroprate (%)

linkdroprate (%)

2 9.569 4.028 5.6583 9.584 3.763 5.4674 9.723 3.252 5.1015 9.622 2.990 4.9506 9.539 2.878 4.8567 9.584 2.751 4.7578 9.896 2.614 4.7149 10.110 2.500 4.657

10 10.015 2.373 4.547

40


Effects of Clock Resolution

DCR-D (alpha = 0.333, K = 0.8)Effects of TCP Clock Resolution.

0

0.2

0.4

0.6

0.8

1

0 2 4 6 8 10 12

tau (in RTT)

Fairn

ess

Inde

x

100ms clk res

10ms clk res

41


Effects of Clock Resolution With Compensated

DCR-D with compensated alpha (alpha = 1.0, K = 0.8)Effects of TCP Clock Resolution.

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0 2 4 6 8 10 12

tau (in RTT)

Fairn

ess

Inde

x

100ms clk res

10ms clk res

42

Simulation Results Measure of smoothness

• Protocols used with real-time audio-video application require smooth sending rates

• Use coefficient of variance as a measure of smoothness

• Note throughput at intervals of time

• For each flow compute the cov as (standard deviation) / (mean) of these values

• For the protocol, the cov is the average cov of all the flows using that protocol.

43


Coefficient of Variance at Different Droprates ( = 0.5s)

bottleneck link droprate (%) TCP-reno COV DCR-D COV1.7 0.4234 0.36282.1 0.4345 0.38982.5 0.4620 0.42773.1 0.4710 0.45704.1 0.4883 0.50204.9 0.5283 0.51715.8 0.5734 0.55416.9 0.6861 0.63598.2 0.8060 0.7243

12.0 0.8006 0.7243

44


Coefficient of Variance at Different values of (p = 0.1%)

delta (in seconds) TCP-reno COV DCR-D COV0.1 0.3725 0.25740.5 0.3184 0.17861 0.2961 0.17192 0.2581 0.16545 0.1960 0.1518

10 0.1511 0.132915 0.1242 0.1218

45

Conclusions

In this thesis, we have,

• provided the general frame work for Delayed Congestion Response protocols.

• examined three cases in particular and shown through analysis and simulations that two of these can be TCP-friendly for a wide range of network parameters.

• Using DCR-D, shown that sending rate can be made smoother through the proper design of the function f2(t).

46

Conclusions (contd.)

Regarding the TCP-Friendliness we have shown,

• 1/ p is necessary but not sufficient condition for determining TCP-Friendliness.

• TCP-Friendliness depends on the underlying buffer management scheme.

• TCP-Friendliness is affected by the type of workload on the system, even in the presence of an active buffer management scheme.

47

Future Work

• Work needs to be done in synthesizing the general equations to provide proper guidelines for choosing the values of (f1(t), f2(t),, ).

• Substantial work needs to be still done to characterize TCP-Friendliness

48

Questions ???

49

Related Work“ModelingTCP Throughput: A simple Model and its Empirical Validation” by J.Padhye, V. Firoiu, D.Towsley and J.Kurose.

• Developed an Analytical Model for TCP’s congestion control mechanism in terms of loss rate and RTT

• Captures the behavior of fast retransmit and the timeout mechanism.

• Evaluated using network traces obtained from the internet.

50

Related Work (contd.)“Equation-Based Congestion Control for Unicast Applications”

by Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer.

• Directly based on the TCP control Equation.

• Receiver provides feed back for RTT calculations.

• Receiver calculates loss event rate and feeds it back to sender.

• Sender takes care of RTT calculations, retransmission ( if required) and adapts the sending rate based on the equation.

51



• How to calculate the loss rate ?

•Instantaneous Values vary too much and are too noisy

• Averaged value could dampen the response to congestion.

• Limited History Weighted Average was used with history of previous 8 loss events out of which latest 4 were weighted heavily.

• Requires 4 to 8 round trip times to halve its sending rate in response to persistent congestion

52



• Shown to be TCP-Friendly over a wide range of parameters.

• Reduces variations in the sending rate compared to TCP.

• Loss rate calculations based on heuristics.

• Implementation is complex and requires modification of sender and receiver.

53

Related Work (contd.)“LDA+ TCP-Friendly Adaptation: A Measurement and

Comparison Study” by Sisalem, D. and Wolisz, A.

• Also uses TCP control equations to compute sending rate, but at the application level.

• Uses Real-Time Protocol (RTP) for collecting loss and delay statistics.

• Shown via simulations and experiments on the public internet to be TCP-Friendly.

54

Related Work (contd.)“LDA+ TCP-Friendly Adaptation: A Measurement and

Comparison Study” by Sisalem, D. and Wolisz, A.

• Application level solution which provides closed feedback requiring no implementation of separate transport layer protocol. Therefore, an attractive option.

• Depends on RTP messages to obtain loss rates, cannot change fast enough in case of rapid changes in the network.

• Receiver report uses 8 bits for loss information setting a limit of 0.002 for minimum loss rate.

55

Related Work (contd.)“TCP-friendly Congestion Control for Real-time Streaming

Applications” by D. Bansal and H. Balakrishnan.

Congestion Control Equations written in the form of binomial equations

I : wt+R wt + / wtk ; > 0

D : wt+t wt - wtl ; 0 < < 1

I refers to increase in windowD refers to decrease in windowwt is the congestion window at time tR RTT

and constants

56



• Covers the entire class of linear controls

• k= 0, l = 1 AIMD

• k= -1, l = 1 MIMD

• k= -1, l = 0 MIAD

• k= 0, l = 0 AIAD

• Steady State Analysis shows T 1/ p 1/(k + l + 1)

• This class of protocols will be TCP-Friendly when k + l = 1 and l 1 (called the k + l rule)

57



• Simulations with two implementations namely Inverse Increase/Additive Decrease (k = 1, l = 0) and SQRT (k = 1/2, l = 1/2) were shown to be TCP-friendly

• Equations indicate that several TCP-Friendly protocols can be designed based on the application requirement, provided they follow the k+l rule.

• Important observation: TCP-Friendliness does not necessarily indicate TCP-Compatibility.

58

DCR-ISimulation Results (contd.)Effect of RED parameters

Fairness Index of DCR-I at different RED parameters (maxthresh = 75%)

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

0 5 10 15 20 25

tau (in RTT)

Fairn

ess

Inde

x

(minth,maxth,pmax)=(3,22.5,0.1)(minth,maxth,pmax)=(7.5,22.5,0.1)(minth,maxth,pmax)=(15,22.5,0.1)(minth,maxth,pmax)=(18,22.5,0.1)(minth,maxth,pmax)=(21,22.5,0.1)

59

DCR-ISimulation Results (contd.)

Effect of RED parameters (contd.)

Fairness Index of DCR-I with different RED parameters.(maxthresh = 100%)

00.20.40.60.8

11.21.41.61.8

22.22.42.6

0 5 10 15 20 25

Tau (in RTT)

Fairn

ess

Inde

x

(minth,maxth,pmax)=(3,30,0.1)(minth,maxth,pmax)=(7.5,30,0.1)(minth,maxth,pmax)=(15,30,0.1)(minth,maxth,pmax)=(22.5,30,0.1)(minth,maxth,pmax)=(27,30,0.1)

delayed congestion response protocols

Documents