Multirate Congestion Control Using TCP Vegas Throughput Equations

Multirate Congestion Control Using TCP Vegas Throughput Equations Anirban Mahanti Department of Computer Science University of Calgary, Alberta Canada T 2 N 1 N 4

Problem Overview n Context: Live or schedule multicast of popular content to thousands of clients n “Layered Encoding” to serve heterogeneous clients n Employ a “multirate” congestion control protocol n Receiver-driven for scalability ADSL Dial-up Internet Video Server High-speed Access 2

The Multirate CC Wish List 1. 2. 3. 4. “TCP friendly” Operate without inducing packet losses while probing for bandwidth Receivers behind a common bottleneck link receive media of the same quality Responsive to congestion, yet achieve consistent playback quality 3

TCP Friendliness for Multimedia Streams n TCP-friendly bandwidth share? n n n 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 n n Fair sharing of bandwidth Lower variation in reception rate compared to TCPlike AIMD approaches 4

Objective n n Develop a new multirate congestion control protocol using TCP Vegas throughput model – “Adaptive Vegas Multicast Rate Control” n Less oscillatory throughput? n Fewer packet losses? n Reduced RTT bias? Prior work: Reno-like rate control (e. g. , RLM Sigcomm’ 96, RLC, FLID-DL in NGC’ 00 etc) 5

TCP Reno Throughput Model n Reno (Mathis et al. ACM CCR 1997, Padhye et al. Sigcomm’ 98) 6

Window Size TCP Vegas Window Evolution [Samois & Vernon’ 03] NO LOSS WINDOW EVOLUTION Stable Backlog: No-loss Window evolution between loss events 7

TCP Throughput Models

TCP Vegas Throughput Model [Samois & Vernon’ 03] 9

TCP Throughput Models: Summary n RTT bias n n 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: n Vegas threshold parameters!! n Buffer space available at bottleneck router!! How to adaptively set the TCP Vegas threshold parameters? 10

Online Estimation of Parameters: RTT n n E. g. , Exponential Weighted Moving Average for RTT What “weights” should be used? 11

Average Loss Interval (ALI) Method s 3 s 2 s 1 Obtained Lost 12

AVMRC Protocol

Adaptive Vegas Multicast Rate Control n n n 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 n subscribe to multiple multicast channels, such that client reception rate approximately matches estimated fair share 14

AVMRC Overview Continued … n n 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 15

AVMRC: Dynamic TCP Vegas Thresholds 16

Time Slot: Protocol Invocation Granularity n How often clients compute new throughput estimates? n n n Once every T seconds ( a time slot) T = ? ? ? Time slot dilemma n n Longer slots for reliable estimates of RTT & p Smaller slots to enable quick channel drop in the event of an aggressive add! 17

AVMRC: Time Slot Dilemma n AVMRC default: T = 100 ms n Maintain short-term & long-term estimates n n Smaller slots to enable quick channel drop based on short-term estimates Channel adds governed by stable long-term estimates 18

AVMRC: Receiver Synchronization A Bottleneck Congestion by A causes B to drop below fair share B n n n 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 n Server inserts a marker in the data stream once every T seconds; is this enough? 19

AVMRC: Channel add/drop Frequency Fair Share 500 Kb 300 Kb Subscription oscillates 200 Kb n n Reception rate choices may be coarse-grained, resulting in client reception rate oscillations Allow add operations every Tadd = n. T n n Clusters channel additions behind a common bottleneck n when nx. T larger than n/w delay variations Channel drops allowed every T seconds (time slot) 20

AVMRC: RTT Estimation n How to define RTT for multicast traffic? n Little or no reverse traffic n Obtain RTT by end-to-end control info. exchange n Use a fixed RTT (e. g. , FLID-DL, RLC) n AVMRC default: Fixed RTT + Queuing Delay n Queuing Delay calculation doesn’t require synchronized clocks 21

AVMRC: Rules for Changing Subscription 22

Evaluation Methodology

Performance Evaluation - Goals n n n Explore properties of AVMRC Compare AVMRC with an analogous protocol (RMRC) that used TCP Reno throughput model Other factors of AVMRC considered: n n n Synchronization Policy RTT Estimation Policy Data Transmission Policy – Bursty vs. smooth Protocol Reactivity Evaluation using Network Simulator (ns-2) 24

AVMRC: Default protocol Parameters n Slot duration T = 0. 1 s RTT: Fixed value (0. 1 s) + variable queuing delay ALI with n=8 for loss event rate comp. Weak synchronization Bursty transmissions – once every 0. 1 s Cumulative layered encoding with following rates: n RMRC uses the same parameters n n n 256, 384, 576, 864, 1296, 1944, 2916, 4374, 6561 Kbps 25

Network Model n Dumbbell topology with a single bottleneck n n Drop-tail FIFO buffering n n 3 Mbps to 100 Mbps approx. 50 to 250 ms Background traffic simulated n n HTTP FTP UDP Round-trip prop. delay in [20, 460]ms 26

AVMRC Performance Evaluation

No Background Traffic (a) AVMRC (b) RMRC 28

No Background Traffic: Scalability (1) Bottleneck = 3 Mbps Buffer = 80 packets 29

No Background Traffic: Scalability (2) Bottleneck = 3 Mbps Buffer = 80 packets 30

UDP Background Traffic n n Bottleneck = 3 Mbps, Buffer = 80 packets If bottleneck link lightly loaded, AVMRC operates without inducing packet losses. 31

FTP Background Traffic n n Bottleneck = 3 Mbps, Buffer = 80 packets AVMRC experiences no packet losses in a majority of the experiments 32

Dynamic Vegas Thresholds (1) n n Bottleneck = 45 Mbps, Buffer = 250 packets Background Flows: 90% HTTP, 10% FTP; RTT in [20, 420]ms 33

Dynamic Vegas Thresholds (2) n n Scaling bottleneck link capacity & background traffic mix Dynamic threshold works! 34

RTT Estimation Policy n Bottleneck capacity = 10 Mbps, Buffer = 150 packets, 90 Background HTTP sessions 35

Protocol Reactivity: Session Scalability n Bottleneck capacity = 3 Mbps, Buffer = 80 packets, no background traffic 36

Protocol Reactivity: HTTP Bkg. Traffic n Bottleneck capacity = 10 Mbps, Buffer = 150 packets, background traffic is HTTP 37

Conclusions & Future Work n AVMRC, a new multirate CC protocol based on TCP Vegas throughput model n n n 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 n n Incremental deployment of Vegas? Unicast rate control? 38

For Details … n n n 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 n http: //www. cpsc. ucalgary. ca/~mahanti 39