[R-C] Charter to be shipped

[Michael Welzl]

Hi Wes,

Here's our charter, in a version that is ready for IESG review. Note  
that there was also some discussion about the name - other suggestions  
were "IMCC - Interactive Media Congestion Control" and "IRCC -  
Interactive RTP Congestion Control". I think that the discussion  
wasn't intense enough to indicate that people really care a lot about  
the name, though, and so I suggest to leave it as it is for now, just  
for simplicity.

(someone told me that the IESG in fact decides the name, when the time  
comes?)

Is "shipping to the IESG" accomplished by sending you this email?  :-)

Cheers,
Michael


*********************************


RTP Media Congestion Avoidance Techniques (rmcat)

Status: Proposed Working Group
Last Updated: 2012-08-10

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.

Congestion control algorithms for interactive real time media may need  
to be quite different from the congestion control of TCP: for example,  
some applications can be more tolerant to loss than delay and jitter.  
The set of requirements for such an algorithm includes, but is not  
limited to:
	• Low delay and low jitter for the case where there is no competing  
traffic using other algorithms
	• Reasonable share of bandwidth when competing with RMCAT traffic,  
other real-time media protocols, and ideally also TCP and other  
protocols. A 'reasonable share' means that no flow has a significantly  
negative impact [RFC5033] on other flows and at minimum that no flow  
starves.
	• 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.
	• Define interactions between applications and RTP flows to enable  
specifying requirements such as per-packet priorities.
	• Determine if there is an appropriate means to define standard RTP/ 
RTCP extensions for carrying congestion control feedback, similar to  
how DCCP defines congestion control mechanisms, and if so, document  
such extensions as standards-track RFCs.
	• Develop techniques to detect, instrument or diagnose failing to  
meet RT schedules due to failures of components outside of the charter  
scope, possibly in collaboration with IPPM.
	• Develop a mechanism for identifying and controlling groups of flows.
	• 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 evaluation criteria and 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), RFC 2914 (congestion control principles), and RFC5033  
(Specifying New Congestion Control Algorithms).

The following topics are out of scope of this working group, on the  
assumption that work on them will proceed elsewhere:
	• 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;
	• Defining active queue management; modifications to TCP of any kind;  
and
	• Multicast congestion control (common control of multiple unicast  
flows is in scope).
	• Topologies other than point-to-point connections. Implications on  
multi-hop connections will be considered at a later stage.

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
	• Requirements for congestion control algorithms for interactive real  
time media - Informational RFC
	• Evaluation criteria for congestion control algorithms for  
interactive real time media - Informational RFC
	• RTCP extensions for use with congestion control algorithms -  
Standards-track RFC
	• Interactions between applications and RTP flows - Informational RFC
	• Identifying and controlling groups of flows - Standards-track RFC
	• Techniques to detect, instrument or diagnose failing to meet RT  
schedules - Informational 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 drafts of  
requirements and evaluation criteria
	• NN NNNB: (=A) publish first drafts of RTCP extensions for use with  
congestion control algorithms and interactions between applications  
and RTP flows
	• NN NNNC: Adopt first congestion control candidate as WG draft
	• NN NNND: (B + 2 months) Publish first draft of identifying and  
controlling groups of flows
	• NN NNNE: (A + 4 months) Submit requirements and evaluation criteria  
to IESG as Informational
	• NN NNNF: (B + 6 months) Submit RTCP extensions for use with  
congestion control algorithms to IESG for Standards-track publication,  
and submit interactions between applications and RTP flows to IESG as  
Informational
	• NN NNNG: (E + 2 months) Submit first congestion control candidate  
to IESG for Experimental publication
	• NN NNNH: (D + 6 months) Submit identifying and controlling groups  
of flows to IESG for Standards-track publication
	• NN NNNI: (G + 3 months) First draft of evaluation results
	• NN NNNJ: (=I) First draft of standards-track congestion control
	• NN NNNK: (=J) First draft of techniques to detect, instrument or  
diagnose failing to meet RT schedules
	• NN NNNL: (K + 6 months) Submit techniques to detect, instrument or  
diagnose failing to meet RT schedules to IESG as Informational
	• NN NNNM: (J + 8 months) Submit congestion control to IESG for  
Proposed Standard
(time from chartering to end of charter is 18 months)