11

Congestion Control Workshop

Exploring 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 feedbackCongestion indications: delay, loss, ECNResponse to indicationsAPIs

• ToolsAQM/ECN/PCNCoDelRTCP, TCP/SCTPQoS (DiffServ, IntServ)

• Papers 1, 7, 8, 12, 13, 14, 15, 19, 21, 27, 28, 31, 32

The RTCWEB application

Collaborative slides for the Real Time Congestion Control Workshop

Pokerstars example

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

WEBRTC Software architecture

Content prioritization in RTCWEB

Desirable property:• Reduce bitrate of streams that can spare it• Add bitrate to streams that benefit

o In RTCWEB contexts, the Javascript application knows best how to stack rank streams' needs

o The browser must implement the prioritization and do the actual adaptation of send rate

Doing the Important Stuff First/Best

Desirable properties:• Communication path to show importance

o A Javascript API to set and get priority infoo RTCWEB uses a separate (un-standardizied) signalling path

between applications

• Handles for classification at other nodeso RTCWeb uses standard SRTP for media datao Port, PT and SSRC in the clearo SCTP over DTLS is "one flow" to the network

• Detection of proper flow groupingso RTCWeb can do semantic groupingso Setting of DSCP proposed, not standardized yet

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

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 9Cisco Confidential 9© 2011 Cisco and/or its affiliates. All rights reserved.

Network-Assisted Dynamic Adaptation (NADA): A Design Summary

Xiaoqing Zhu and Rong PanAdvanced Architecture & Research

Cisco Systems

July 2012

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 10

Design Goal of NADA

Relative bandwidth

Application-level priority

In case of congestion, bandwidth sharing among flows:

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 11

A Suite of Feedback Mechanisms

Delay-based

ECN-based

PCN-based

none existingfeature new feature

Network support

Perfo

rman

ce

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 12

video playout

optimal rate calculation

adaptive FEC calculation

encoderrate adaptation

periodic RTCP report

(delay/ECN/PCN)

video packets

network node

measure delay/marking

sender receiver

target rate FEC

percentage

update networkcongestion notification

System Diagram

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 13

Example Results• bottleneck link of 30 Mbps• ten competing flows in two classes• PCN marking with 90% target link utilization

Class A: 1~3 Mbps

Class B: 2~6 Mbps

Zero standing queue

Thoughts on Real-time Congestion Control (# 27)

Congestion Control for Interactive Real-Time Applications (#13)

Sanjeev MehrotraMurari Sridharan, Jin Li

Existing protocol issues

• Need: Congestion Control at Low Congestion Levelo Loss based TCP variants and TFRC do not work well

due to high queuing delay and packet losso 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

o Available bandwidth estimation (ABE) techniques do not work well on noisy networks for similar reasons

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

o Mark based on instantaneous queue length, no nominal RTT configurationo Sources average based on ECN markso 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

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

ΔR

k0 r

300kbps200kbps

Conclusion

• Real-time CC should use all 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.

Coupled Control Loops and APIs

Varun Singh, Jörg Ott, and Colin Perkins

Codecs and Congestion Control• Codec has limited scope for adaptation – what rates it can adopt,

and how rapidlyo 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 flexibilityo 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?

Semantic Loss Feedback• RTCP under RTP/AVPF can report most loss events – but not most

lost packetso 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 reportso 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?

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

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

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

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

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

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

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