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

Digital Fountain Approach(Byers, Luby, Mitzenmacher, Rege: SIGCOMM ’98)

Encoding Stream

Received

Message

Sourcen

n

n Can recover filefrom any set ofn encoding packets.

Transmission

• 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

1 2 3 4

Aggregaterate

0

1

5 6

2

3

4

5

6

Base layer

Layer 1

Layer 2

Increasesignal = 1

Increasesignal = 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.

NCL1

NCL1

NCL2

NCL0

NCL0

NCL3

NCL1NCL0

NCL3

NCL1

NCL3

NCL2

12345

6

10987

t1 t3t2 t4

NCL0=1

NCL1=2

NCL2=4

NCL3=7

Reception Rate

Time

Another Approach: FGLM (Byers, Luby, Mitzenmacher - Infocom 2001)

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.

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,41,8

1,4

1,1,2,4

2,4

1,1,2,4,8

Cumulative: Dilation = 1 Non-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)

A Stair Layer in Action

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

What Stair Layers Accomplish

K = αj + m, K = 23+5, α= 2

Reducing Dilation in FGLM

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

TCP Fairness

RED DropTail

30 Mbps

Different RTTs

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.