[R-C] BOF request: RMCAT - RTP Media Congestion Avoidance Techniques

Harald Alvestrand harald at alvestrand.no
Thu May 24 15:30:32 CEST 2012


The proposers would like to request a 2-hour slot for a BOF in Vancouver 
on the subject of RTP Congestion Control.

The proposed acronym is RMCAT - RTP Media Congestion Avoidance Techniques.

Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC and any video 
codec BOF, TCPM and relevant transport WGs

Expected attendance: 60 persons.

BOF agenda
----------------
Chairs: Randell Jesup and Harald Alvestrand

Area: TSV
Area directors: Wesley Eddy, Martin Stiemerling

The following is a draft agenda, subject to modifications. Names are 
tentative.
Intro (Chairs - 5 min)
Problem statement (Harald/Randell) - 25 min
Covers existing protocols and their effect on low-delay streams.
Addresses limiting the scope of this effort to a "probably solvable 
problem".
Includes a report from the IAB workshop on the same topic on Saturday
Context setting: BufferBloat & AQM (10 min) (Gettys)
RRTCC draft (10 min) (Stefan)
Describes existing proposal, Covering areas for improvement
Alternative Solution (10 min) (?)
    Modified Cx-TCP??  Modified TFRC???
Charter presentation, discussion (50 min)
Next steps/conclusion (10 min)
Total timeslot: 2 hours.

WG charter (proposed)
-------------------------------

RTP Media Congestion Avoidance Techniques (rmcat)

Status: Proposed Working Group
Last Updated: 2012-05-18

Chair(s):
  TBD

Transport Area Director(s):
  Wesley Eddy <wes at mti-systems.com>

Transport Area Advisor:
  Wesley Eddy <wes at mti-systems.com>

Mailing Lists: TBD (until establishment, we use 
rtp-congestion at alvestrand.no)

Description of Working Group

In today's current internet, part of the traffic is delivery of 
interactive real time media, often in the form of sets of media flows 
using RTP over UDP.
There is no generally accepted congestion control mechanism for this 
kind of data flow.
With the deployment of applications using the RTCWEB protocol suite, the 
number of such flows is likely to increase, especially non-fixed-rate 
flows such as video or adaptive audio. There is therefore some urgency 
in specifying one or more congestion control mechanisms that can find 
general acceptance.

The set of requirements for such an algorithm includes, but is not 
limited to:
* Low delay for the case where there is no competing traffic using other 
algorithms
* Fair share of bandwidth when there is competing traffic using other 
algorithms
* Effective use of signals like packet loss and ECN markings to adapt to 
congestion

The working group will:
* Develop a clear understanding of the congestion control requirements 
for RTP flows, and document deficiencies of existing mechanisms such as 
TFRC with regards to these requirements
* Determine if there is an appropriate means to define standard RTP/RTCP 
extensions for carrying congestion control feedback, similar to how DCCP 
defines CCIDs, and if so, document such extensions as standards-track RFCs.
* Define evaluation criteria for proposed mechanisms, and publish these 
as an Informational RFCs.
* Find or develop candidate congestion control algorithms, verify that 
these can be tested on the Internet without significant risk, and 
publish one or more of these as Experimental RFCs.
* Publish the result of experimentation with these Experimental 
algorithms on the Internet
* Once an algorithm has been found or developed that meets the 
evaluation criteria, and has a satisfactory amount of documented 
experience on the Internet, publish this algorithm as a Standards Track 
RFC. There may be more than one such algorithm.

The work will be guided by the advice laid out in RFC 5405 (UDP usage 
guidelines) and RFC 2914 (congestion control principles).

The following topics are out of scope:
* Circuit-breaker algorithms for stopping media flows when network 
conditions render them useless; this work is done in AVTCORE.
* Media flows for non-interactive purposes like stored video playback; 
those are not as delay sensitive as interactive traffic.
* Modifications to TCP of any kind.

The working group is expected to work closely with the RAI area, 
including the underlying technologies being worked on in the AVTCORE and 
AVTEXT WGs, and the applications/protocol suites being developed in the  
CLUE and RTCWEB working groups.
It will also liaise closely with other Transport area groups working on 
congestion control, and with the Internet Congestion Control Research 
Group of the IRTF.

Deliverables

* Evaluation criteria for congestion control algorithms for interactive 
real time media - Informational RFC
* RTCP extensions for use with congestion control algorithms - 
Standards-track RFC
* Candidate congestion control algorithm for interactive real time media 
- Experimental RFCs (likely more than one)
* Experimentation and evaluation results for candidate congestion 
control algorithms - Informational RFC
* A recommended congestion control algorithm for interactive real time 
media - Standards-track RFC

Milestones

NN NNNA: (chartering + 1 month) Publish first draft of evaluation crieria
NN NNNB: Adopt first congestion control candidate as WG draft
NN NNNC: (A + 4 months) Submit evaluation criteria to IESG as Informational
NN NNND: (C + 1 month) Submit first congestion control candidate to IESG 
for Experimental publicaiton
NN NNNE: (D + 3 months) First draft of evaluation results
NN NNNF: (=E) First draft of standars-track congestion control
NN NNNG: (F + 6 months) Submit congestion control to IESG for Proposed 
Standard
(time from chartering to end of charter is 15 months)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120524/1f6e88b7/attachment-0001.html>


More information about the Rtp-congestion mailing list