瘀b啂十楗敲敬獳潲灵-STAIRPracticalAIMD.pptVIP

STAIR: Practical AIMD Multirate Multicast Congestion Control John Byers and Gu-In Kwon 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 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 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) Experience with RLC Coarse-grained approximation to additive increase. “TCP-like” in simulation. E