[R-C] Charter update
Bob Briscoe
bob.briscoe at bt.com
Mon Aug 13 16:03:30 CEST 2012
Michael,
A few suggestions for minor changes, but otherwise, no big objections:
s/• Reasonable share of bandwidth when competing
with RMCAT traffic, other real-time media
protocols, and ideally also TCP and other protocols/
/• 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./
s/The work will be guided by the advice laid out
in RFC 5405 (UDP usage guidelines) and RFC 2914
(congestion control principles)./
/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)./
s/The following topics are out of scope:/
/The following topics are out of scope of this
working group, on the assumption that work on them will proceed elsewhere:/
Bob
At 12:31 13/08/2012, Stefan Holmer wrote:
>Sounds good to me.
>
>/Stefan
>
>On Mon, Aug 13, 2012 at 9:40 AM, Michael Welzl
><<mailto:michawe at ifi.uio.no>michawe at ifi.uio.no> wrote:
>Folks,
>
>I sense a lot of tacit approval ;-)
>
>Is this now ready to be shipped to the IESG?
>
>
>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?
>
>Cheers,
>Michael
>
>
>
>On 10. aug. 2012, at 13:02, Michael Welzl wrote:
>
> > See below for an update of the charter:
> >
> > - some minor fixes, e.g. wording in the list of deliverables
> > - the most significant change: updated milestone list
> >
> > Comments?
> >
> > 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 <<mailto:wes at mti-systems.com>wes at mti-systems.com>
> >
> > Transport Area Advisor:
> > Wesley Eddy <<mailto:wes at mti-systems.com>wes at mti-systems.com>
> >
> > Mailing Lists: TBD (until establishment, we
> use <mailto:rtp-congestion at alvestrand.no>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
> > • 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) 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
> > • 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)
> >
> >
> > _______________________________________________
> > Rtp-congestion mailing list
> > <mailto:Rtp-congestion at alvestrand.no>Rtp-congestion at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>_______________________________________________
>Rtp-congestion mailing list
><mailto:Rtp-congestion at alvestrand.no>Rtp-congestion at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>
>
>_______________________________________________
>Rtp-congestion mailing list
>Rtp-congestion at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/rtp-congestion
________________________________________________________________
Bob Briscoe, BT Innovate & Design
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120813/2d5789ea/attachment.html>
More information about the Rtp-congestion
mailing list