- Rtp-congestion - alvestrand.no

congestion control in WebRTC
by manphis chen 13 Jun '13

13 Jun '13

Dear all, Recently I am investigating the feedback mechanism for rate control in webrtc. Does the receiver use RTCP to inform the sender about the information such as available bandwidth, lossy ratio, .., etc.? I saw the packet format by wireshark, and saw that there is extra information appended on the SR (Sender Report) of RTCP, but wireshark cannot recognize it. Does anyone have the same experience? Or is there any document describing the details of the feedback mechanism or the format of the feedback packets in webrtc? Many thanks BRs manphis

2 1

Fwd: WG Review: RTP Media Congestion Avoidance Techniques (rmcat)
by Wesley Eddy 24 Sep '12

24 Sep '12

As you can see, the RMCAT charter is now out for review, and scheduled for approval on the next IESG telechat. The charter below is pretty much just the previous one that Michael sent to this list, with tweaks that I made in order to satisfy some of the blocking and non-blocking comments that it attracted during the IESG internal review. It does seem to be missing the milestones at the moment; which should be no real issue as they mimic the final set of deliverables bullets largely. However, I think this is an issue with our new chartering tool that RMCAT is making the first real use of, and I'll work to resolve it with the tool. -------- Original Message -------- Subject: WG Review: RTP Media Congestion Avoidance Techniques (rmcat) Date: Wed, 05 Sep 2012 14:46:52 -0700 From: The IESG <iesg-secretary(a)ietf.org> To: IETF-Announce <ietf-announce(a)ietf.org> A new IETF working group has been proposed in the Transport Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2012-09-12. RTP Media Congestion Avoidance Techniques (rmcat) ------------------------------------------------ Current Status: Proposed Working Group Assigned Area Director: Wesley Eddy <wes(a)mti-systems.com> Charter of Working Group: Description of Working Group Today's Internet traffic includes interactive real-time media, which is often carried via sets of 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. This must be completed prior to finishing any Experimental algorithm specifications. - Identify interactions between applications and RTP flows to enable conveying helpful cross-layer information such as per-packet priorities, flow elasticity, etc. This information might be used to populate an API, but the WG will not define a specific API itself. - Determine if extensions to RTP/RTCP are needed for carrying congestion control feedback, using DCCP as a model. If so, provide the requirements for such extensions to the AVTCORE working group for standardization there. - 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 shared bottlenecks between groups of flows, and means to flexibly allocate their rates within the aggregate hitting the shared bottleneck. - Define evaluation criteria for proposed congestion control mechanisms, and publish these as an Informational RFC. This must be completed prior to finishing any Proposed Standard algorithm specifications. - 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. This must be completed prior to finishing any Proposed Standard algorithm specifications. - 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. - For each of the Experimental algorithms that have not been selected for the Standards Track, the working group will review the algorithm and determine whether the RFC should be moved to Historic status via a document that briefly describes the issues encountered. This step is particularly important for algorithms with significant flaws, such as ones that turn out to be harmful to flows using or competing with them. 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 algorithms or modifications to TCP of any kind - 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 coordinate 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 as an Informational RFC - Evaluation criteria for congestion control algorithms for interactive real time media as an Informational RFC - RTCP extensions for use with congestion control algorithms as a Proposed Standard RFC - Interactions between applications and RTP flows as an Informational RFC - Identifying and controlling groups of flows as a Proposed Standard RFC - Techniques to detect, instrument or diagnose failing to meet RT schedules as either an Informational RFC or on the Standards Track if needed for interoperability or other aspects that would justify it. - Candidate congestion control algorithm for interactive real time media as Experimental RFCs (likely more than one) - Experimentation and evaluation results for candidate congestion control algorithms as an Informational RFC - One or more recommended congestion control algorithms for interactive real time media as Proposed Standard RFCs Milestones:

6 10

Sender- vs. receiver-based, yet again...
by Michael Welzl 24 Sep '12

24 Sep '12

Hi, Sorry for bringing this up yet again - but my thoughts just keep returning to the question of sender-vs.-receiver based congestion control, because it's a seemingly simple problem for which we should be able to agree on a clear answer?! As most of you probably know by now, I'm critical of a receiver-based approach as in RRTCC. (In fact, as I will explain further below, I argue against a *combined* sender+receiver approach). Here is a plus/minus list as I see it: PLUS no. 1: it helps to reduce the amount of feedback. That's really the ONLY benefit. MINUS no. 1: it requires the same mechanism on the sender and receiver side, which means that, if RTP becomes a "framework" for congestion control mechanisms, we must signal which mechanism is used to the other side. In contrast, we don't have to do this with TCP's (implemented but not standardized) pluggable congestion control. This is, to me, the biggest problem, as it requires code updates to happen on both sides for a new mechanism to be deployed. MINUS no. 2: it could make combined congestion control between multiple flows via the FSE more complicated. Anyway it seems we'll need an FSE on the sender AND receiver side, but with receiver-based congestion control, we'll face the question: for two flows between the same two hosts, sharing the same bottleneck, should the receivers exchange information and coordinate their feedback, or should the senders exchange information and coordinate their behavior? => when congestion control mechanisms are split across sender and receiver, the right answer to this question becomes a per-mechanism decision. Please amend this list if I'm missing something. Regarding the one PLUS above, here's a critical look at the benefits of reducing feedback **via receiver-side congestion control**: - less feedback means a greater chance for the feedback to be dropped, which translates into a greater chance for undesirable sender behavior - we deal with interactive traffic, in which case a lot of the feedback could hopefully be piggybacked onto payload packets - in some cases there will be other parallel flows (e.g. the data channel in rtcweb) that already give us all the feedback that we need, this is another chance for feedback reduction - receiver-side-congestion-control-based feedback reduction as in RRTCC means to reduce the feedback whenever feedback isn't urgent for the sender. I'd argue that, in fact, we should reduce feedback only when the channel carrying it (the backwards channel) is congested, and that is a generic function, not bound to the sender-side congestion control behavior. So how urgent is it to reduce feedback, anyway? Some time ago, Bill Ver Steeg wrote: *** 1- The upstream/return traffic is (generally) assumed to be a precious resource by the RTP community. This is partially due to multicast considerations (which we can mostly ignore here) and partially due to asynchronous networks. Note that the CableTV community has found it necessary to play games with TCP acks in Cable Modems because of upstream bandwidth limitations, even for unicast TCP traffic. This is an ugly hack that I will not defend here, but it is indicative of the problem space. The net-net is that we have to be somewhat conservative in our sending of acks, or we will end up in similar trouble. *** As he states, multicast is out of scope. Plus, I think we should care more about technical reasons than what the RTP community considers to be a precious resource. As for the CableTV example, one can always find examples where people started doing useless things :-) but consider the following: many parallel TCP connections, each sending lots of feedback, work okay for maaaany end users that 1) surf the Internet or (bringing it closer to rtcweb thinking) 2) use P2P applications. And TCP doesn't even do any form of congestion control on ACKs (an RFC exists but noone uses it (so far)). I'm not saying ACKs never cause problems. I'm saying it's probably rare that they do, and reducing their number WHEN they cause trouble is good enough (and, I would argue, a better decision). Let's take a step back and summarize the situation: 1) congestion-control-based-feedback-reduction has at least one significant MINUS (no. 1), probably two 2) the benefits of doing it seem minimal 3) not being based on congestion along the backwards path, it misses the point somewhat... As a result of the above, I would suggest to move all congestion control functionality to the sender side and keep the receiver side dumb, as in TCP, but amended with some generic (i.e. not mechanism-specific) feedback-reduction functions (ACK congestion control; piggybacking; omitting feedback when it is known (e.g. via a signal from the sender) that we get feedback from another flow). Alternatively, we could still remove the MINUS no. 1 above by agreeing on a generic sender behavior. IIRC, in RRTCC, the sender is rather simple - it follows the rate dictated by the receiver and has a timeout behavior. If all congestion control mechanisms are installed on the receiver side only, with the same agreed generic sender behavior for everyone, we can also have pluggable congestion control without a need for signalling. It's just the idea of multiple proposals for congestion control involving newly described sender AND receiver behavior that strikes me as bad design. Thoughts? Cheers, Michael

5 4

Welcome to RMCAT
by Eggert, Lars 23 Sep '12

23 Sep '12

Welcome to RMCAT! Your chairs will be Mirja and myself. A few administrative bits: * Please start using the rmcat(a)ietf.org WG list for discussions. Harald's list can probably be retired at this point. * Familiarize yourself with the final version of the charter (https://datatracker.ietf.org/wg/rmcat/charter/) and esp. our first few milestones. Begin discussions on this list. * If you are submitting IDs targeted at the WG, please name them draft-yourname-rmcat-*, so the tools will pick them up and we can track them easily. (Resubmit revisions of existing IDs under the same naming scheme. You can point out in the text which earlier ID they replace.) * Familiarize yourself with the IETF Note Well (http://www.ietf.org/about/note-well.html) Make sure you comply with the relevant rules, especially with regards to timely IPR disclosure. * Remember that the WG works continuously on the list year-round, and face-to-face sessions are for those high-importance issues that need the additional bandwidth available in a live setting to be resolved. This means that we'll likely cherry-pick the topics that get face-time at WG sessions - not everything being worked on on the list will need or get session time. On the flip side, it's highly unlikely that anything will get session time that isn't being discussed on the list. So: work on the list, it's the primary forum. Begin now :-) * The ADs asked for a slot in Atlanta. We don't know yet when or how long it is. Mirja and me will begin putting a charter together based on the WG list discussions. Lars

1 0

moving list to ietf.org
by Wesley Eddy 13 Sep '12

13 Sep '12

As part of becoming a working group, I'm going to request an ietf.org hosted mailing list for this group; rmcat(a)ietf.org (does not exist yet; do not use until notified). We plan to transition the membership of this list over to the ietf.org one at the moment it's created, without you having to do anything explicit. This note is just to let you know not to panic when that happens, and that once it's ready, that will be the list to use for communication related to the working group. -- Wes Eddy MTI Systems

1 0

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