STAIR: Practical AIMD Multirate Multicast Congestion Control

1. STAIR: Practical AIMD Multirate Multicast Congestion Control Computer Science Boston University John Byers and Gu-In Kwon

2. Pro:one copy of packet per link -- saves bandwidth Cons: challenges of reliability and congestion control, especially as session size scales IP Multicast for Content Delivery Sender Receivers

3. 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)

4. 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?

5. Loss Elasticity Matters • Every encoded packet “equivalently useful”. • Thus, packets may be scheduled on any layer.

6. 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).

7. 6 Increase signal = 2 5 Aggregate rate 4 Increase signal = 1 Layer 2 3 2 Layer 1 1 Base layer 0 0 1 2 3 4 5 6 Time One Instantiation: RLC (Vicisano, Rizzo, Crowcroft - Infocom 1998)

8. 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.

9. NCL0=1 NCL1=2 NCL2=4 NCL3=7 10 9 8 7 6 NCL3 NCL3 5 NCL2 NCL3 4 NCL2 3 2 NCL1 NCL1 NCL1 1 NCL1 NCL0 NCL0 NCL0 Another Approach: FGLM (Byers, Luby, Mitzenmacher - Infocom 2001) Reception Rate t1 t2 t3 t4 Time

10. 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 B0 is fixed. • If B0 is small: frequent subscription changes. • If B0 is large: abrupt rate increases. • Bandwidth dilation at links (next slide). • Satisfies restricted class of applications: • time-varying (and non-cumulative) subscription rates.

11. 1,1,2 2,4 1,4 1 1,1 1,8 1,1,2,4,8 1,1,2,4 1,1,2,4 1,1,2,4 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 Cumulative: Dilation = 1 Non-Cumulative: Dilation = 16/9

12. STAIR (Simulate TCP’s AIMD with Rate-based )Congestion Control

13. 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).

14. Stair Layers • 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. SL (128 ) with R = 1Mbps (and 1KB packets)

15. A Stair Layer in Action

16. 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).

17. What Stair Layers Accomplish • Accommodate a variety of RTT’s • Our recommendation: provide exponential spacing between stair layers. • SL0 : Additive increase every 2i ms. • SLj : 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.

18. Reducing Dilation in FGLM K = αj + m, K = 23+5, α= 2

19. Advanced STAIR • Hybrid layering scheme. • Cumulative Layers (CL’s):c0 = 1, ci = c0* αi-1. • a : increase factor • Non-Cumulative Layers (NCL’s):n0 = 1, n1 = 2, and ni = ni-1 + ni-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).

20. TCP Fairness 30 Mbps DropTail RED

21. Different RTTs

23. 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?

24. For more information:www.cs.bu.edu/~byersThank you.