1 / 24

STAIR: Practical AIMD Multirate Multicast Congestion Control

STAIR: Practical AIMD Multirate Multicast Congestion Control. Computer Science. Boston University. John Byers and Gu-In Kwon. Pro: one copy of packet per link -- saves bandwidth Cons: challenges of reliability and congestion control, especially as session size scales.

trory
Download Presentation

STAIR: Practical AIMD Multirate Multicast Congestion Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

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

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

More Related