congestion control workshop exploring potential solutions n.
Skip this Video
Loading SlideShow in 5 Seconds..
Congestion Control Workshop Exploring Potential Solutions PowerPoint Presentation
Download Presentation
Congestion Control Workshop Exploring Potential Solutions

Loading in 2 Seconds...

play fullscreen
1 / 28

Congestion Control Workshop Exploring Potential Solutions - PowerPoint PPT Presentation

  • Uploaded on

Congestion Control Workshop Exploring Potential Solutions. July 28, 2012. 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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Congestion Control Workshop Exploring Potential Solutions' - ulmer

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
  • 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
    • CoDel
    • QoS(DiffServ, IntServ)
  • Papers 1, 7, 8, 12, 13, 14, 15, 19, 21, 27, 28, 31, 32
the rtcweb application

The RTCWEB application

Collaborative slides for the Real Time Congestion Control Workshop

pokerstars example
Pokerstars example

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

content prioritization in rtcweb
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
doing the important stuff first best
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
the google delay based cc proposal
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
network assisted dynamic adaptation nada a design summary

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

Xiaoqing Zhu and Rong Pan

Advanced Architecture & Research

Cisco Systems

July 2012

design goal of nada
Design Goal of NADA

Application-level priority

Relative bandwidth

In case of congestion, bandwidth sharing among flows:

a suite of feedback mechanisms
A Suite of Feedback Mechanisms








new feature

Network support

system diagram
System Diagram




RTCP report


optimal rate calculation

adaptive FEC calculation







update network

congestion notification


rate adaptation




network node


example results
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


Thoughts on Real-time Congestion Control (# 27)Congestion Control for Interactive Real-Time Applications (#13)

Sanjeev Mehrotra

Murari Sridharan, Jin Li

existing protocol issues
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
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
delay based congestion control
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

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.

coupled control loops and apis

Coupled Control Loops and APIs

Varun Singh, Jörg Ott, and Colin Perkins

codecs and congestion control
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?
semantic loss feedback
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?
there is no magic transport wand
There is NoMagic Transport Wand
  • (paper #14)
  • John Leslie (
  • 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
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
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
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
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
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
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