.

Coupled Congestion Control for RTP Media

When multiple congestion controlled RTP sessions traverse the same network bottleneck, it can be beneficial to combine their controls such that the total on-the-wire behavior is improved. This document describes such a method for flows that have the same sender, in a way that is as flexible and simple as possible while minimizing the amount of changes needed to existing RTP applications.

Details

[+] Coupled Congestion Control Architecture

We have opted for an approach that minimizes the amount of necessary changes to existing applications. It involves a central storage element called Flow State Exchange (FSE). The elements of the proposed architecture for coupled congestion control are: the Flow State Exchange (FSE), Shared Bottleneck Detection (SBD) and Flows. The FSE is a storage element that can be implemented in two ways: active and passive. In the active version, it initiates communication with flows and SBD. However, in the passive version, it does not actively initiate communication with flows and SBD; its only active role is internal state maintenance (e.g., an implementation could use soft state to remove a flow's data after long periods of inactivity). Every time a flow's congestion control mechanism would normally update its sending rate, the flow instead updates information in the FSE and performs a query on the FSE, leading to a sending rate that can be different from what the congestion controller originally determined. Using informationabout/from the currently active flows, SBD updates the FSE with the correct Flow State Identifiers (FSIs).


[+] The Flow State Exchange (FSE)

The FSE contains a list of all flows that have registered with it. For each flow, it stores the following for the active version of our Algorithm:

  • a unique flow number to identify the flow
  • the FGI of the FG that it belongs to (based on the definitions in this document, a flow has only one bottleneck, and can therefore
    be in only one FG)
  • a priority P, which here is assumed to be represented as a floating point number in the range from 0.1 (unimportant) to 1
    (very important). A negative value is used to indicate that a flow has terminated.
  • The rate used by the flow, FSE_R.
  • In the FSE, each FG contains one static variable S_CR which is meant to be the sum of the calculated rates of all flows in the same FG
    (including the flow itself). This value is used to calculate the sending rate.


[+] Algorithm - Active FSE
  1. When a flow f starts, it registers itself with SBD and the FSE. FSE_R and DR are initialized with the congestion controller's
    initial rate. SBD will assign the correct FGI. When a flow is assigned an FGI, it adds its FSE_R to S_CR.
  2. When a flow f stops, it deletes the flow.
  3. Every time the congestion controller of the flow f determines a new sending rate CC_R, the flow calls UPDATE, which carries out
    the tasks listed below to derive the new sending rates for all the flows in the FG. A flow's UPDATE function uses a local
    (i.e. per-flow) temporary variable: S_P, which is initialized to 0.
    • It updates S_CR and FSE_R(f) with CC_R.


      S_CR = S_CR + CC_R - FSE_R(f)
      FSE_R(f) = CC_R

    • It calculates the sum of all the priorities, S_P.

      for all flows i in FG do
      S_P = S_P + P(i)
      end for

    • It calculates the sending rates for all the flows in an FG
      and distributes them.

      for all flows i in FG do
      FSE_R(i) = (P(i)*S_CR)/S_P
      send FSE_R(i) to the flow i
      end for

News

  • Presentation on "Managing Real-Time Media Flows through a Flow State Exchange", IEEE NOMS 2016, Istabul Turkey
  • Our Draft is now a WG item of RMCAT
  • Paper Accepted at IEEE NOMS 2016

Recent Activity

  • Working with the Active version of the FSE to control RAP and TFRC. We are currently working with updating the FSE algorithm in order to make it a bit more conservative. The goal is to reduce queue growth and packet losses.
  • Identifying how LEDBAT works.

Milestones

  • Submission Deadline, IEEE NOMS, 2015, Deadline: September 1, 2015
  • Updating the draft for IETF 93.
  • Coupled congestion control with NADA
  • Controlling LEDBAT and SCTP via FSE [Ongoing].
  • Writing a paper based on the results achieved with RAP and TFRC.
  • Updating the draft for IETF 91.
  • Updating the draft for IETF 90.
  • Camera ready submission CSWS, Deadline: May 23

Papers in conference / workshop proceedings

  1. Safiqul Islam, Michael Welzl, David Hayes, Stein Gjessing: Managing Real-Time Media Flows through a Flow State Exchange, IEEE NOMS 2016, Istanbul, Turkey, 25-29 April 2016
  2. Safiqul Islam, Michael Welzl, Stein Gjessing, Naeem Khademi: "Coupled Congestion Control for RTP Media", ACM SIGCOMM Capacity Sharing Workshop (CSWS 2014), 18 August 2014, Chicago, USA. Best Paper Award
    • Also published in: ACM Computer Communication Review, volume 44, Issue 4, October 2014
  3. Safiqul Islam, Michael Welzl, Stein Gjessing, Naeem Khademi: "Coupled Congestion Control for WebRTC", In EuCNC Special session on latency, June/July 2015, Paris, France

Internet Drafts

Technical Reports

Poster

Presentation and Talks

  1. Managing Real-Time Media Flows through a Flow State Exchange, IEEE NOMS 2016, Istanbul, Turkey, 26 April 2016
  2. Updates on Coupled Congestion Control for RTP Media (draft-ietf-rmcat-coupled-cc-01) , 6 April 2016, RMCAT, 95th IETF meeting, Buenos Aires, Argentina. (pdf)
  3. Coupled Congestion Control for RTP Media (draft-ietf-rmcat-coupled-cc-00) , 6 November 2015, RMCAT, 94th IETF meeting, Yokohama, Japan. (pdf)
  4. Coupled Congestion Control for RTP Media (draft-welzl-rmcat-coupled-cc-05) , 20 July 2015, RMCAT, 93rd IETF meeting, Prague, Czech Republic. (pdf)
  5. Coupled Congestion Control for RTP Media (draft-welzl-rmcat-coupled-cc-04) , RMCAT, 92nd IETF meeting, Dallas, USA. (pdf) (pptx)
  6. RMCAT - Shared Bottleneck Detection and Coupled Congestion Control vs. QoS for WebRTC, 11. December 2014, Centre for Advanced Internet Architectures (CAIA), Swinburne University, Melbourne, VIC Australia. (pdf)
  7. Coupled Congestion Control for RTP Media (draft-welzl-rmcat-coupled-cc-04) , 12 November 2014, RMCAT, 91st IETF meeting, Honolulu, USA. (pdf)
  8. Coupled Congestion Control for RTP Media , ACM SIGCOMM Capacity Sharing Workshop (CSWS 2014), 18 August 2014, Chicago, USA. (pdf)
  9. Coupled congestion control for RTP media (draft-welzl-rmcat-coupled-cc-03), 24. July 2014, RMCAT, 90th IETF meeting, Toronto, Canada. (pdf) (pptx)
  10. Coupled congestion control for RTP media, 6. November 2013, RMCAT, 88th IETF meeting, Vancouver, Canada. (pdf) (pptx)
  11. Coupled Congestion Control for RTP Media, August 1. 2013, 87th IETF Meeting, Berlin Germany.(pptx)((Audio) - starting from 1:10:48)
  12. Tightly Coupled Congestion Control in WebRTC, Upperside WebRTC Conference, 12 October 2012, Paris, France. (pdf) (pptx)
  13. Coupled Congestion Control, RITE Project Meeting, London, 2012

Simulation Results and Sources