1. Congestion Manager and its relevance to WebTP Rajarshi Gupta

2. Acknowledgements CM GROUP Hari Balakrishnan (MIT LCS) Hariharan S Rahul (MIT LCS) Srinivasan Seshan (IBM TJ Watson) SOURCES Paper in HotOS (March 99) MIT LCS Tech Report Presentation by Hari at Bell Labs http://inat.lcs.mit.edu/ projects/cm/

3. Congestion Management Challenges Heterogeneous traffic mix –Variety of applications and transports Multiple concurrent streams Separation from other tasks like loss recovery Stable control algorithms Enable applications

4. Integrated TCP Sessions r1 r-n r3 r2 Independent TCP connections, but shared control parameters [BPS+98, Touch98] Shared congestion windows, round-trip estimates But, this approach doesn’t accommodate non-TCP traffic Server Client

5. What is the World Heading Toward? The world won’t be just HTTP The world won’t be just TCP Logically different streams (objects) kept separate, yet efficient congestion management must be performed. u1 u-m u3 u2 r1 r2 r3 r-n Server Internet Client

6. What We Really Need… An integrated approach to end-to-end congestion management for the Internet IP HTTPVideo1 TCP1TCP2UDP AudioVideo2 Congestion Manager

7. Jobs of a CM Reacts to congestion Probes carefully and passively for spare bandwidth Receives feedback from the receivers (losses, status) Apportions available capacity between active flows

8. CM Properties Ensures proper and stable congestion behavior Enables application and transport adaptation to congestion via API Trusted intermediary between flows for bandwidth management Per-host & per-domain statistics (bandwidth, loss rates, RTT) Motivated by e2e argument and ALF

9. CM Features Algorithms and Protocols Adaptation API Applications & performance

10. CM Features Algorithms and protocols Adaptation API Applications & performance

11. CM Algorithms Rate-based AIMD control Loss-resilient feedback protocol Exponential aging when feedback is infrequent Flow segregation to handle non-best-effort networks Scheduler to apportion bandwidth between flows

12. TCP-friendly (?) rate-based control Friendly: Throughput goes as 1/sqrt(p) for AIMD scheme n r 2 = K { (n r /n d ) + 1 }, where n r = # recd and n d = # dropped is necessary and sufficient for verifying TCP “friendliness”

13. Receiver Feedback Implicit: hints from application –Losses, ECN (e.g TCP/CM) Explicit: CM probes –Probe every half RTT using loss-resilient protocol –Requires modification to receiver (CM) –Low overhead Tracks loss rate, RTT estimate

14. Why Feedback? Loss rate inversely prop to feedback frequency x times per RTT Loss probability Infrequent Feedback: Exponential aging Reduce rate by half, every RTT. Uses minimum RTT. SRTT too aggressive Continues to transmit at safe rate without clamping apps

15. Better than Best-effort ? Future networks will not treat all flows equally Per-host aggregation incorrect Solution: flow segregation based on loss rates and aggregrated throughput [Evaluation in-progress] Use per-flow QoS parameters in CM

16. CM Scheduler Currently HRR scheduler for rate allocation Uses pre-configured weights and receiver hints to apportion bandwidth between flows Application allowed to send the number of bytes allowed by the CM Experiments show it working well Exploring other scheduling algorithms for delay management as well (real-time)

17. CM Features Algorithms and protocols Adaptation API Applications & performance

18. CM API Principles Goal: To enable easy application adaptation Four guiding principles: –Put the application in control (give it rate - it can choose what to send) –Accommodate traffic heterogeneity –Accommodate application heterogeneity –Learn from the application (API should be flexible enough to learn different info)

19. CM API Structure Data Structure –cm_entry –cm_id Query –cm_query Control –cm_open –cm_request –cm_notify –cm_update –cm_close Callback –app_notify –change_rate

20. Functioning of CM API Apps use cm_query to enquire about state App requests allocation using cm_request CM responds with app_notify App sends any data it pleases, up to allocation App informs CM of tx using cm_notify App can give extra fedback with cm_update CM may change rate using change_rate

21. API should not force particular application style Asynchronous transmitters (e.g., TCP) –Triggered by events other than periodic clocks –Request/callback/notify works well Synchronous transmitters –Maintain internal timer for transmissions –Need rate change triggers from CM change_rate(newrate); Application Heterogeneity

22. CM Features Algorithms and protocols Adaptation API Applications & performance

23. Application 1: Web/TCP Web server uses change_rate() to pick source encoding

24. CM Web Performance With CM CM greatly improves performance predictability and consistency TCP Newreno Time (s) Sequence number

25. Application 2: Layered Streaming Audio Time (s) Sequence number Competing TCP TCP/CM Audio/CM Wanted TCP/CM + Audio/CM to equal TCP

26. CM Conclusions CM ensures proper and stable congestion behavior –CM tells flows their rates Simple, yet powerful API to enable application adaptation –Application is in control of what to send Improves performance consistency and predictability for individual applications and makes them better network citizens ;-)

27. Proposed WebTP Architecture Application User-centric Optim., Data Model MEASUREMENTSMEASUREMENTS Light-weight Connection Protocol API Congestion Mgr API $ IP

28. CM in WebTP How it Fits in Architecture diagram ALF motivation Learn from co-located flows Rate-based flow control QoS and CoS How it Doesn’t Strictly sender-based Too much API overhead (App  CM  FlowTP) Need separate control for reliability