May 2012 - Rtp-congestion

Fwd: Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada
by Harald Alvestrand 16 Jun '12

16 Jun '12

Here's the CFP. Yes, the date is fixed now. -------- Original Message -------- Subject: Call for Papers: IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication, July 28, 2012 Vancouver, Canada Date: Wed, 23 May 2012 10:47:49 -0700 From: IAB Chair <iab-chair(a)iab.org> Reply-To: iab(a)iab.org Organization: Internet Architecture Board To: <ietf-announce(a)ietf.org> CC: iab(a)iab.org IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication July 28, 2012 Vancouver, Canada The IAB and IRTF will hold a workshop on Congestion Control for Interactive Real-Time Communication" in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html <http://www.ietf.org/meeting/83/index.html>). Participation at the workshop is free of charge. There is no requirement to either register with or attend the IETF-84 meeting that follows the workshop. The workshop organizers would like to foster a discussion on: 1. What are appropriate congestion signals to use for interactive media and data? 2. What existing congestion control algorithms are appropriate for interactive media and data? What properties would be desirable in new congestion control algorithms? 3. Measurement and/or simulations of new congestion signals (e.g., delay-based) and their interaction with existing congestion control mechanisms. 4. What are good available techniques for adjusting sending rates for interactive media and data? What are the limits of those techniques? What properties would be desirable in new techniques? 5. What application-specific considerations have to be taken into account? 6. How can we ensure that real-time communications are well-behaved with respect to other Internet applications while still providing good quality? 7. What should the IETF and/or IRTF do? The organizers seek position papers on any or all of these topics, as well as other topics related to congestion control for interactive realtime media. Every prospective workshop participant must submit a position paper containing a name and an email address. Authors of accepted papers will be invited to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Accepted position papers will be published. Additional details about the meeting venue will be provided to authors of accepted papers. Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Additional Details Additional details on the workshop as well as the submission process is available at http://www.iab.org/cc-workshop/ Contact To sponsors: If you are interested to help us working towards better interactive media congestion control mechanisms on the Internet (such as by making a contribution towards catering costs and room rental), please contact us! In case of questions please send email to mary.ietf.barnes at gmail.com.

2 1

BOF request: RMCAT - RTP Media Congestion Avoidance Techniques
by Harald Alvestrand 30 May '12

30 May '12

The proposers would like to request a 2-hour slot for a BOF in Vancouver on the subject of RTP Congestion Control. The proposed acronym is RMCAT - RTP Media Congestion Avoidance Techniques. Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC and any video codec BOF, TCPM and relevant transport WGs Expected attendance: 60 persons. BOF agenda ---------------- Chairs: Randell Jesup and Harald Alvestrand Area: TSV Area directors: Wesley Eddy, Martin Stiemerling The following is a draft agenda, subject to modifications. Names are tentative. Intro (Chairs - 5 min) Problem statement (Harald/Randell) - 25 min Covers existing protocols and their effect on low-delay streams. Addresses limiting the scope of this effort to a "probably solvable problem". Includes a report from the IAB workshop on the same topic on Saturday Context setting: BufferBloat & AQM (10 min) (Gettys) RRTCC draft (10 min) (Stefan) Describes existing proposal, Covering areas for improvement Alternative Solution (10 min) (?) Modified Cx-TCP?? Modified TFRC??? Charter presentation, discussion (50 min) Next steps/conclusion (10 min) Total timeslot: 2 hours. WG charter (proposed) ------------------------------- RTP Media Congestion Avoidance Techniques (rmcat) Status: Proposed Working Group Last Updated: 2012-05-18 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. The set of requirements for such an algorithm includes, but is not limited to: * Low delay for the case where there is no competing traffic using other algorithms * Fair share of bandwidth when there is competing traffic using other algorithms * 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 * Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines CCIDs, and if so, document such extensions as standards-track RFCs. * 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 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. * Modifications to TCP of any kind. 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 * Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC * RTCP extensions for use with congestion control algorithms - Standards-track 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 draft of evaluation crieria NN NNNB: Adopt first congestion control candidate as WG draft NN NNNC: (A + 4 months) Submit evaluation criteria to IESG as Informational NN NNND: (C + 1 month) Submit first congestion control candidate to IESG for Experimental publicaiton NN NNNE: (D + 3 months) First draft of evaluation results NN NNNF: (=E) First draft of standars-track congestion control NN NNNG: (F + 6 months) Submit congestion control to IESG for Proposed Standard (time from chartering to end of charter is 15 months)

1 1

Re: [R-C] Effect of ConEx on RMCAT
by Ingemar Johansson S 29 May '12

29 May '12

Hi CC the ConEx list as I believe a cross-post is motivated. There has been a few experiments with ConEx, I know Mirja has done some experimentation before, also there was presentation at the last IETF http://tools.ietf.org/agenda/83/slides/slides-83-conex-5.pdf the re-feedback of the ECN marks was however not properly implemented if I remember it right but the results was anyway interesting. As mentioned in an earier email (from me), I don't believe that ConEx should be squeezed into the charter now. But what is important is that it should be recongnized that there are other mechanisms other than the endpoint rate adaptation algorithms that benefit from a timely feedback of congestion information from the receiver back to the sender. /Ingemar > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 May 2012 09:24:31 -0500 > From: "Bill Ver Steeg (versteb)" <versteb(a)cisco.com> > To: "Zaheduzzaman Sarker" <zaheduzzaman.sarker(a)ericsson.com>, > <rtp-congestion(a)alvestrand.no> > Subject: Re: [R-C] Effect of ConEx on RMCAT > Message-ID: > <117602CF2B17DB4F9001427FA6D9053901D19BC6(a)XMB-RCD-312.cisco.com> > Content-Type: text/plain; charset="iso-8859-1" > > Does anybody have results from trials of ConEX? I have not > seen any. In the absence of such feedback, I am reluctant to > put it on the critical path. It seems like there may be > something good in ConEX, but it does add significant > complexity to the system > > bvs > > > -----Original Message----- > From: rtp-congestion-bounces(a)alvestrand.no > [mailto:rtp-congestion-bounces@alvestrand.no] On Behalf Of > Zaheduzzaman Sarker > Sent: Thursday, May 24, 2012 7:03 AM > To: rtp-congestion(a)alvestrand.no > Subject: [R-C] Effect of ConEx on RMCAT > > Hi, > > One topic that so far have not been discussed in this mailing > list is the ConEx and it's effect on congestion avoidance. > > ConEx Background: IETF ConEx WG is chartered here > https://datatracker.ietf.org/wg/conex/charter/. According to > that charter ConEX is working on congestion exposure > mechanism for IPv6 networks. Basically, the receiver of a > flow sends the congestion related information (packetloss, > ECN-CE markings) back to the sender then the sender of the > flow inserts IPv6 header extension to expose that information > to the operators. This is done to aid the congestion > management at the network. Typically as long as the flow does > not exceed a certain congestion volume the network does not > do any kind of traffic shaping on that flow. > > > The effects: > > + RTP media is not ConEx enabled: Bitrate may be throttled > in the network possibly based on some time of day policy or whatever. > > + RTP media is ConEx enabled but no feedback or congestion information > to the sender or congestion feedback is too slow : Audit > functions will find a mismatch between stated and actual > congestion and will start to drop packets. > > + RTP media is ConEx enabled and timely feedback of congestion info to > sender: Packets will pass through unaffected by the ConEx > policers as long as congestion volume quota is not exceeded. > > This means: > > * the operators can drop priority on non-ConEx flows hence a > ConEx enabled flow is treated differently. This will have > impact on the congestion avoidance techniques RMCAT will > produce as same algorithm may not work efficiently enough for > both ConEx enabled flow and non-ConEx enabled flow. > > * a ConEx enabled flow will need to send congestion related > information (perhaps more frequently than usual) i.e. packet > loss and ECN marking information along with simple rate request. > > * RTP media need to be congestion volume aware. > > I see a clear impact on design choice on how to handle these. > I think we should discuss the impact of ConEx here before the > BOF in Vancouver. > > -- > Zahed > > ============================================ > ANM ZAHEDUZZAMAN SARKER > > > Ericsson AB > Multimedia Technologies (MMT) > Ericsson Research > P.O. Box 920, SE-971 28, Lule?, Sweden > Phone +46 10 717 37 43 > Fax +46 920 996 21 > SMS/MMS +46 76 115 37 43 > zaheduzzaman.sarker(a)ericsson.com > www.ericsson.com > ============================================ > _______________________________________________ > 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 > > > End of Rtp-congestion Digest, Vol 8, Issue 10 > ********************************************* >

2 1

Interesting reference: "thin, fast" vs "thick, slow" data streams research project
by Harald Alvestrand 28 May '12

28 May '12

Those of you who read Norwegian may enjoy this: http://www.tu.no/it/2012/05/26/fjerner-forsinkelser-pa-nettet?utm_source=ne… <http://www.tu.no/it/2012/05/26/fjerner-forsinkelser-pa-nettet?utm_source=ne…> Perhaps Michael Welzl has a link in English that is more geared towards an audience that knows what they're talking about? Harald

3 2

Re: [R-C] Effect of ConEx on RMCAT
by Ingemar Johansson S 25 May '12

25 May '12

Hi My take is that one can in WebRTC (or in for that matter any other service that will use RMCAT) do feedback in many different ways. We limit ourselves to Video for simpicity. One can do receiver based rate adaptation and only feedback rate requests, or.. One can feedback actual congestion signals from the network (packet loss and ECN using e.g RTCP XR) back to the sender, where rate adapatation is done. It does not preclude the use of delay based rate adapation for the cases where the transmission path is buffer bloated. In the former case (rate requests back to sender) a ConEx enabled sender cannot insert any meaningful information into the IP headers. In the latter case (feedback of packet loss, ECN) it is possible, the question mark is then how often is feedback needed ? Questions are: + Should one bother with ConEx here ?. I would say that ConEx should be considered when feedback mechanisms are being discussed. Congestion management is a hot topic among operators and I would say that a mechanism that makes services expose the congestion that they cause/experience should improve the chances for them to be accepted without having the packets crippled in an unpredictable way, yes I know ConEx is experimental and may not fly but when one choose between feedback mechanisms one should consider the possibility that ConEx can fly. + Do I say that ConEx should be baked into RMCAT ? , probably too early for this but I say that if the appropriate feedback mechanisms are in place, then addition of ConEx is made easier later on. Of course one can dismiss ConEx because it is too premature but the risk is then that it will be necessary to change the RMCAT specification later on to contain the necessary elements to interoperate well with ConEx. IPv6 only: Yes its true but the reasons behind this in the ConEx WG charter are more the results of a lenghtly BoF and WG formation discussion than technical. Re-ECN is a proof of concept which use the precious bit 48 in the IPv4 header. So yes, I believe ConEx can be extended to IPv4 as well (if it is worth the effort) /Ingemar > Message: 4 > Date: Thu, 24 May 2012 08:48:05 -0400 > From: John Leslie <john(a)jlc.net> > To: Wesley Eddy <wes(a)mti-systems.com> > Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker(a)ericsson.com>, > "rtp-congestion(a)alvestrand.no" <rtp-congestion(a)alvestrand.no> > Subject: Re: [R-C] Effect of ConEx on RMCAT > Message-ID: <20120524124805.GI2661@verdi> > Content-Type: text/plain; charset=us-ascii > > Wesley Eddy <wes(a)mti-systems.com> wrote: > > On 5/24/2012 7:02 AM, Zaheduzzaman Sarker wrote: > > > >> Basically, the receiver of a flow sends the congestion related > >> information (packetloss, ECN-CE markings) back to the > sender then the > >> sender of the flow inserts IPv6 header extension to expose that > >> information to the operators. This is done to aid the congestion > >> management at the network. > > Yes. > > >> Typically as long as the flow does not exceed a certain congestion > >> volume the network does not do any kind of traffic shaping > on that flow. > > Um... maybe... > > >> + RTP media is not ConEx enabled: Bitrate may be throttled in the > >> network possibly based on some time of day policy or whatever. > > That's a remote possibility. > > >> + RTP media is ConEx enabled but no feedback or congestion > information > >> to the sender or congestion feedback is too slow : Audit > functions > >> will find a mismatch between stated and actual > congestion and will > >> start to drop packets. > > That's a premature conjecture. > > If you include the ConEx (IPv6) destination option, it is a license > for an audit function to do whatever it may see fit to do with such > packets. There are proposals on the ConEx list for what that may be, > but they're _only_ discussing what to experiment with in > audit functions. > > >> + RTP media is ConEx enabled and timely feedback of congestion info > >> to sender: Packets will pass through unaffected by the ConEx > >> policers as long as congestion volume quota is not exceeded. > > Even that is a premature conjecture. > > >> This means: > >> > >> * the operators can drop priority on non-ConEx flows hence a ConEx > >> enabled flow is treated differently. This will have impact on the > >> congestion avoidance techniques RMCAT will produce as > same algorithm > >> may not work efficiently enough for both ConEx enabled flow and > >> non-ConEx enabled flow. > > That's a premature conjecture. > > >> * a ConEx enabled flow will need to send congestion > related information > >> (perhaps more frequently than usual) i.e. packet loss > and ECN marking > >> information along with simple rate request. > > That's likely, if ConEx ever gets beyond Experimental status. > > >> * RTP media need to be congestion volume aware. > > That would be good, IMHO, but it's still premature. > > >> I see a clear impact on design choice on how to handle > these. I think > >> we should discuss the impact of ConEx here before the BOF > in Vancouver. > > I'd be happy to discuss how we might apply ConEx to RTP flows, but > I see no urgency for such a discussion. > > > I do *not* think it's necessary, and that it's a > distraction for this > > RTP group. > > I quite agree it's not necessary; but I don't entirely agree it's a > distraction... > > > CONEX is just an "experiment" at the moment; not something > > being baked into the core of the Internet. It's not something > > everyone else has to suddenly take into account as part of the > > network. Maybe someday. > > Yes, it's a "maybe someday" thing. > > BTW, I certainly intend no criticism of Zaheduzzaman: the > ConEx list > itself isn't clear about what policing policies might be tried. > > -- > John Leslie <john(a)jlc.net> > >

1 0

Effect of ConEx on RMCAT
by Zaheduzzaman Sarker 24 May '12

24 May '12

Hi, One topic that so far have not been discussed in this mailing list is the ConEx and it's effect on congestion avoidance. ConEx Background: IETF ConEx WG is chartered here https://datatracker.ietf.org/wg/conex/charter/. According to that charter ConEX is working on congestion exposure mechanism for IPv6 networks. Basically, the receiver of a flow sends the congestion related information (packetloss, ECN-CE markings) back to the sender then the sender of the flow inserts IPv6 header extension to expose that information to the operators. This is done to aid the congestion management at the network. Typically as long as the flow does not exceed a certain congestion volume the network does not do any kind of traffic shaping on that flow. The effects: + RTP media is not ConEx enabled: Bitrate may be throttled in the network possibly based on some time of day policy or whatever. + RTP media is ConEx enabled but no feedback or congestion information to the sender or congestion feedback is too slow : Audit functions will find a mismatch between stated and actual congestion and will start to drop packets. + RTP media is ConEx enabled and timely feedback of congestion info to sender: Packets will pass through unaffected by the ConEx policers as long as congestion volume quota is not exceeded. This means: * the operators can drop priority on non-ConEx flows hence a ConEx enabled flow is treated differently. This will have impact on the congestion avoidance techniques RMCAT will produce as same algorithm may not work efficiently enough for both ConEx enabled flow and non-ConEx enabled flow. * a ConEx enabled flow will need to send congestion related information (perhaps more frequently than usual) i.e. packet loss and ECN marking information along with simple rate request. * RTP media need to be congestion volume aware. I see a clear impact on design choice on how to handle these. I think we should discuss the impact of ConEx here before the BOF in Vancouver. -- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker(a)ericsson.com www.ericsson.com ============================================

5 6

Fwd: [AVTCORE] Protocol Action: 'Explicit Congestion Notification (ECN) for RTP over UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt)
by Harald Alvestrand 23 May '12

23 May '12

I assume that most people will be aware of this, but it never hurts to make sure. Harald -------- Original Message -------- Subject: [AVTCORE] Protocol Action: 'Explicit Congestion Notification (ECN) for RTP over UDP' to Proposed Standard (draft-ietf-avtcore-ecn-for-rtp-08.txt) Date: Wed, 16 May 2012 14:25:58 -0700 From: The IESG <iesg-secretary(a)ietf.org> To: IETF-Announce <ietf-announce(a)ietf.org> CC: avtcore chair <avtcore-chairs(a)tools.ietf.org>, avtcore mailing list <avt(a)ietf.org>, RFC Editor <rfc-editor(a)rfc-editor.org> The IESG has approved the following document: - 'Explicit Congestion Notification (ECN) for RTP over UDP' (draft-ietf-avtcore-ecn-for-rtp-08.txt) as Proposed Standard This document is the product of the Audio/Video Transport Core Maintenance Working Group. The IESG contact persons are Robert Sparks and Gonzalo Camarillo. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtcore-ecn-for-rtp/ Technical Summary This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined. Working Group Summary There were no controversy about the proposed solution and there was consensus on all discussion points Document Quality There is at least one research implementation and there is fairly strong commercial interest. There was interest in this work by other standard bodies like 3GPP and ITU-T SG16 who need to reference it. The SDP attributes and ICE options defined in the document were sent to review in MMUSIC on September 30, 2011 Personnel Roni Even is the document shepherd. Robert Sparks is the responsible area director. _______________________________________________ Audio/Video Transport Core Maintenance avt(a)ietf.org https://www.ietf.org/mailman/listinfo/avt

1 0

Hold the date: Trying to get a workshop on congestion control for real time interactive media together....
by Harald Alvestrand 19 May '12

19 May '12

FYI ... .the IAB is trying to get together a workshop (of the typical IAB format; people get invited if they contribute ideas beforehand) together before the Vancouver IETF, covering the same subject area as the RTP congestion work. This would have a goal, among other things, of getting people to think about the subject matter for our BOF/WG, and get people better informed (and interested!) before the BOF. The likely date is Saturday before the IETF (July 28), but this is not settled yet, so don't book tickets specifically for this until you hear the official announcement.... Harald

1 0

Another draft charter for the RMCAT WG
by Harald Alvestrand 18 May '12

18 May '12

I tried for a more concise and "pointy" version of the description of what we need to get done. The text below came out. Is this something we can use as a starting point? What needs to change? This is a charter based on the one suggested in December 2011, but substantially rewritten. It is an input document. Draft is here: https://sites.google.com/a/alvestrand.com/rtp-congestion/bof-planning-page/… RTP Media Congestion Avoidance Techniques (rmcat) Status: Proposed Working Group Last Updated: 2012-05-08 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. The set of requirements for such an algorithm includes, but is not limited to: * Low delay for the case where there is no competing traffic using other algorithms * Fair share of bandwidth when there is competing traffic using other algorithms * 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 * Determine if there is an appropriate means to define standard RTP/RTCP extensions for carrying congestion control feedback, similar to how DCCP defines CCIDs, and if so, document such extensions as standards-track RFCs. * 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 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. * Modifications to TCP of any kind. The working group is expected to work closely with the RAI area, including the AVTCORE, AVTEXT and RTCWEB working group. 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 * Evaluation criteria for congestion control algorithms for interactive real time media - Informational RFC * RTCP extensions for use with congestion control algorithms - Standards-track 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 - still missing

3 3

BOF agenda for Vancouver
by Harald Alvestrand 11 May '12

11 May '12

It's time to get our act together for Vancouver if we wish to maintain "full speed ahead" with getting protocol documents suitable for real-time interactive media worked on and published. Here's a proposed BOF agenda - a way to spend 2 hours on figuring out what the right work is to do. BOF agenda, RMCAT BOF - Vancouver IETF The following is a draft agenda, subject to modifications. Names are tentative. * Intro (Chairs - 5 min) * Problem statement (Harald/Randell) - 25 min Covers existing protocols and their effect on low-delay streams * Context setting: BufferBloat & AQM (10 min) (?Gettys?) * RRTCC draft (10 min) (Stefan?) Describes existing proposal, Covering areas for improvement * Alternative Solution (10 min) (?) * Modified Cx-TCP?? Modified TFRC??? * Charter presentation, discussion (50 min) * Next steps/conclusion (10 min) Total timeslot: 2 hours.

3 3