Source-Based Multicast Congestion Control

1. Source-Based Multicast Congestion Control P. Thapliyal, Sidhartha, S.Kalyanaraman Rensselaer Polytechnic Institute Contact: shivkuma@ecse.rpi.edu http://www.ecse.rpi.edu/Homepages/shivkuma

2. A case for purely source-based CC. • Scheme: • Concepts • 3-Stage Filters • RTT estimation issues • Sample performance results • Drop-to-zero resistance • TCP-friendliness Overview

3. Pure Source-based CC • Leverages existing RMT reverse traffic (NAKs, Bitmaps) • Very low (or zero) control traffic requirements • Implemented at source => no other support required in receivers, network elements, aggregators and packet headers. • Deployment simplicity • Weak, but minimal requirements on RTT estimation • Low (*, G) state/computational requirements at the sender • Could extend relatively easily to multi-sender case (future) • Sender-based MCC: Cons: • Minimal reverse control traffic carrying implicit congestion and timing information required

4. Concepts • Unicast: • During congestion, receiver sends multiple loss indications (LIs) per RTT • Sender responds to at most one LI per RTT: “Loss Event” (LEs) or “Congestion Indication” (CI) • Multicast: LIi available per-receiver => Total LIs = i Lii • Drop-to-zero problem without filtering => 3-stage filters. Stage 1: LI2LE filtering on a per-receiver basis (LIi LEi) • Total LEs after LI2LE filtering = i LEi Stage 2: Pass Maxi{LEi} out of i LEi Stage 3: Pass at most one filtered LE (I.e. CI) per RTT

5. ATF 3-Stage Filter Model Congestion Indications (CIs) Max{LEs} • Stage 1: LI2LE (Loss Indication  Loss Event) filter • Stage 2: Max-LPRF (Linear Proportional Response Filter) • Stage 3: ATF: Adaptive Time Filter • Rate-based AIMD (Additive Increase Multiplicative Decrease) • RTT Estimator Max- LPRF Loss event (LEs) AIMD LI2LE Loss Indications (Lis) RTT Estimator Estimated RTT

6. LI2LE Filter • Goal: Per receiver, pass at most one LI per RTT. • These filtered LIs are considered to be LEs • Per receiver timestamp (Ti) noted when the last LI passed • LIi is passed if current time (t) - Ti > k*RTT • k = 1 typically LIs Per-receiver Timestamp LI2LE LEs RTT estimate

7. Max-LPRF (Linear Proportional Response Filter) • Filters every LE with the probability: • Xi: the number of loss events received from receiver i. • Max{Xi}: the Max LE count from any one receiver. • Xi: the total number of LEs received from all receivers. LEi Xi Maxi{Xi} Per receiver LE counter Max- LPRF Decay function RTT estimate

8. Adaptive Time Filter (ATF) Concepts • Assume tree with just a single multicast flow • Congestion can occur independently in branches due to capacity changes, buffer sizing etc • Congestion “epoch”:Sub-period of congestion where: • the source reduces its rate exactly once and • gives enough time for rate-reduction to diffuse through the congested sub-tree. • To avoid drop-to-zero (due to independent congestion events): • The number of congestion epochs should be exactly = ceil{log2 (/min)} • min is the minimum available rate for the RMT flow anywhere in the tree;  is the source rate before congestion • Ideally,congestion epoch=largest RTT of congested sub-tree

9. source rate = R Congested source rate =0.5 R Sub-tree Congested Longest RTT of Congested Sub-tree Sub-tree = RTT2 Router 0.3R Longest RTT of Congested Router 0.3R Sub-tree = RTT1 Router Router Router Router 0.8R 0.8R Congestion Epoch 1 Congestion Epoch 2 Timelines: Total Congestion Period = RTT1 + RTT2 Congestion Epoch 1 = Congestion Epoch 2 = RTT1 RTT2 Congestion Epochs, Congested Sub-tree Structures, Longest RTT, Total Congestion Period

10. RTT Estimation Issues • Sampling: • Local timestamp recorded when packet transmitted • RTT sample when NAK is received • Ideally, RTT samples not taken for NAKs which are re-transmitted (or NAKs which correspond to RDATA losses) • Statistics collection: • Reject 90% of samples smaller than SRTT/2 (SRTT =avg) • Use most samples from highest “order of magnitude” RTT • Exponentially average the samples (SRTT) and the deviations (|sample - SRTT|) • Note: this does not guarantee getting samples from largest RTT sub-tree if there is aggregation. • If samples come from different sub-trees, it will be reflected in the smoothed mean deviation

12. RTT Estimation and AIMD • Reject 90% of samples smaller than SRTT/2 • Use most samples from highest “order of magnitude” RTT • Canonical congestion epoch = SRTT + 4D (like TCP timeout) • Accounts for variance in remaining samples • NAKs filtered out till end of congestion epoch • Assume rexmitted NAKs not included in RTT estimation • No rate increases during epoch • Additional silence period of SRTT/2 • No source traffic sent after rate reduction for SRTT/2 • Allows collection of NAKs from newly congested sub-tree • Compensates for partial or no aggregation • Only “new” NAKs can trigger rate decrease (and fresh epochs) • Rate increase interval = SRTT + 2D (empirically set)

13. RM receivers Destination 1 6 Mbps Set 1 5 Mbps Destination 2 Set 2 Set 3 Destination 3 Set 4 Destination 4 Main source Effect of Multiplexing, Fanout

14. Summary • Pure source-based MCC could potentially have zero control traffic requirements and reduced complexity • Needs congestion indications and implicit timing information from underlying feedback stream • Idea: emulate unicast model • 3-stage filters: LI2LE, Max-LPRF, ATF • AIMD and RTT estimation Module • Preliminary results (assuming un-aggregated LIs): • Drop-to-zero resistance and TCP friendliness