Presentation on theme: "STAIR: Practical AIMD Multirate Multicast Congestion Control John Byers and Gu-In Kwon Boston University Computer Science."— Presentation transcript:
STAIR: Practical AIMD Multirate Multicast Congestion Control John Byers and Gu-In Kwon Boston University Computer Science
IP Multicast for Content Delivery Pro: one copy of packet per link -- saves bandwidth Cons: challenges of reliability and congestion control, especially as session size scales Sender Receivers
Congestion Control Goals End-to-end: No special router support. Multi-rate: Heterogeneous reception rates supported. (Considerable recent progress on single-rate case). Non-adaptive sender: Sender behaves no differently whether one or a million receivers. –Same outgoing packets independent of number of hosts. –Of course, not all packets reach all hosts. Receiver-driven: Each receiver autonomously adjusts reception rate. Friendly to the network (bursts, buffer overflows) and fair to other flows (e.g. TCP)
Myths and Conventional Wisdom Myth: A satisfactory multi-rate congestion control solution is unattainable. Closer to the truth: A general purpose, i.e. application-agnostic, solution is unattainable. –TCP’s congestion control is not general purpose either… –Some applications are easier to handle than others. Very hard: Loss-inelastic real-time. Hard: Video streaming (w/ tolerance to losses). Easier: Reliable transmission of FEC-encoded content. Key observation: Elasticity to packet loss simplifies multi-rate congestion control. Why?
Loss Elasticity Matters Every encoded packet “equivalently useful”. Thus, packets may be scheduled on any layer.
Base Solution: Layered Multicast (initiated by McCanne, Jacobson, Vetterli, SIGCOMM ‘96) Basic Ideas Set of multicast groups for each session with geometrically increasing rates (1, 1, 2, 4, 8, 16,..). Receivers adjust reception rate by joining and leaving multicast groups in cumulative order. Challenges how to ensure TCP-friendliness? how to coordinate receivers behind a bottleneck? only works when content encoding tolerates rate- adaptation (designed with layered video in mind).
One Instantiation: RLC (Vicisano, Rizzo, Crowcroft - Infocom 1998) 0 Time 1234 Aggregate rate 0 1 56 2 3 4 5 6 Base layer Layer 1 Layer 2 Increase signal = 1 Increase signal = 2
Experience with RLC Coarse-grained approximation to additive increase. –“TCP-like” in simulation. –Early analysis/notions of TCP-friendliness. Adverse network impacts in practice: –Doubling causes abrupt rate increases. –Large buffer overflows; bursts of dropped packets. Also, IGMP leave latency can be substantial –Most layered multicast solutions suffer from this. –One remedy proposed in NGC 2000 paper.
Experience with FGLM Finer-grained approximation to additive increase. But: –Large amount of IGMP traffic at each last hop router. 1 join and 2 leaves per client at every AI decision point. Constant hum at last hop routers with large fanout. –Base layer bandwidth B 0 is fixed. If B 0 is small: frequent subscription changes. If B 0 is large: abrupt rate increases. –Bandwidth dilation at links (next slide). Satisfies restricted class of applications: –time-varying (and non-cumulative) subscription rates.
Dilation (of a link) Definition: ratio of total bandwidth demanded by all downstream receivers over maximum rate demanded by one downstream receiver. Measure of wasted bandwidth by asynchronous receivers 1,1 1 1,1,2,4 1,1,2 1,1,2,4 1,8 1,4 1,1,2,4 2,4 1,1,2,4,8 Cumulative: Dilation = 1Non-Cumulative: Dilation = 16/9
STAIR (Simulate TCP’s AIMD with Rate-based ) Congestion Control
STAIR Contributions True additive increase, multiplicative decrease. –(Interesting that it is doable; not clear that this is needed). Small amount of IGMP traffic at each last hop router. Different RTTs mapped to different rates of additive increase, like TCP’s congestion control. Also, a way to reduce bandwidth dilation in FGLM. Remaining Limitations: –Only applications which can use non-cumulative layering stand to benefit. –Probably best for high-bandwidth receivers. (Slow members can use TFMCC or pgmcc, for example).
Stair layers are dynamic. SL (t ) emulates additive increase of a TCP with RTT = t. Recycles to a rate of zero upon reaching max rate R. Stair Layers SL (128 ) with R = 1Mbps (and 1KB packets)
Basic STAIR Subscribe to one Stair layer + NCLs. By doing nothing, result = additive increase. When Stair layer recycles: –If there was no loss -- Additive Increase Increase rate on NCL’s by R (1 join and 2 leaves) –When there’s loss -- Multiplicative Decrease Drop the highest NCL (1 leave) This can be done any time, not just at a boundary. (We haven’t faithfully modeled timeout behaviour).
Accommodate a variety of RTT’s –Our recommendation: provide exponential spacing between stair layers. SL 0 : Additive increase every 2 i ms. SL j : Additive increase every 2 j+i ms. –Then pick the fastest stair < estimated RTT. Mitigate last-hop IGMP implosion. Allow multicast receivers to asynchronously emulate rate they would get with TCP. And… bandwidth dilation is modest, both provably & experimentally. What Stair Layers Accomplish
K = α j + m, K = 2 3 +5, α= 2 Reducing Dilation in FGLM
Advanced STAIR Hybrid layering scheme. –Cumulative Layers (CL’s): c 0 = 1, c i = c 0 * α i-1. a : increase factor –Non-Cumulative Layers (NCL’s): n 0 = 1, n 1 = 2, and n i = n i-1 + n i-2 + 1 for i > 1. –To attain a given rate K = a^j + m. Subscribe to j CL’s and the right set of NCL’s for a rate m. Before (just NCL’s): Dilation of about 1.62 After (Hybrid): Dilation is 1 + 1.62(α-1)/α. When α = 1.2, dilation is 1.27. A complete accounting also needs to consider dilation of stair layers (tends to zero as overall rates increase).
Conclusions Modularity in congestion control design is important… … but useful to leverage application-specific requirements. STAIR emulates receiver-driven version of TCP’s AIMD. –Provides same-path fairness to TCP. –Matches functional relationship between throughput & RTT. –Incurs low dilation, much better than n * unicast. –Amount of IGMP traffic carefully managed. Designed for users with high end-to-end bandwidth rates. Main open question: Can other applications stand to benefit from principles used in STAIR design?
For more information: www.cs.bu.edu/~byers Thank you.