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@ifi.uio.no>michawe@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@mti-systems.com>wes@mti-systems.com>
Transport Area Advisor: Wesley Eddy <<mailto:wes@mti-systems.com>wes@mti-systems.com>
Mailing Lists: TBD (until establishment, we
use <mailto:rtp-congestion@alvestrand.no>rtp-congestion@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@alvestrand.no>Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list <mailto:Rtp-congestion@alvestrand.no>Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
________________________________________________________________ Bob Briscoe, BT Innovate & Design
/• 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./
This does not work. The hedging language for TCP in the previous text ("idealy") is required because protecting RMCAT from TCP (and other protocols such as LEDBAT) can't be solved in general within the scope of this WG. We can try, and there are some partial solutions that will help some of the time, but there are no general solutions that really solve this problem. Adding the definition of reasonable share is fine. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Mon, Aug 13, 2012 at 7:03 AM, Bob Briscoe <bob.briscoe@bt.com> wrote:
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/
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 <michawe@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@mti-systems.com>
Transport Area Advisor: Wesley Eddy <wes@mti-systems.com>
Mailing Lists: TBD (until establishment, we use rtp-congestion@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
________________________________________________________________ Bob Briscoe, BT Innovate & Design
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On Aug 15, 2012, at 2:53 AM, Matt Mathis wrote:
/• 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./
This does not work. The hedging language for TCP in the previous text ("idealy") is required because protecting RMCAT from TCP (and other protocols such as LEDBAT) can't be solved in general within the scope of this WG. We can try, and there are some partial solutions that will help some of the time, but there are no general solutions that really solve this problem.
Adding the definition of reasonable share is fine.
So, the final thing could become:
/• 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, ideally, no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves./
(I just added "ideally" to Bob's text above) ?? Cheers, Michael
On 15 Aug 2012, at 09:03, Michael Welzl wrote:
On Aug 15, 2012, at 2:53 AM, Matt Mathis wrote:
/• 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./
This does not work. The hedging language for TCP in the previous text ("idealy") is required because protecting RMCAT from TCP (and other protocols such as LEDBAT) can't be solved in general within the scope of this WG. We can try, and there are some partial solutions that will help some of the time, but there are no general solutions that really solve this problem.
Adding the definition of reasonable share is fine.
So, the final thing could become:
/• 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, ideally, no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves./
(I just added "ideally" to Bob's text above)
I think Matt meant to keep it ("ideally") in its original place as he was ok with Bob's 'reasonable share' definition. Though it seems to me that RMCAT traffic will need to be able to compete on some basis with TCP, though the appropriate trade-offs are something that need to be defined by the group - e.g. competing with TCP on a low RTT/Q path may be perfectly feasible whilst maintaining RT media delay bounds and 'reasonable' bandwidth share, however on larger RTT/Q path this trade-off may not work. So I'd agree with keeping the hedging language. And leaving Bob's original reasonable share definition as there's unlikely to be a situation where squeezing out TCP or other flows entirely is going to be beneficial to RMCAT flows. Piers.
??
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On Aug 15, 2012, at 10:35 AM, Piers O'Hanlon wrote:
On 15 Aug 2012, at 09:03, Michael Welzl wrote:
On Aug 15, 2012, at 2:53 AM, Matt Mathis wrote:
/• 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./
This does not work. The hedging language for TCP in the previous text ("idealy") is required because protecting RMCAT from TCP (and other protocols such as LEDBAT) can't be solved in general within the scope of this WG. We can try, and there are some partial solutions that will help some of the time, but there are no general solutions that really solve this problem.
Adding the definition of reasonable share is fine.
So, the final thing could become:
/• 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, ideally, no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves./
(I just added "ideally" to Bob's text above)
I think Matt meant to keep it ("ideally") in its original place as he was ok with Bob's 'reasonable share' definition.
Ah yes, thanks - I think you're right and I misunderstood. So the final thing is:
/• Reasonable share of bandwidth when competing with RMCAT traffic, other real-time media protocols, and ideally also TCP and other protocols. A 'reasonable share' means that no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves./
i.e., the first sentence is back to what it was before, whereas the second is Bob's. (btw, Bob: I think your other two suggestions can be accepted without any further debate)
Though it seems to me that RMCAT traffic will need to be able to compete on some basis with TCP, though the appropriate trade-offs are something that need to be defined by the group - e.g. competing with TCP on a low RTT/Q path may be perfectly feasible whilst maintaining RT media delay bounds and 'reasonable' bandwidth share, however on larger RTT/Q path this trade-off may not work.
So I'd agree with keeping the hedging language. And leaving Bob's original reasonable share definition as there's unlikely to be a situation where squeezing out TCP or other flows entirely is going to be beneficial to RMCAT flows.
Copy that :-) Cheers, Michael
participants (4)
-
Bob Briscoe -
Matt Mathis -
Michael Welzl -
Piers O'Hanlon