[R-C] Charter update

[Stefan Holmer]

Sounds good to me.

/Stefan

On Mon, Aug 13, 2012 at 9:40 AM, Michael Welzl <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 <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 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
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120813/70b96953/attachment-0001.html>