<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Additional request:<br>
<br>
Given that the related IAB workshop is on the Saturday before, and
that some of the important contributors have to leave as early as
Wednesday, we would like to request the BOF to be scheduled on
Monday or Tuesday if possible.<br>
<br>
Harald Alvestrand<br>
<br>
On 05/24/2012 03:30 PM, Harald Alvestrand wrote:
<blockquote cite="mid:4FBE37F8.60804@alvestrand.no" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
The proposers would like to request a 2-hour slot for a BOF in
Vancouver on the subject of RTP Congestion Control.<br>
<br>
The proposed acronym is RMCAT - RTP Media Congestion Avoidance
Techniques.<br>
<br>
Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC and any
video codec BOF, TCPM and relevant transport WGs<br>
<br>
Expected attendance: 60 persons.<br>
<br>
BOF agenda<br>
----------------<br>
Chairs: Randell Jesup and Harald Alvestrand<br>
<br>
Area: TSV<br>
Area directors: Wesley Eddy, Martin Stiemerling<br>
<br>
The following is a draft agenda, subject to modifications. Names
are tentative.<br>
Intro (Chairs - 5 min)<br>
Problem statement (Harald/Randell) - 25 min<br>
Covers existing protocols and their effect on low-delay streams.<br>
Addresses limiting the scope of this effort to a "probably
solvable problem".<br>
Includes a report from the IAB workshop on the same topic on
Saturday<br>
Context setting: BufferBloat & AQM (10 min) (Gettys)<br>
RRTCC draft (10 min) (Stefan)<br>
Describes existing proposal, Covering areas for improvement<br>
Alternative Solution (10 min) (?)<br>
Modified Cx-TCP?? Modified TFRC???<br>
Charter presentation, discussion (50 min)<br>
Next steps/conclusion (10 min)<br>
Total timeslot: 2 hours.<br>
<br>
WG charter (proposed)<br>
-------------------------------<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
RTP Media Congestion Avoidance Techniques (rmcat)<br>
<br>
Status: Proposed Working Group<br>
Last Updated: 2012-05-18<br>
<br>
Chair(s):<br>
TBD<br>
<br>
Transport Area Director(s):<br>
Wesley Eddy <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:wes@mti-systems.com"><wes@mti-systems.com></a><br>
<br>
Transport Area Advisor:<br>
Wesley Eddy <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:wes@mti-systems.com"><wes@mti-systems.com></a><br>
<br>
Mailing Lists: TBD (until establishment, we use <a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
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>
The set of requirements for such an algorithm includes, but is not
limited to:<br>
* Low delay for the case where there is no competing traffic using
other algorithms<br>
* Fair share of bandwidth when there is competing traffic using
other algorithms<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>
* 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.<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 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>
* Modifications to TCP of any kind.<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>
<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>
* 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>
<br>
NN NNNA: (chartering + 1 month) Publish first draft of evaluation
crieria<br>
NN NNNB: Adopt first congestion control candidate as WG draft<br>
NN NNNC: (A + 4 months) Submit evaluation criteria to IESG as
Informational<br>
NN NNND: (C + 1 month) Submit first congestion control candidate
to IESG for Experimental publicaiton<br>
NN NNNE: (D + 3 months) First draft of evaluation results<br>
NN NNNF: (=E) First draft of standars-track congestion control<br>
NN NNNG: (F + 6 months) Submit congestion control to IESG for
Proposed Standard<br>
(time from chartering to end of charter is 15 months)<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Rtp-congestion mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Rtp-congestion@alvestrand.no">Rtp-congestion@alvestrand.no</a>
<a class="moz-txt-link-freetext" href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion">http://www.alvestrand.no/mailman/listinfo/rtp-congestion</a>
</pre>
</blockquote>
<br>
</body>
</html>