Sounds good to me.<div><br></div><div>/Stefan<br><br><div class="gmail_quote">On Mon, Aug 13, 2012 at 9:40 AM, Michael Welzl <span dir="ltr"><<a href="mailto:michawe@ifi.uio.no" target="_blank">michawe@ifi.uio.no</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Folks,<br>
<br>
I sense a lot of tacit approval ;-)<br>
<br>
Is this now ready to be shipped to the IESG?<br>
<br>
<br>
Okay, I'm trying to be provocative, to get some feedback... but seriously, I think that there wasn't a lot of debate (in the sense of disagreement) about the charter, just constructive suggestions. I do believe that I have incorporated most, if not all of them in this version. So I'd like to try using a deadline: could we say that I ship this off on Wednesday 15 August unless I receive suggestions for changes by then?<br>
<br>
Cheers,<br>
Michael<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 10. aug. 2012, at 13:02, Michael Welzl wrote:<br>
<br>
> See below for an update of the charter:<br>
><br>
> - some minor fixes, e.g. wording in the list of deliverables<br>
> - the most significant change: updated milestone list<br>
><br>
> Comments?<br>
><br>
> Cheers,<br>
> Michael<br>
><br>
><br>
> *******************************************************************************************<br>
><br>
><br>
> RTP Media Congestion Avoidance Techniques (rmcat)<br>
><br>
> Status: Proposed Working Group<br>
> Last Updated: 2012-08-10<br>
><br>
> Chair(s):<br>
> TBD<br>
><br>
> Transport Area Director(s):<br>
> Wesley Eddy <<a href="mailto:wes@mti-systems.com">wes@mti-systems.com</a>><br>
><br>
> Transport Area Advisor:<br>
> Wesley Eddy <<a href="mailto:wes@mti-systems.com">wes@mti-systems.com</a>><br>
><br>
> Mailing Lists: TBD (until establishment, we use <a href="mailto:rtp-congestion@alvestrand.no">rtp-congestion@alvestrand.no</a>)<br>
><br>
> Description of Working Group<br>
><br>
> 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.<br>
> There is no generally accepted congestion control mechanism for this kind of data flow.<br>
> 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.<br>
><br>
> 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:<br>
> • Low delay and low jitter for the case where there is no competing traffic using other algorithms<br>
> • Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols<br>
> • Effective use of signals like packet loss and ECN markings to adapt to congestion<br>
><br>
> The working group will:<br>
> • 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.<br>
> • Define interactions between applications and RTP flows to enable specifying requirements such as per-packet priorities.<br>
> • 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.<br>
> • 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.<br>
> • Develop a mechanism for identifying and controlling groups of flows.<br>
> • Define evaluation criteria for proposed mechanisms, and publish these as an Informational RFCs.<br>
> • 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.<br>
> • Publish evaluation criteria and the result of experimentation with these Experimental algorithms on the Internet<br>
> • 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.<br>
><br>
> The work will be guided by the advice laid out in RFC 5405 (UDP usage guidelines) and RFC 2914 (congestion control principles).<br>
><br>
> The following topics are out of scope:<br>
> • Circuit-breaker algorithms for stopping media flows when network conditions render them useless; this work is done in AVTCORE;<br>
> • Media flows for non-interactive purposes like stored video playback; those are not as delay sensitive as interactive traffic;<br>
> • Defining active queue management; modifications to TCP of any kind; and<br>
> • Multicast congestion control (common control of multiple unicast flows is in scope).<br>
> • Topologies other than point-to-point connections. Implications on multi-hop connections will be considered at a later stage.<br>
><br>
> 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.<br>
> 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.<br>
><br>
> Deliverables<br>
> • Requirements for congestion control algorithms for interactive real time media - Informational RFC<br>
> • Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC<br>
> • RTCP extensions for use with congestion control algorithms - Standards-track RFC<br>
> • Interactions between applications and RTP flows - Informational RFC<br>
> • Identifying and controlling groups of flows - Standards-track RFC<br>
> • Techniques to detect, instrument or diagnose failing to meet RT schedules - Informational RFC<br>
> • Candidate congestion control algorithm for interactive real time media - Experimental RFCs (likely more than one)<br>
> • Experimentation and evaluation results for candidate congestion control algorithms - Informational RFC<br>
> • A recommended congestion control algorithm for interactive real time media - Standards-track RFC<br>
><br>
> Milestones<br>
> • NN NNNA: (chartering + 1 month) Publish first drafts of requirements and evaluation criteria<br>
> • NN NNNB: (=A) publish first drafts of RTCP extensions for use with congestion control algorithms and interactions between applications and RTP flows<br>
> • NN NNNC: Adopt first congestion control candidate as WG draft<br>
> • NN NNND: (B + 2 months) Publish first draft of identifying and controlling groups of flows<br>
> • NN NNNE: (A + 4 months) Submit requirements and evaluation criteria to IESG as Informational<br>
> • 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<br>
> • NN NNNG: (E + 2 months) Submit first congestion control candidate to IESG for Experimental publication<br>
> • NN NNNH: (D + 6 months) Submit identifying and controlling groups of flows to IESG for Standards-track publication<br>
> • NN NNNI: (G + 3 months) First draft of evaluation results<br>
> • NN NNNJ: (=I) First draft of standards-track congestion control<br>
> • NN NNNK: (=J) First draft of techniques to detect, instrument or diagnose failing to meet RT schedules<br>
> • NN NNNL: (K + 6 months) Submit techniques to detect, instrument or diagnose failing to meet RT schedules to IESG as Informational<br>
> • NN NNNM: (J + 8 months) Submit congestion control to IESG for Proposed Standard<br>
> (time from chartering to end of charter is 18 months)<br>
><br>
><br>
> _______________________________________________<br>
> Rtp-congestion mailing list<br>
> <a href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a><br>
> <a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br>
<br>
_______________________________________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br>
</div></div></blockquote></div><br></div>