End-to-end Congestion Management for the NGI Hari Balakrishnan MIT Laboratory for Computer Science http://nms.lcs.mit.edu/ DARPA NGI PI Meeting October 2, 2000 Srinivasan Seshan (CMU), Frans Kaashoek (MIT) Dave Andersen, Deepak Bansal, Dorothy Curtis, Nick Feamster

iNAT Project: Motivation Increasing heterogeneity in the Internet Nodes: Mobiles, devices, sensors,... Links: Optical, wireless,... Services & applications: Web, telepresence, streaming, remote device control Need a general solution for applications to discover resources and deal with mobility Need a general framework for learning about and adapting to changing network conditions

iNAT Approach Intelligent naming Adaptive transmission Resource discovery: Intentional Naming System (INS) using expressive names and self-configuring name resolver overlay network Mobility: Via dynamic name updates and secure connection migration (check out demo!) Adaptive transmission End-system congestion management and adaptation framework for the NGI Congestion Manager software and algorithms

The Problem End-to-end congestion management is essential Reacting when congestion occurs Probing for spare bandwidth when it doesn’t The future isn’t about just TCP! Many applications are inherently adaptive, but they don’t adapt today Enable applications to learn about network conditions Many applications use concurrent flows between sender and receiver, which has adverse effects Enable efficient multiplexing and path sharing What are some key features of the world I just described? - Lots of heterogeneity - Much higher levels of dynamism than today - Much more decentralized and needs much more robustness - allow for tetherless operation Congestion Manager (CM): A new end-system architecture for congestion management

The Big Picture IP HTTP Audio Video1 Video2 Per-”macroflow” statistics (cwnd,rtt,…) TCP1 TCP2 UDP API Congestion Manager IP Flows aggregated into macroflows to share congestion state All congestion management tasks performed in CM Apps learn and adapt using API

CM Architecture Sender Receiver Application (TCP, HTTP, RTP, etc.) feedback Application API API cm_update(feedback) Congestion Detector Hints Dispatch Congestion Controller Scheduler Sharing macroflow bandwidth Deciding who can send Requirements of api and probing sys result in following arch.. Cong ctl is repository of cong info… it gets info from the application hints as well as probing system… it implements Cong ctl algorithms and decides when and how fast data should be sent Once it decides data can be sent.. Control is passed to scheduler…. Sched decides which active application should be able to send. Probing system interacts with receiver’s cong detector and responder to detect losses using cm protocol Implemented in ns now and ongoing implementation in linux Stable controls Deciding when to send Responder Prober CM protocol

Lesson: move buffering into the application Transmission API Traditional kernel buffered-send has problems Does not allow app to “pull back” data App CM IP Rate change cm_send( ,dst) Can’t pull out and re-encode Packets queued to dst Lesson: move buffering into the application

Transmission API (cont.) Callback-based send App CM IP cm_request() send( ) cmapp_send() based on allowed rate Schedule requests, not packets Enables apps to adapt “at the last instant”

Benefits of macroflow sharing Shared learning Avoids overly aggressive behavior Good for Internet stability and fairness Adoption incentives More consistent performance of concurrent downloads Avoids independent slow-starts and improves response times Beats persistent-connection HTTP on interactive performance by allowing parallel downloads

predictability and consistency of downloads CM Web Performance TCP Newreno Sequence number With CM Time (s) CM greatly improves predictability and consistency of downloads

CM applications TCP over CM Congestion-controlled UDP HTTP server Uses TCP/CM for concurrent connections cm_query() to pick content formats SCTP: Stream Control Transport Protocol Real-time streaming applications Synchronous API for audio (e.g., vat) Callback API for video (scalable MPEG-4 delivery system)

Congestion Control for Streaming Applications CM provides a flexible framework for per-macroflow congestion control algorithms TCP-style additive-increase/multiplicative decrease (AIMD) is ill-suited for streaming media Window Time MD causes large, drastic rate changes Slow start Goal: Smooth rate reductions

l  K  size / (sqrt(p)  RTT) TCP-friendliness Throughput vs. loss-rate equation for AIMD: l  K  size / (sqrt(p)  RTT) Important for safe deployment and competition with TCP connections Two different approaches: Increase/Decrease rules Increase: w(t+R)  I(w); e.g., w+1 or 2w Decrease: w(t+dt)  D(w), e.g., w/2 Loss-rate monitoring (e.g., TFRC) Estimate loss rate, p, and set rate  f(p)

Binomial Algorithms I(w) and D(w) are nonlinear functions I: w(t+R)  w + a / wK D: w(t+ dt)  w - b wL Generalize linear algorithms AIMD (K=0, L=1); MIMD (K=-1, L=1) When L < 1, reductions are smaller than multiplicative-decrease Are there interesting TCP-friendly binomial algorithms?

The (K,L) space I: w(t+R)  w + a / wK D: w(t+ dt)  w - b wL Unstable AIMD AIAD MIAD MIMD 1 More aggressive than AIMD (-1 < K+L < 1) Less aggressive than AIMD (K+L > 1) SQRT (K=L=0.5) IIAD (K=1, L=0) K Unstable (K+L < -1) TCP-friendly K+L = 1

Window Evolution w(t) AIMD dw/dt = a / (wK RTT) Trade-off between increase aggressiveness and decrease magnitude TCP-friendliness rule: K+L = 1 t

Binomial Algorithms Benefit Layered MPEG-4 Delivery

CM Linux Implementation App stream Stream requests, updates cmapp_*() libcm.a User-level library; implements API System calls (e.g., ioctl) Control socket for callbacks TCP CM macroflows, kernel API UDP-CC Congestion controller Scheduler Prober ip_output() cm_notify() ip_output() IP

Server performance CPU seconds for 200K pkts cmapp_send() Buffered UDP-CC TCP, no delack TCP/CM, no delack TCP/CM, w/ delack TCP, w/ delack Packet size (bytes)

Status CM Linux alpha code release this week http://nms.lcs.mit.edu/projects/cm/ Sender-only CM soon to be up for proposed standard in IETF ECM working group WG document: draft-ietf-ecm-cm-02.txt Mailing list: ecm-request@aciri.org On-going work: Evaluation of “slowly responsive” algorithms Macroflow formation for diffserv Congestion control vs. feedback frequency CM scheduler algorithms Using binomial algorithms on high-speed paths

Summary Congestion Manager (CM) framework provides end-to-end adaptation platform for NGI applications and protocols CM enables: Adaptive applications using application-level framing (ALF) ideas Efficient multiplexing and stable control of concurrent flows by sharing path information Per-macroflow congestion control algorithms, including binomial algorithms for streaming media Download it!