August 2012 - Rtp-congestion

Fwd: video and TCP interaction
by Matt Mathis 29 Aug '12

29 Aug '12

This seem particularly relevant here. Confused, Timid, and Unstable: Picking a Video Streaming Rate is Hard http://www.stanford.edu/~huangty/videoRateAdapt.pdf >From IMC 2012 Thanks, --MM--

6 5

Draft meeting minutes from the BOF
by Michael Welzl 24 Aug '12

24 Aug '12

Dear all, Please find below the minutes from the RMCAT BOF, and please let us have any comments / fixes by the end of the week. Thanks! Cheers, Michael Minutes of the RTP Media Congestion Avoidance Techniques (RMCAT) BoF Reported by Colin Perkins The RMCAT BoF was held from 13:00-15:00 on 2 August 2012 at the IETF 84 meeting in Vancouver, Canada. The chairs were Michael Welzl (University of Oslo) and Colin Perkins (University of Glasgow). The BoF grew out of discussions around the RTCWEB working group, and was coordinated on the <rtp‐congestion(a)alvestrand.no> mailing list. Introduction Slides: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-1.pdf The chairs introduced the BoF. The IETF and W3C are currently developing standards for video conferencing in web browsers, using an RTP-based media layer. The resulting systems are expected to see wide deployment. This is potentially problematic, since standards for RTP congestion control are not well developed. This risks causing congestion collapse in the Internet in the worst case, and in the short-term may disrupt the quality of experience due to interactions between flows. The main goal of this BoF is to understand the problem, and agree on a process for finding a solution. Problem Statement Slides: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-5.pdf Harald Alvestrand gave a more detailed outline of the problem statement. He noted that the Internet is dominated by TCP traffic, and that real- time interactive traffic is a niche, comprising mostly low-bandwidth VoIP and gaming flows, generally running on managed or high capacity networks. RTCWEB is aiming to change this, deploying interactive and high-bandwidth video on unmanaged and variable quality networks. Harald re-iterated the potential for congestion collapse due to these flows, and noted also that a consequence of the interactive nature of these applications is that low delay is as important as a sufficient bandwidth allocation. He also noted that these applications, while being relatively high bandwidth, have both upper- and lower-bounds on the bandwidth they can consume. Several mechanisms exist that might be considered for congestion control of interactive real-time applications. TCP can be said to deliver obsolete data reliably, encouraging full queues at bottlenecks, and so cannot meet the delay bounds. TFRC has smoother behaviour than TCP and is unreliable, but does not focus on minimizing delay, and has not seen wide deployment for a range of reasons. There are also proprietary mechanisms, that are by definition not interoperable. None of these are suitable. What we need from a future working group is a well-defined problem statement, one (or more) fully specified mechanisms for solving the congestion problem for interactive real-time applications, and metrics against which the success of that mechanism can be evaluated. Context: IAB/IRTF Congestion Control Workshop Slides: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-6.pdf Michael Welzl summarised the outcomes of the workshop on congestion control for interactive real-time applications that was held on 28 July 2012 in Vancouver. The workshop asked 1) if, absent changes to the network, we can develop a useful congestion control algorithm for interactive media; 2) if there is work in the area of measurements that we can use to create incentives to make updates to the network happen; and 3) if it is useful to develop a congestion control mechanism that assumes the problem is in the end host only, where there is idle capacity in the network. The consensus of the workshop participants was to answer yes to all these questions, but to note a wide range of normal delay variation in non-congested networks, which will significantly complicate the problem due to the delay bounds of interactive applications. The workshop participants noted that there are both short- and long-term paths to the solution. In the long-term, we should consider ECN, active queue management, and ways to segregate non-delay sensitive TCP traffic from interactive traffic. In the short term, there is potential to avoid self-inflicted queuing and ensure that e.g. browsers sending interactive flows don't cause excessive congestion and delay. Properties and limitations of the media codecs and feedback channel were noted, as was the trade-off between loss- and delay-based algorithms. Context: Buffer Bloat and AQM Slides: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-4.pdf Jim Gettys summarised issues relating to buffer bloat and active queue management (AQM) in the network. Numerous middleboxes, especially home gateway devices, and hosts have excess buffering. This can lead to large standing queues in the presence of TCP traffic, since TCP tries to fill the pipe, but doesn't try to minimise delay. This is problematic for interactive media flows that do care about delay. There are numerous pieces to the solution including reducing buffering in the network, deploying active queue management (where the new CoDel algorithm has promise), and developing new congestion control algorithms. None are likely to solve the problem in the short term, so RMCAT will need to cope with over-buffered networks when designing a solution. Context: Competing Traffic Slides: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-3.pdf Matt Mathis outlined the problems with interactive media flows competing with TCP traffic ("TCP Friendly is an oxymoron"). The fundamental problem is that TCP requires queues for correct operation, but interactive media flows cannot tolerate queueing. Modern TCP stacks are sufficiently well tuned that they will cause queuing on any network path, if they don't run out of data to send first. Matt believes the solution is a combination of traffic segregation, coupled with metrics to expose the problem. For interactive media congestion control, he recommended the group assume a (mostly) empty queue, and design the congestion control to avoid causing self-inflicted queuing delay and to provide "fair" sharing between media flows. Queuing delay is unavoidable in the presence of TCP cross-traffic, and a circuit breaker is needed to avoid serious congestion, but he suggested to avoid over-think interactions in failure cases: "protecting TCP is unnecessary, it will not return the favour". Outline Proposals for Potential Solutions Slides: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-2.pdf and http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-0.pdf Harald Alvestrand and Piers O'Hanlon presented candidate congestion control algorithms for interactive media applications. The proposal from Harald is a delay-based algorithm, based on analysis of filtered packet inter-arrival times; Piers suggested a variant of the TFRC algorithm that also includes a delay-based component. Neither algorithm was discussed in detail. Proposed Charter and Discussion Slides: http://www.ietf.org/proceedings/84/slides/slides-84-rmcat-1.pdf Draft charter: http://rtp-congestion.alvestrand.com/bof-planning-page/wg-charter---input-t… The chairs outlined the proposed charter and invited discussion. The following points were raised: - Matt Mathis suggested that a missing item on the charter is defining a clear metric that can be used to report congestion-related problems to the users of interactive media applications. - Magnus Westerlund asked if congestion control for calls using a mixer or other application-layer middlebox should be in scope for the group. It is possible to run a separate control loop on each side of the middlebox, but this can require media transcoding for rate adaptation if the two sides of the call achieve different bandwidth allocations. Passing congestion signals through the middlebox can allow end-to-end congestion control, avoiding transcoding, so the group should possibly consider coupled congestion control for this scenario. Cullen Jennings disagreed, wanting to limit the scope to point-to-point flows only and to remove anything to do with middleboxes. - Stephan Wenger suggested that the discussions have been behind the state of the art in joint source-channel coding. The group should consider that not all packets are equal in importance when designing congestion control algorithms. - Toerless Eckert suggested that the group may be too constrained by not being able to change TCP. - Eric Rescorla noted that the pace of browser development is fast, and would allow us to rapidly roll out new versions of congestion control provided it is scoped to running in a single application-level process. This suggests that trying to change operating system or network layer components should be outside the scope. - Harald Alvestrand and Spencer Dawkins agreed to keep the scope small, and suggested that the Transport Area could consider the wider issues, possibly creating other working groups if necessary. Limiting the scope of a possible RMCAT working group should not limit the wider discussion of the issues. - Randell Jesup wanted clarification that AQM is out of scope. The chairs agreed that defining AQM would be out of scope for RMCAT, but the group might decide to develop proposals that could use AQM if available. - Van Jacobson commented that the problem to be tackled is difficult. He recalled some of the history of developing TCP congestion control, and suggested that solving the self-interference problem for interactive media flows would be a sufficient challenge. Van recommended that the group consider impact on TCP as a second-order problem. - Jonathan Lennox, Spencer Dawkins, and others wondered why the charter proposed initial publication of the algorithms as experimental RFCs. The process is unusual, and it is not clear how deploying the algorithms in browsers with hundreds of millions of users can be classed as an experiment. Ted Hardie suggested that an important point is how easily and quickly the algorithm can be updated. - On a related note, Lars Eggert noted that defining evaluation criteria is important: what denotes success for the group? Lars also suggested that we need to be clearer on how we evaluate candidate algorithms, noting that we should have experiments that can be replicated, and competing proposals evaluated against the same criteria to ensure fairness and clarity in the evaluation. Toerless Eckert echoed these statements. - Harald Alvestrand suggested that we need to identify how multiple flows work, and how flows can be grouped together. To what extent should congestion control of aggregates of independent flows sharing a 5-tuple be in scope? Michael Welzl suggested that defined APIs may be a part of this. - Bob Briscoe cautioned the group that congestion control is a difficult problem, and suggested that we may want to develop a framework, rather than a single algorithm. - ??? suggested that a requirements document is a missing deliverable in the charter. He also noted that media congestion control is broader than RTCWEB, and suggested that the group should try to avoid limiting the applicability of the algorithms developed to just RTCWEB. The chairs wrapped-up the discussion by asking three questions: - Do you think that the problem is clear, well‐scoped, solvable, and worth solving? There was a hum in favour. - Do you support forming a WG with the charter outlined? There was a strong hum in favour. - Would you be willing to work on one or more of the drafts outlined? There was a significant constituency of people willing to work on the drafts. The charter will be updated based on the discussion and circulated on the mailing list for review. The chairs and the area directors will then work to form a working group. - + -

2 1

Feedback mechanisms
by Randell Jesup 22 Aug '12

22 Aug '12

So, there are a few possible feedback mechanisms (regardless of the exact algorithm): 1) TMMBR Has issues in that it's SSRC-specific Requires most of the algorithm to run in the receiver Travels over RTCP and is subject to AVPF rules, otherwise can send whenever needed Pro: Already exists, has some chance of being useful in interop situations (iffy) Con: In extreme congestion, can fail to be delivered. If congestion information is merged between multiple streams between endpoints, it's confusing what should be sent for a specific SSRC - requires the receiver to make decisions about inter-stream tradeoffs without knowing the parameters, or requires revising the TMMBR spec. 2) REMB Multiple SSRCs (good) Requires most of the algorithm to run in the receiver Travels over RTCP and is subject to AVPF rules, otherwise can send whenever needed Pro: Eases merging congestion information for streams Lower "extra" packet rate than explicit ack Can be suppressed when nothing interesting is happening - Lower bandwidth usage Con: If RTCP fraction is too low, can be blocked (so don't make it too low) In extreme congestion, can fail to be delivered. 3) Explicit RTCP C-ACK packets (Congestion-ACK) 1 packet per incoming packet (or short queuing time before sending to cut packet rate) Algorithm runs mostly in the sender Travels over RTCP and is subject to AVPF rules Pros: Sender can trigger on failure to receive C-ACKs - though we don't know if there's congestion in the sending direction, just in the feedback direction Cons: Extra bandwidth and packet traffic - increases congestion and uses queue slots If RTCP fraction is too low, can be blocked (and this uses a lot more than 1 or 2) I'm going to propose a fourth mechanism: 4) CHEX (Congestion Header EXtension) - ok, come up with a better name! Multiple SSRCs - multiple 'acks' in the extension Allows most of the algorithm to run in the sender Piggybacks in header extensions, can only send with an RTP packet (i.e. may be delayed) Pros: Extends existing support for actual send time header extensions (XXXX) Sender can trigger on failure to receive - though we don't know if there's congestion in the sending direction, just in the feedback direction Minimal additional bandwidth compared to C-ACK (3) Cons: Anything that strips header extensions causes failover to basic Requires waiting for an outgoing packet - fallback to sending via RTCP if we need to send "now" or if we've waited too long for a media packet (or anticipate waiting too long). Only one header extension per packet may be a small issue. Cuts max payload some (not a lot), but that may limit the number of updates in a single packet. Noticeably more bandwidth than REMB (2) Basically, it would be a combination of the actual send time (like XXXX), and reception data (equivalent to TCP ACKs, but including the time received or the inter-packet delta difference from the send time stamp (i.e. the input to the Kalman filter). I'm not saying this is my preference (I currently believe it makes more sense to run at least the Kalman filter in the receiver, and probably omit some , but it makes sense to explore the tradeoffs between sender and receiver running the algorithm. If we feel we want to use explicit acknowledgment or seriously consider it, we'll need to talk more about this and the tradeoffs and make this more fleshed-out. -- Randell Jesup randell-ietf(a)jesup.org

9 33

Re: [R-C] Charter to be shipped
by Bob Briscoe 15 Aug '12

15 Aug '12

Michael, I'm also v happy with it. Bob At 18:40 15/08/2012, Matt Mathis wrote: >It looks really good! Thanks for figuring out what I meant... > >I believe the charter accurately describes the largest solvable >problem with just the right edges. Furthermore, it properly >identifies boundaries to adjacent problem spaces, with just the right >amount of fuzziness. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > > >On Wed, Aug 15, 2012 at 7:01 AM, Wesley Eddy <wes(a)mti-systems.com> wrote: > > On 8/15/2012 9:01 AM, Michael Welzl wrote: > >> Hi Wes, > >> > >> Here's our charter, in a version that is ready for IESG review. Note > >> that there was also some discussion about the name - other suggestions > >> were "IMCC - Interactive Media Congestion Control" and "IRCC - > >> Interactive RTP Congestion Control". I think that the discussion wasn't > >> intense enough to indicate that people really care a lot about the name, > >> though, and so I suggest to leave it as it is for now, just for > simplicity. > >> > >> (someone told me that the IESG in fact decides the name, when the time > >> comes?) > >> > >> Is "shipping to the IESG" accomplished by sending you this email? :-) > >> > > > > > > ACK. This looks good to me, and I'll have it on the next > > available IESG telechat to try and approve it for external > > review. > > > > Regarding the name ... we can note the other options that > > have been suggested during the IESG discussion, but I don't > > think we will select something that the community doing the > > work doesn't identify with. I agree with you that at this > > point there doesn't seem to be a huge amount of push in any > > clear direction for a new name. We know the keys that need > > to remain are RTP and congestion, and I think we agree pretty > > well on the scope of work, so IMHO playing with other words > > to sandwich around "RTP" and "congestion" isn't going to > > change much else. > > > > Thank you to everyone for the feedback and especially to > > Michael for wrangling it all together so actively! > > > > -- > > Wes Eddy > > MTI Systems > > _______________________________________________ > > Rtp-congestion mailing list > > Rtp-congestion(a)alvestrand.no > > http://www.alvestrand.no/mailman/listinfo/rtp-congestion >_______________________________________________ >Rtp-congestion mailing list >Rtp-congestion(a)alvestrand.no >http://www.alvestrand.no/mailman/listinfo/rtp-congestion ________________________________________________________________ Bob Briscoe, BT Innovate & Design

2 1

Charter to be shipped
by Michael Welzl 15 Aug '12

15 Aug '12

Hi Wes, Here's our charter, in a version that is ready for IESG review. Note that there was also some discussion about the name - other suggestions were "IMCC - Interactive Media Congestion Control" and "IRCC - Interactive RTP Congestion Control". I think that the discussion wasn't intense enough to indicate that people really care a lot about the name, though, and so I suggest to leave it as it is for now, just for simplicity. (someone told me that the IESG in fact decides the name, when the time comes?) Is "shipping to the IESG" accomplished by sending you this email? :-) 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(a)mti-systems.com> Transport Area Advisor: Wesley Eddy <wes(a)mti-systems.com> Mailing Lists: TBD (until establishment, we use rtp-congestion(a)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. A 'reasonable share' means that no flow has a significantly negative impact [RFC5033] on other flows and at minimum that no flow starves. • 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), RFC 2914 (congestion control principles), and RFC5033 (Specifying New Congestion Control Algorithms). The following topics are out of scope of this working group, on the assumption that work on them will proceed elsewhere: • 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)

3 2

Re: [R-C] Charter update
by Bob Briscoe 15 Aug '12

15 Aug '12

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(a)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(a)mti-systems.com> > > > > Transport Area Advisor: > > Wesley Eddy <<mailto:wes@mti-systems.com>wes(a)mti-systems.com> > > > > Mailing Lists: TBD (until establishment, we > use <mailto:rtp-congestion@alvestrand.no>rtp-congestion(a)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(a)alvestrand.no > > http://www.alvestrand.no/mailman/listinfo/rtp-congestion > >_______________________________________________ >Rtp-congestion mailing list ><mailto:Rtp-congestion@alvestrand.no>Rtp-congestion(a)alvestrand.no >http://www.alvestrand.no/mailman/listinfo/rtp-congestion > > >_______________________________________________ >Rtp-congestion mailing list >Rtp-congestion(a)alvestrand.no >http://www.alvestrand.no/mailman/listinfo/rtp-congestion ________________________________________________________________ Bob Briscoe, BT Innovate & Design

4 4

Fairness of RRTCC and TCP
by Varun Singh 14 Aug '12

14 Aug '12

Hi, Following up on the discussion of fairness between interactive real-time flows and TCP. I've implemented the RRTCC in NS-2 and attached within are the preliminary results. The scenarios that we simulated are: 1. RRTCC flow shares a bottleneck with short TCP. 2. two RRTCC flows share a bottleneck with with short TCP flows. The short TCP flows are modelled as on/off flows. The size of the data is obtained from a uniform distribution between 100KB and 1.5MB, and the idle periods are obtained from an exponential distribution with the mean as 10. The results are available as a short presentation at: http://bit.ly/rrtcc-tcp I would appreciate any comments and/or feedback. Cheers, Varun

5 6

Charter update
by Michael Welzl 13 Aug '12

13 Aug '12

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(a)mti-systems.com> Transport Area Advisor: Wesley Eddy <wes(a)mti-systems.com> Mailing Lists: TBD (until establishment, we use rtp-congestion(a)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)

2 2

RRTCC issues: loss, decrease rate
by Randell Jesup 08 Aug '12

08 Aug '12

This is the first of a few messages on the details of RRTCC I expect to post, based on analysis (not testing) of the algorithm, and my 8-year experience with an algorithm I designed which had very similar theory and underpinnings. This has been used (mostly in residential settings) in hundreds of thousands of devices mostly for peer-to-peer calls. Please feel free to critique! I make no assertions that this analysis is guaranteed correct (and in fact I'm sure it will be pointed out several ways in which it's wrong), but I think it will be a helpful starting point. I also realize there are some simplifications assumed below; I've tried to note them. The first focus is on loss. I'll primarily focus on the impact of tail-drop policies for now. Loss affects a stream in a number of ways: 1) Directly - loss of a packet in the RTP stream 2) Indirectly - loss of a packet for another traffic stream, for this or another destination 3) "Random" loss (non-congestion) Note: Not all channels experience "random" loss, though some "random" loss is momentary congestion of a core router or some type of AQM. Since in this case we're focusing on tail-drop routers (at the bottleneck), we'll assume this category can be modeled as non-congestive random losses. Obviously the more inputs and knowledge of the streams (especially between the two endpoints, via any port, not just the 5-tuple) the better the model can perform. A confounding issue to be discussed later is how differential packet marking affects congestion and bandwidth models. Since RRTCC works from inter-packet-delays (when compared to sending times, either from RTP timestamps of header extensions with closer-to-the-stack sending times), let's look at how these types of loss affect the signals seen by the receiver and the Kalman filter. 1) Direct loss ------------------- In this case, we'll see the loss directly. This is common in access-link self-congestion, where our stream(s) are the only significant user of bandwidth or if there are a very few users, and we've exceeded the capacity of the physical link. The inter-packet delay was likely increasing steadily leading up to the loss. For example, if the other side is sending at 220Kbps at 20ms intervals with an access bottleneck (upstream at their side, or downstream at our side) of 200Kbps, and there's no other traffic on the link, then the packets would have been coming in about 22ms apart instead of 20ms. Let's assume a very short queue depth (no bufferbloat!) of 2 packets (40ms), and look what happens. For whatever reason (packet loss, noisy signal to the filter, long RTT, cross-traffic that just went away, etc) let's assume that the system didn't react before the loss happened. When the packet is lost, there must have been 2 packets in the buffer. The receiver will see packet N, N+1, and then N+3 and N+4. N will have been delayed around 38ms, N+1 around 40ms, N+3 about 22ms, and N+4 around 24ms Pictorially this would look like a sawtooth in the delay profile. If you naively input these into the filter, it will start to move down away from a 10% slope, and might indicate a flat queue-depth profile or perhaps even negative (draining) for a short time, when in fact we've been over-bandwidth the entire time. This would depend on the exact filter type and usage, but this certainly violates some of the assumptions about error in a Kalman filter (for example, Gaussian distribution). At least in this case, a Kalman filter might not be the optimum choice. * Possible modifications: a) drop samples where there's a loss, since losses frequently perturb the delta of the next packet This will reduce the 'noise' in the inputs to the filter, especially in simple cases like above. b) increase the "uncertainty" of the next packet dramatically in the input to the filter This is an attempt to get the Kalman filter to weight the packet much lower, but not ignore it entirely. I don't see this as very useful in practice. c) look at whether there was a significant drop in delay following a loss, and use that as a separate indicator that we're over-bandwidth In my algorithm, I termed these "fishy" losses - they implied a queue suddenly shortened. Too many (more than 1) of these in a short period of time meant I would decrease sending bandwidth by a significant extra amount, since the implication is not just delay, but a full queue, which I really want to get out of fast. This is a form of modification 'c'. If we're not the only stream on the bottleneck, and we just got "unlucky" and had our packet get dropped, similar issues may occur, but the reduction in delay of the next packet may be less or much less, since we're typically metering in our packets at a frame rate. With enough other traffic, the delay of the next packet will be roughly flat (or 40ms in the case above). So this modification (c) is of most use in detecting the bandwidth/queue limit of a relatively idle link, typically an access (especially upstream) link. It therefore may want to be combined with other mechanisms. If we see a direct loss without a significant reduction in delay, we need to assume it's either a congested link (not a physical layer limit we're hitting on an idle link) or it's a "random" loss. Losses on a congested link also indicate a full queue, and so even though the delay stopped increasing (or stayed on=average stable after you've hit the max and started dropped), you still want to decrease sending rate. If it's a "random" loss (and not AQM), this causes a minor under-utilization, but for a truly congested link or if AQM is causing "random" drops, it's a signal we should reduce to try to start the queue draining. To avoid over-reaction and 'hunting', it may be good to use some type of threshold, perhaps averaged or filtered. If the loss rate reached ~5%, I'd make a mild cut in sending rate on top of any filter-suggested cuts, and if it reached ~10% I'd make a strong cut. (to be continued in another post) -- Randell Jesup randell-ietf(a)jesup.org

4 9

Charter
by Michael Welzl 08 Aug '12

08 Aug '12

Hi all, There were two minimal changes to the charter, which is at: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/… It now explicitly says that the following are out of scope: * Active queue management; modifications to TCP of any kind; and * Multicast congestion control (common control of multiple unicast flows is in scope). Other than that, the charter hasn't changed since the last version that was sent around in May. Cheers, Michael

9 19