Congestion Control Workshop Exploring Potential Solutions

1. Congestion Control WorkshopExploring Potential Solutions July 28, 2012

2. Goals • Goal of this session is to discuss potential building blocks and the situations in which they may apply. • Topics: • Frequency and semantics of feedback • Congestion indications: delay, loss, ECN • Response to indications • APIs • Tools • AQM/ECN/PCN • CoDel • RTCP, TCP/SCTP • QoS(DiffServ, IntServ) • Papers 1, 7, 8, 12, 13, 14, 15, 19, 21, 27, 28, 31, 32

3. The RTCWEB application Collaborative slides for the Real Time Congestion Control Workshop

4. Pokerstars example In a Javascript RTCWEB app, instead of avatars and text chat, you could see live video and audio.

5. WEBRTC Software architecture

6. Content prioritization in RTCWEB Desirable property: • Reduce bitrate of streams that can spare it • Add bitrate to streams that benefit • In RTCWEB contexts, the Javascript application knows best how to stack rank streams' needs • The browser must implement the prioritization and do the actual adaptation of send rate

7. Doing the Important Stuff First/Best Desirable properties: • Communication path to show importance • A Javascript API to set and get priority info • RTCWEB uses a separate (un-standardizied) signalling path between applications • Handles for classification at other nodes • RTCWeb uses standard SRTP for media data • Port, PT and SSRC in the clear • SCTP over DTLS is "one flow" to the network • Detection of proper flow groupings • RTCWeb can do semantic groupings • Setting of DSCP proposed, not standardized yet

8. The Google Delay-Based CC Proposal • Originally designed for retrofit into existing systems • Measures one-way delay at receiver, using a filter function to estimate delay • Decreases bandwidth estimate when delay increases • Increases bandwidth when delay's been decreasing or stable for a while • Returns feedback on a "when needed" basis, using TMMBR or a new message

9. Network-Assisted Dynamic Adaptation (NADA): A Design Summary Xiaoqing Zhu and Rong Pan Advanced Architecture & Research Cisco Systems July 2012

10. Design Goal of NADA Application-level priority Relative bandwidth In case of congestion, bandwidth sharing among flows:

11. A Suite of Feedback Mechanisms PCN-based Performance ECN-based Delay-based existing feature none new feature Network support

12. System Diagram measure delay/marking periodic RTCP report (delay/ECN/PCN) optimal rate calculation adaptive FEC calculation video playout target rate FEC percentage update network congestion notification encoder rate adaptation video packets sender network node receiver

13. Example Results • bottleneck link of 30 Mbps • ten competing flows in two classes • PCN marking with 90% target link utilization Class B: 2~6 Mbps Class A: 1~3 Mbps Zero standing queue

14. Thoughts on Real-time Congestion Control (# 27)Congestion Control for Interactive Real-Time Applications (#13) Sanjeev Mehrotra Murari Sridharan, Jin Li

15. Existing protocol issues • Need: Congestion Control at Low Congestion Level • Loss based TCP variants and TFRC do not work well due to high queuing delay and packet loss • Existing low congestion level (delay based / ECN based) algorithms have issues working well on noisy networks (EV-DO, HSPA, LTE, Wi-Fi, WiMAX) as noise may be falsely classified as congestion • Available bandwidth estimation (ABE) techniques do not work well on noisy networks for similar reasons

16. DCTCP using ECN • Used to be a chicken and egg problem but modern OS’ enabled ECN functionality • Standard TCP’s use of ECN results in loss of link utilization • In DCTCP • Mark based on instantaneous queue length, no nominal RTT configuration • Sources average based on ECN marks • Full link utilization as sources react to the extent of congestion not the presence. • Similar or even the same controller can be built on top of UDP using ECN to sense congestion

17. Delay Based Congestion Control • Use of delay-based Utility Maximization based rate control framework to adjust rate • Use hybrid rate + window based rate control to prevent burst of packets from being mistaken for congestion • Use appropriate congestion signals to control rate

18. Conclusion Real-time CC should useall available signals such as ECN, packet loss and queuing delay. Use congestion signals and thresholds to achieve lowest congestion levels possible Incentivizing ECN deployment, what can the IETF do here? Operators are engaged more so than before.

19. Coupled Control Loops and APIs Varun Singh, Jörg Ott, and Colin Perkins

20. Codecs and Congestion Control • Codec has limited scope for adaptation – what rates it can adopt, and how rapidly • Congestion control will be more stable if it knows the limitations of the codec, and can compensate – this requires coupling between layers, and additional reporting from the codec • Codec sends data in bursts, many implementations operate as black boxes, but they could offer more control and flexibility • Schedule codec bursts around estimated network queuing capacity • Potential significant gains from closer coupling between codec and congestion control – how can the API be designed to achieve these?

21. Semantic Loss Feedback • RTCP under RTP/AVPF can report most loss events – but not most lost packets • TCP similarly only responds to one loss event per RTT – difference is we can only report on approximately one event per RTT • Be smart in use of limited reporting bandwidth: semantic loss reports, not packet loss reports • A PLI/SLI is more meaningful and more efficient than a list of lost packets; and potentially allows smarter loss repair • RTCP has much richer semantic feedback than TCP – how can we use it?

22. There is NoMagic Transport Wand • (paper #14) • John Leslie (JLC.net) • July 28, 2012 • IAB/IRTF Workshop on Congestion Control for • Interactive Real-Time Communication

23. Work is needed at Network layer to improve timeliness of congestion signals • ECN must be enabled and made attractive to deploy • CoDel-style AQM is needed to cure buffer-bloat • “Backpressure” from uplink router deserves (separate) effort

24. Work is needed at Transport layer to establish a “heartbeat” rigor • Feedback according to a strict schedule ensures the feedback is timely • ECN (and CoDel AQM) deserve to be engaged in both directions • Signaling congestion to the application layer must be standardized

25. Work is needed at Application layer to negotiate sender’s data rate reduction • Video framerate can be varied (possibly to zero) • Video & audio resolution could be varied • Audio “silence” can be more aggressively inferred • Explicit (or derivable) timing signals are needed for lipsync

26. Addressing BufferBloat • Tail-drop buffers have no control of time-in-buffer • Traditional AQM takes no action until buffer “full” • CoDel measures time-in-queue at every dequeue • CoDel considers time-in-queue >one RTT “bad” • CoDel drops when delay > “target” for “interval” • “target” is 5 msec; “interval” is approximate RTT

27. Recognizing Congestion Quickly • Tail-drop buffers have no control of time-in-buffer • Traditional AQM takes no action until buffer “full” • CoDel measures time-in-queue at every dequeue • CoDel considers time-in-queue >one RTT “bad” • CoDel drops when delay > “target” for “interval” • Gives the best chance of keeping delay >150 msec

28. Competing Traffic Problems • “Normal” TCP traffic needs to buffer one RTT • Multiple TCP connections can buffer multiple RTTs • SCTP can do multiple flows buffering only one RTT • LEDBAT backs off if delay>100 msec, but not if delay<150 msec • Native RTCP reacts much too slowly • CoDel could hold the sum to about 100 msec • “Back-pressure” could feedback actual egress delay