TCP, Active Queue Management and QoS

TCP, Active Queue

Management and QoS

Don Towsley

UMass Amherst

[email protected]

Collaborators: W. Gong, C. Hollot , V. Misra

Outline

• motivation

• TCP friendliness/fairness

• bottleneck invariant principle

• active queue management (AQM) & RED • QoS

Properties of TCP

• 90% of Internet traffic

– primary deliverer of multimedia (e.g., napster)

• conservative end-end congestion control (CC)

– additive increase multiplicative decrease CC – equal bandwidth share

• only end-end protocol w. congestion control

20Mbs B1=5Mbs

B₂=5Mbs

B₃=5Mbs

B₄=5Mbs 1

2 3

4

TCP

20Mbs B₁= 2Mbs

B₂= 2Mbs

B₃= 2Mbs

B₄= 2Mbs 1 2 3 4 UDP-12Mbs TCP

{

Additive-Increase

Multiplicative-Decrease (AIMD) Congestion Control

r_i - rate after i-th feedback

r_i+1 = r_i + c if i -th feedback is no congestion

r_i+1 = a x r_i if i -th feedback indicates

congestion, a < 1

• similar algorithms for window-based CC • basic building block of most congestion

r_i 1

r i

2

C C

(r1_,r2₎

• two sources, rates

r_i1, r

i2

. ..

(Chiu,Jain 89)

• initial rates r1 _and

r2

• bandwidth C

Example

• as time goes on, i

increases, source rates converge to a

Generic TCP Behavior

• window algorithm (window W )

– up to W packets can be in network

– return of ACK allows sender to send another packet

– ACKS cumulative

• increase window by one per RTT W <− <− <− <− W +1/W per ACK

⇒⇒⇒⇒ W <− <− <− <− W +1 per RTT

sender receiver

Generic TCP Behavior

• window algorithm (window W)

• increase window by one per RTT W <− <− <− <− W +1/W per ACK

• decrease window by half on detection of loss (triple duplicate ACK), W <−<−<−<− W/2

sender receiver

Generic TCP Behavior

• window algorithm (window W)

• increase window by one per RTT

W <− <− <− <− W +1/W per ACK

• halve window on detection of loss, W <−<−<−<− W/2

• timeouts due to lack of ACKs −>−>−>−> window reduced to one, W <−<−<−<− 1

sender

receiver

Generic TCP Behavior

• window algorithm (window W)

• increase window by one per RTT (or one over window per ACK, W <− <− <− <− W +1/W)

• halve window on detection of loss, W <−<−<−<− W/2 • timeouts due to lack of ACKs, W <−<−<−<− 1

• successive timeout intervals grow exponentially long

• slow start mechanism

IETF mandated (1997) :

“thou must be TCP fair”

IETF and TCP fairness

original definition

B ∝∝∝∝ MTU /(R * p )

p - loss probability;

R - round trip time;

MTU - pkt length;

• equilibrium analysis • focus on avg window

size W

p W/2 = (1-p)

××××

drift down = drift up

Derivation of

p

_expression

W = 2(1-p)/p

≈≈≈≈

B = 2 /R p

R

t W(t)

How well does this work?

• unidirectional bulk transfer from UMass to INRIA

• 100 sec. samples

• significant number of timeouts in most traces

• p 1/2 _{formula inaccurate (1-2}

orders of magnitude for large p)

+ +++ + ++++ + + +₊ + + ++ + + + +++ + +_{++ +++++} + + _{+ +} + ++ + +_{+++ +++ +++++} ++ ++ + + + +_{++ +}+_{+ +} + + + + ₊ + + ++ + + + ++ + + + + + 1 10 100 1000 10000 100000

0.001 0.01 0.1 1

loss probability

+ measurements

Floyd

p 1/2 formula

measurements loss rate t hro ug hp ut

Including timeouts:

• renewal theoretic approximation

B (p,R )

∝

∝

∝

∝

T₀ 3(3p/4)1/2p ₍₁₊₃₂p 2_)]-1

T₀ - timeout length

Basis of revised definition of

TCP friendliness

Validation

Experiments:

– 38 traces from 18 hosts

– unidirectional bulk transfers – 100sec measurements

Conclusions:

– good validation

– other studies support model – insensitive to TCP version

F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F F 0.01 0.1 1 10 100

0.001 0.01 0.1 1

Loss probability (p)

F _Measured

Full Model Floyd/Ott Model

UMass - INRIA

P a ck et s /s Measured PFTK Model

p1/2 _model

Lessons

• TCP exhibits well defined bandwidth curve

– decreasing function of R and p

• timeouts important

• little difference between TCP versions

– AIMD, timeouts – Vegas an exception

Bottleneck invariance principle

• bottleneck router

– where loss occurs – high load, util. ≈ 1

• bottleneck invariance principle (BIP)

ΣΣΣΣ

B

(

R

,

p

) =

C

Applications of BIP

• accurate models of networks supporting infinite/finite duration TCP flows

– thruput, loss rate, avg. queue length, …

• provides simple checks of protocol design

– new improved congestion control algorithms – forward error correction

– active queue management – RED

New and improved TCP

• new/improved, B_UMass(p)

B_UMass(p)

B_TCP(p)

p

thrup

ut

• TCP, B_TCP(p)

Sharing bottleneck with TCP

N_TCP N_UM

p

N_UM B_UM(p) + N_TCP B_ni(p) = C

• a win!

C

⇒⇒⇒⇒ B_UM(p) > B_TCP(p)

Replacing TCP with UMass

N

C

N B_UM(p_UM) = C vs

N B_TCP(p_TCP) = C

⇒ ⇒ ⇒

⇒ p_UM > p_TCP

• a loss!

• SACK worse than Reno?

SACK vs Reno

• SACK ACK includes bit vector of status of most recent group of packets

1. one window reduction max per RTT 2. reduces timeout rate

⇒ ⇒ ⇒

⇒ p_SACK > p_Reno at bottleneck

(difference slight)

3. increases retransmission efficiency

⇒ ⇒⇒

⇒ reduces duplicate packets • benefits of 3. outweigh 1. + 2.

Use of FEC

10%

use packet level FEC!

• 10% pkt loss C

encoder decoder

TCP source

TCP rcvr p

⇒ ⇒ ⇒

Use of FEC

10%

use packet level FEC!

• 10% pkt loss C

encoder decoder

TCP source

TCP rcvr

ACKs

p

p_FEC

• p_FEC << p

⇒ ⇒ ⇒

Use of FEC

• available bandwidth, C_FEC < C_wo • B_FEC( )

=

• N B_wo(p_wo) = C_wo

• N B_FEC(p_FEC) = C_FEC

⇒ ⇒ ⇒

⇒ p_FEC > p_wo

BIP can provide tremendous

insight into TCP.

BIP can provide tremendous

insight into congestion

Active queue management

• drop tail - drop pkt when buffer fills • active queue management (AQM)

– proactively drop/mark packets before buffer overflow

– example: drop pkt with probability p(x) x - avg. queue length

RED (Random Early Detect)

RED: marking/dropping based on average

queue length x (t )

t_min t_max p_max

1

2t_max

ma

rki

ng prob

p

avg queue length x

t

- q (t )

- x (t )

x (t) : smoothed, time averaged q (t) x (t_i +1) = α q (t_i +δ) + (1-α) x (t_i)

Droptail vs. RED

Experiment (Christiansen, etal, SIGCOMM’00)

• finite duration http flows into router • low load

– no difference

• high load

– droptail often produces lower latencies

– careful tuning of RED can reduce difference

RED

Droptail vs. RED: high load

Drop tail

q

q

⇒ q_DT > q_RED • R = A + q/C

⇒ R_DT > R_RED

⇒ p_DT < p_RED

⇒ longer latencies for finite duration flows under RED

• true for other AQM policies

Solution

- packet marking (ECN)

RED discard function

• RED queue

N

N₁ < N₂

N₂

• N identical TCP sources B(R,p) = C/N

C

• p increases with N

p_max

t_max N₁

N₁

N₃

N₂ < N₃

?

N₄

RED discard function

• RED queue

N

• N identical TCP sources B(R,p) = C/N

C

• p increases with N

p_max

t_max N₄

RED discard function

• RED queue

N

(Firoiu, Borden, 00)

• N identical TCP sources B(R,p) = C/N

C

• p increases with N • once p > p_max, queue

oscillates around t_max

⇒ ⇒⇒

⇒ RED unstable!

p_max

Improved RED

t_min t_max p_max

1

discontinuity removed

in gentle_ variant

2t_max

Mark

ing pro

b.

p

Another problem

• queue length smoothing adds delay to control loop ∫ ∫ R 1 N ⊗ ⊗ 21

1 W! _W q! _q

p _ _ _ _ C R1 R1 Time Delay R_tt Control law (e.g. RED)

• generates queue length oscillations • solution requires other tools

– fluid models

– differential equations – control theory

• 30 long-lived, 60 short lived flows • default ns RED parameters

• RED wo smoothing better than RED w smoothing

que

ue

s

ize

(p

kt

s)

time (seconds)

- RED with smoothing

Solution

• remove smoothing (May, etal, 00; Hollot, etal INFOCOM 01)

but feedback delay + queue fill/empty times remain

⇒

⇒

⇒

⇒

• use classical methods to compensate for delays (Hollot, etal, INFOCOM 01)

– addition of phase lead – PI control (also Low ‘00)

Improving congestion control

• PI controller vs. RED • time varying http, ftp

workload

Queue length vs. Time - PI Controller

- RED Controller

que

ue

le

ngt

h

time • PI controller: faster

response, decouples queue size and load level

TCP and QoS

• proper design of TCP affects QoS

• AQM design significantly impacts QoS

– most DiffServ proposals rely on RED

• no additional mechanisms required for underloaded network

• call admission required for overloaded network

Summary

• although complex, TCP is well behaved and

easy to characterize

• BIP can provide tremendous insight

• AQM not useful without marking

• RED is flawed AQM policy

• control theory explains flaws, suggests