[R-C] Charter

[Michael Welzl]

Hi all,

About congestion control vs. congestion avoidance: my personal opinion was that it's really the same, and using "congestion control" is just fine. I agreed with the suggestion to go for "congestion avoidance" because I didn't care, but Matt's argument convinces me. Indeed, congestion avoidance, as introduced in the seminal paper about that, refers to a phase of TCP, and is hence a bit misleading. It's possible that this charter could be interpreted to mean that we're really only interested in replacing this specific phase of TCP, but keep the rest (slow start etc.) for interactive real-time apps. Congestion control clearly refers to the whole thing, and so I went back to that wording now.  (just using "avoid congestion" is a more significant change to the text).

About John's last suggestion: " I'm not particular about the wording, but I think the charter needs at least a hint that the congestion-avoidance aims are different than TCP."  I have now incorporated that, just before the list of requirements; I hope you like the way I phrased it.

I think it's high time for me to share my current version, sorry for not having done that up to now - I was expecting to do internal updates first and then start the wordsmithing, but you guys seem to be fully at it already  :-)

I'm attaching a pdf of a version I produced with Word, where I added comments about who said what. Not everything is from the mailing list, some things come directly from the BOF. Yes, having the minutes would be helpful too, I know... I hope we'll have them soon.  I'm also copy+pasting the whole thing at the bottom of this email in plain text for your convenience - sorry if the formatting turns out strange.

Cheers,
Michael

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rmcatcharterafterbof.pdf
Type: application/pdf
Size: 87226 bytes
Desc: not available
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120808/e701f7e8/attachment-0001.pdf>
-------------- next part --------------


************************************
copy+pasted version:


Internal comments


	? The milestones need to be updated (more relaxed - though a suggestion was to finish soon with something that is replaceable...), but let?s perhaps first agree on the rest.


RTP Media Congestion Avoidance Techniques (rmcat)

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

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 examples, 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
	? 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.
	? Define interactions between applications and RTP flows to enable signalling 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 CCIDs, 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.
	? 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.
	? Develop a mechanism for jointly controlling multiple flows that may each experience different treatment by the network.

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;
	? 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
	? Define interactions between applications and RTP flows for signaling requirements such as per-packet priorities - Standards-track 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 
	? A mechanism for joint control of multiple flows that may each experience different treatment by the network - Standards-track RFC 
Milestones


	? NN NNNA: (chartering + 1 month) Publish first drafts of requirements and evaluation criteria
	? 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 publication
	? 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)