<html>
<body>
Michael,<br><br>
A few suggestions for minor changes, but otherwise, no big
objections:<br><br>
s/• Reasonable share of bandwidth when competing with RMCAT traffic,
other real-time media protocols, and ideally also TCP and other
protocols/<br>
/• Reasonable share of bandwidth when competing with RMCAT traffic,
other real-time media protocols, TCP and other congestion control
protocols. A 'reasonable share' means that no flow has a significantly
negative impact [RFC5033] on other flows and at minimum that no flow
starves./<br><br>
s/The work will be guided by the advice laid out in RFC 5405 (UDP usage
guidelines) and RFC 2914 (congestion control principles)./<br>
/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)./<br><br>
s/The following topics are out of scope:/<br>
/The following topics are out of scope of this working group, on
the assumption that work on them will proceed elsewhere:/<br><br>
<br><br>
Bob<br><br>
At 12:31 13/08/2012, Stefan Holmer wrote:<br>
<blockquote type=cite class=cite cite="">Sounds good to me.<br><br>
/Stefan<br><br>
On Mon, Aug 13, 2012 at 9:40 AM, Michael Welzl
<<a href="mailto:michawe@ifi.uio.no">michawe@ifi.uio.no</a>>
wrote:<br>
<dl>
<dd>Folks,<br><br>
<dd>I sense a lot of tacit approval ;-)<br><br>
<dd>Is this now ready to be shipped to the IESG?<br><br>
<br>
<dd>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>
<dd>Cheers,<br>
<dd>Michael<br><br>
<br><br>
<dd>On 10. aug. 2012, at 13:02, Michael Welzl wrote:<br><br>
<dd>> See below for an update of the charter:<br>
<dd>><br>
<dd>> - some minor fixes, e.g. wording in the list of
deliverables<br>
<dd>> - the most significant change: updated milestone list<br>
<dd>><br>
<dd>> Comments?<br>
<dd>><br>
<dd>> Cheers,<br>
<dd>> Michael<br>
<dd>><br>
<dd>><br>
<dd>>
*******************************************************************************************<br>
<dd>><br>
<dd>><br>
<dd>> RTP Media Congestion Avoidance Techniques (rmcat)<br>
<dd>><br>
<dd>> Status: Proposed Working Group<br>
<dd>> Last Updated: 2012-08-10<br>
<dd>><br>
<dd>> Chair(s):<br>
<dd>> TBD<br>
<dd>><br>
<dd>> Transport Area Director(s):<br>
<dd>> Wesley Eddy
<<a href="mailto:wes@mti-systems.com">wes@mti-systems.com</a>><br>
<dd>><br>
<dd>> Transport Area Advisor:<br>
<dd>> Wesley Eddy
<<a href="mailto:wes@mti-systems.com">wes@mti-systems.com</a>><br>
<dd>><br>
<dd>> Mailing Lists: TBD (until establishment, we use
<a href="mailto:rtp-congestion@alvestrand.no">
rtp-congestion@alvestrand.no</a>)<br>
<dd>><br>
<dd>> Description of Working Group<br>
<dd>><br>
<dd>> 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>
<dd>> There is no generally accepted congestion control mechanism for
this kind of data flow.<br>
<dd>> 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>
<dd>><br>
<dd>> 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>
<dd>> • Low delay and low jitter
for the case where there is no competing traffic using other
algorithms<br>
<dd>> • Reasonable share of
bandwidth when competing with RMCAT traffic, other real-time media
protocols, and ideally also TCP and other protocols<br>
<dd>> • Effective use of signals
like packet loss and ECN markings to adapt to congestion<br>
<dd>><br>
<dd>> The working group will:<br>
<dd>> • 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>
<dd>> • Define interactions
between applications and RTP flows to enable specifying requirements such
as per-packet priorities.<br>
<dd>> • 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>
<dd>> • 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>
<dd>> • Develop a mechanism for
identifying and controlling groups of flows.<br>
<dd>> • Define evaluation criteria
for proposed mechanisms, and publish these as an Informational RFCs.<br>
<dd>> • 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>
<dd>> • Publish evaluation
criteria and the result of experimentation with these Experimental
algorithms on the Internet<br>
<dd>> • 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>
<dd>><br>
<dd>> The work will be guided by the advice laid out in RFC 5405 (UDP
usage guidelines) and RFC 2914 (congestion control principles).<br>
<dd>><br>
<dd>> The following topics are out of scope:<br>
<dd>> • Circuit-breaker algorithms
for stopping media flows when network conditions render them useless;
this work is done in AVTCORE;<br>
<dd>> • Media flows for
non-interactive purposes like stored video playback; those are not as
delay sensitive as interactive traffic;<br>
<dd>> • Defining active queue
management; modifications to TCP of any kind; and<br>
<dd>> • Multicast congestion
control (common control of multiple unicast flows is in scope).<br>
<dd>> • Topologies other than
point-to-point connections. Implications on multi-hop connections will be
considered at a later stage.<br>
<dd>><br>
<dd>> 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>
<dd>> 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>
<dd>><br>
<dd>> Deliverables<br>
<dd>> • Requirements for
congestion control algorithms for interactive real time media -
Informational RFC<br>
<dd>> • Evaluation criteria for
congestion control algorithms for interactive real time media -
Informational RFC<br>
<dd>> • RTCP extensions for use
with congestion control algorithms - Standards-track RFC<br>
<dd>> • Interactions between
applications and RTP flows - Informational RFC<br>
<dd>> • Identifying and
controlling groups of flows - Standards-track RFC<br>
<dd>> • Techniques to detect,
instrument or diagnose failing to meet RT schedules - Informational
RFC<br>
<dd>> • Candidate congestion
control algorithm for interactive real time media - Experimental RFCs
(likely more than one)<br>
<dd>> • Experimentation and
evaluation results for candidate congestion control algorithms -
Informational RFC<br>
<dd>> • A recommended congestion
control algorithm for interactive real time media - Standards-track
RFC<br>
<dd>><br>
<dd>> Milestones<br>
<dd>> • NN NNNA: (chartering + 1
month) Publish first drafts of requirements and evaluation criteria<br>
<dd>> • NN NNNB: (=A) publish
first drafts of RTCP extensions for use with congestion control
algorithms and interactions between applications and RTP flows<br>
<dd>> • NN NNNC: Adopt first
congestion control candidate as WG draft<br>
<dd>> • NN NNND: (B + 2 months)
Publish first draft of identifying and controlling groups of flows<br>
<dd>> • NN NNNE: (A + 4 months)
Submit requirements and evaluation criteria to IESG as Informational<br>
<dd>> • 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>
<dd>> • NN NNNG: (E + 2 months)
Submit first congestion control candidate to IESG for Experimental
publication<br>
<dd>> • NN NNNH: (D + 6 months)
Submit identifying and controlling groups of flows to IESG for
Standards-track publication<br>
<dd>> • NN NNNI: (G + 3 months)
First draft of evaluation results<br>
<dd>> • NN NNNJ: (=I) First draft
of standards-track congestion control<br>
<dd>> • NN NNNK: (=J) First draft
of techniques to detect, instrument or diagnose failing to meet RT
schedules<br>
<dd>> • NN NNNL: (K + 6 months)
Submit techniques to detect, instrument or diagnose failing to meet RT
schedules to IESG as Informational<br>
<dd>> • NN NNNM: (J + 8 months)
Submit congestion control to IESG for Proposed Standard<br>
<dd>> (time from chartering to end of charter is 18 months)<br>
<dd>><br>
<dd>><br>
<dd>> _______________________________________________<br>
<dd>> Rtp-congestion mailing list<br>
<dd>>
<a href="mailto:Rtp-congestion@alvestrand.no">
Rtp-congestion@alvestrand.no</a><br>
<dd>>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br><br>
<dd>_______________________________________________<br>
<dd>Rtp-congestion mailing list<br>
<dd><a href="mailto:Rtp-congestion@alvestrand.no">
Rtp-congestion@alvestrand.no</a><br>
<dd>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a><br><br>
</dl><br>
_______________________________________________<br>
Rtp-congestion mailing list<br>
Rtp-congestion@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a></blockquote>
<x-sigsep><p></x-sigsep>
________________________________________________________________<br>
Bob
Briscoe,
BT Innovate & Design</body>
</html>