Multirate Congestion Control Using TCP Vegas Throughput Equations

Anirban MahantiDepartment of Computer Science

University of CalgaryCalgary, AlbertaCanada T2N 1N4

2

Problem Overview

Context: Live or schedule multicast of popular content to thousands of clients “Layered Encoding” to serve heterogeneous

clients Employ a “multirate” congestion control protocol Receiver-driven for scalability

Internet

Video Server

ADSL

Dial-up

High-speed Access

3

The Multirate CC Wish List

1. “TCP friendly”

2. Operate without inducing packet losses while probing for bandwidth

3. Receivers behind a common bottleneck link receive media of the same quality

4. Responsive to congestion, yet achieve consistent playback quality

4

TCP Friendliness for Multimedia Streams

TCP-friendly bandwidth share? As much as a TCP flow under similar condition

(e.g., RLC Infocom’98) Function of the number of receivers

(e.g., WEBRC Sigcomm’02)

Equation-based approach Fair sharing of bandwidth Lower variation in reception rate compared to

TCP-like AIMD approaches

5

Objective

Develop a new multirate congestion control protocol using TCP Vegas throughput model – “Adaptive Vegas Multicast Rate Control”

Less oscillatory throughput?

Fewer packet losses?

Reduced RTT bias?

Prior work: Reno-like rate control (e.g., RLM Sigcomm’96, RLC, FLID-DL in NGC’00 etc)

6

TCP Reno Throughput Model

Reno (Mathis et al. ACM CCR 1997, Padhye et al. Sigcomm’98)

)321(8

33

32

1

2

Re

ppp

TOp

Rno

7

TCP Vegas Window EvolutionW

indo

w S

ize

Win

dow

Siz

e

NO LOSS WINDOW EVOLUTION

Stable Backlog:No-loss Window evolutionbetween loss events

[Samois & Vernon’03]

TCP Throughput Models

9

TCP Vegas Throughput Model

baseRTTRlossno

vegasTONR

Wpp

nlossvegas

1)1(

)ed!(complicat ,, of func. :

1 ,

)(2

)(

RTT observed min. : ,parameters thresholdVegas : ,

out-Time : RTT, avg.: rate, loss statesteady :

npWN

p

pn

baseRTTR

RW

baseRTT

TORp

to

to

[Samois & Vernon’03]

10

TCP Throughput Models: Summary

RTT bias

None when packet losses are negligible

In presence of packet losses some RTT bias, but lower than that of TCP Reno

Relative aggressiveness of TCP Vegas flows depend on:

Vegas threshold parameters!!

Buffer space available at bottleneck router!!

How to adaptively set the TCP Vegas threshold parameters?

11

Online Estimation of Parameters: RTT

E.g., Exponential Weighted Moving Average for RTT

What “weights” should be used?

t

t

R

RRR

RTTrecent most given to weight :

) 1(

12

Average Loss Interval (ALI) Method

sp

wnw

sws in

ii

n

iii

1

}2.0,4.0,6.0,8.0,1,1,1,1{ ,8 ;

1

1

Obtained Lost

s1s3s2

AVMRC Protocol

14

Adaptive Vegas Multicast Rate Control End-to-end protocol

Server transmits data for a media object using multiple multicast channels

Clients independently determine their reception rate using TCP Vegas model

subscribe to multiple multicast channels, such that client reception rate approximately matches estimated fair share

15

AVMRC Overview Continued …

Dynamically vary Vegas threshold parameters

Short-term and long-term averages of loss event rate and delay

RTT approximated as average queuing delay along path from server to client plus some “aggressiveness constant”

Clients are “weakly” synchornized

16

AVMRC: Dynamic TCP Vegas Thresholds

Condition) Backlog (Stable 32367

322

WW

p

new

lt

ltnew R

baseRTTRW

W

05.095.0 .3

)( .2

for condition backlog stable solve ,slot" time"At 1.

:Initialize min

17

Time Slot: Protocol Invocation Granularity

How often clients compute new throughput estimates?

Once every T seconds ( a time slot) T = ???

Time slot dilemma Longer slots for reliable estimates of RTT & p Smaller slots to enable quick channel drop in the

event of an aggressive add!

18

AVMRC: Time Slot Dilemma

AVMRC default: T = 100 ms

Maintain short-term & long-term estimates

Smaller slots to enable quick channel drop based on short-term estimates

Channel adds governed by stable long-term estimates

19

AVMRC: Receiver Synchronization

Add operations can impede convergence to fair share

Quick drop by a client, however, do not impede converge of other receivers.

AVMRC solution: weak synchronization Server inserts a marker in the data stream once

every T seconds; is this enough?

Bottleneck

A

B

Congestion by A causes B to drop below fair share

20

AVMRC: Channel add/drop Frequency

Reception rate choices may be coarse-grained, resulting in client reception rate oscillations

Allow add operations every Tadd = nT Clusters channel additions behind a common bottleneck

when nxT larger than n/w delay variations

Channel drops allowed every T seconds (time slot)

200 Kb

300 Kb

500 Kb Fair Share

Subscription oscillates

21

AVMRC: RTT Estimation

How to define RTT for multicast traffic? Little or no reverse traffic

Obtain RTT by end-to-end control info. exchange

Use a fixed RTT (e.g., FLID-DL, RLC)

AVMRC default: Fixed RTT + Queuing Delay Queuing Delay calculation doesn’t require

synchronized clocks

22

AVMRC: Rules for Changing Subscription

)(),max(

Otherwise, .2

)(),min(

past recent in the channel a joinedclient if 1.

:condition Drop

)(),min( :condition Add

layersmcast ifor req.Bandwidth :

parameters term-long

using Estimate Throughput :

parameters term-short

using Estimate Throughput :

1

1

11

iiiltst

iiiltst

iiiltst

i

lt

st

BBbB

BBbB

BBaB

B

Evaluation Methodology

24

Performance Evaluation - Goals

Explore properties of AVMRC

Compare AVMRC with an analogous protocol (RMRC) that used TCP Reno throughput model

Other factors of AVMRC considered: Synchronization Policy RTT Estimation Policy Data Transmission Policy – Bursty vs. smooth Protocol Reactivity

Evaluation using Network Simulator (ns-2)

25

AVMRC: Default protocol Parameters

Slot duration T = 0.1s RTT: Fixed value (0.1s) + variable queuing

delay ALI with n=8 for loss event rate comp. Weak synchronization Bursty transmissions – once every 0.1s Cumulative layered encoding with following

rates: 256, 384, 576, 864, 1296, 1944, 2916, 4374, 6561Kbps

RMRC uses the same parameters

26

Network Model

Dumbbell topology with a single bottleneck 3Mbps to 100Mbps

Drop-tail FIFO buffering approx. 50 to 250 ms

Background traffic simulated HTTP FTP UDP Round-trip prop. delay in [20, 460]ms

AVMRC Performance Evaluation

28

No Background Traffic

(a) AVMRC (b) RMRC

29

No Background Traffic: Scalability (1)

Bottleneck = 3MbpsBuffer = 80 packets

30

No Background Traffic: Scalability (2)

Bottleneck = 3MbpsBuffer = 80 packets

31

UDP Background Traffic

Bottleneck = 3Mbps, Buffer = 80 packets If bottleneck link lightly loaded, AVMRC

operates without inducing packet losses.

32

FTP Background Traffic

Bottleneck = 3Mbps, Buffer = 80 packets AVMRC experiences no packet losses in a

majority of the experiments

33

Dynamic Vegas Thresholds (1)

Bottleneck = 45Mbps, Buffer = 250 packets Background Flows: 90% HTTP, 10% FTP; RTT in [20,420]ms

34

Dynamic Vegas Thresholds (2)

Scaling bottleneck link capacity & background traffic mix Dynamic threshold works!

35

RTT Estimation Policy

Bottleneck capacity = 10 Mbps, Buffer = 150 packets, 90 Background HTTP sessions

36

Protocol Reactivity: Session Scalability

Bottleneck capacity = 3 Mbps, Buffer = 80 packets, no background traffic

37

Protocol Reactivity: HTTP Bkg. Traffic

Bottleneck capacity = 10 Mbps, Buffer = 150 packets, background traffic is HTTP

38

Conclusions & Future Work

AVMRC, a new multirate CC protocol based on TCP Vegas throughput model

Can operate without inducing losses No feedback from source No explicit coordination among clients No constraints on data transmission policy Fair sharing with TCP Reno

Dynamic TCP Vegas threshold estimation Incremental deployment of Vegas? Unicast rate control?

39

For Details …

Anirban Mahanti, “Scalable Reliable On-Demand Media Streaming Protocols”, Ph.D. Thesis, Dept. of Computer Science, Univ. of Saskatchewan, March 2004.

Anirban Mahanti, Derek L. Eager, and Mary K. Vernon, “Improving Multirate Congestion Control Using TCP Vegas Throughput Equations”, Computer Networks Journal, to appear 2004.

Email: mahanti@cpsc.ucalgary.ca http://www.cpsc.ucalgary.ca/~mahanti