- Rtp-congestion - example.com

Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-01.txt
by Colin Perkins 16 Jul '12

16 Jul '12

This is a minor update only, primarily to update the version of the TCP throughput equation used, and to clarify a few points raised at the last meeting. A more significant update can be expected later in the summer. Colin Begin forwarded message: > From: internet-drafts(a)ietf.org > Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-01.txt > Date: 16 July 2012 23:56:28 GMT+01:00 > To: i-d-announce(a)ietf.org > Cc: avt(a)ietf.org > Reply-To: internet-drafts(a)ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions > Author(s) : Colin Perkins > Varun Singh > Filename : draft-perkins-avtcore-rtp-circuit-breakers-01.txt > Pages : 15 > Date : 2012-07-16 > > Abstract: > The Real-time Transport Protocol (RTP) is widely used in telephony, > video conferencing, and telepresence applications. Such applications > are often run on best-effort UDP/IP networks. If congestion control > is not implemented in the applications, then network congestion will > deteriorate the user's multimedia experience. This document does not > propose a congestion control algorithm; rather, it defines a minimal > set of "circuit-breakers". Circuit-breakers are conditions under > which an RTP flow is expected to stop transmiting media to protect > the network from excessive congestion. It is expected that all RTP > applications running on best-effort networks will be able to run > without triggering these circuit breakers in normal operation. Any > future RTP congestion control specification is expected to operate > within the envelope defined by these circuit breakers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-perkins-avtcore-rtp-circuit-breakers > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-perkins-avtcore-rtp-circuit-breakers-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=draft-perkins-avtcore-rtp-circuit-breake… > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce(a)ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- Colin Perkins http://csperkins.org/

1 0

Re: [R-C] BoF approved
by Bob Briscoe 12 Jul '12

12 Jul '12

Matt, Indeed - we can carve out any scope we want out of the wider scope of the whole problem space. My concern was that the argument for choosing the particular scope of RTP transport seemed based on some misunderstanding. It would be perfectly valid to work solely on RTP transport if it was to make sure it doesn't starve out elastic traffic. This was the proposal from people like Colin Perkins, which was a sensible attempt to focus down the work (setting aside whether there is a feasible solution). Bob At 21:59 07/07/2012, Matt Mathis wrote: >I would like to point out that nobody has actually disagreed: If >"fixing the network" means something like "deploy QoS" then yes it >is absolutely out of scope. However "diagnosing (the lack of) QoS" >is absolutely in scope. It should have the indirect effect of >causing the former, irregardless of scope or who owns the problem. > >Note that the Internet will almost certainly be better served by QoS >metrics that are built into all applications and determined by their >needs, rather than the intent of the QoS implementers. > >And (I hope) we all agree that rtcweb can not directly fix network >problems, no matter how well it performs. > >Thanks, >--MM-- >The best way to predict the future is to create it. - Alan Kay > > > >On Sat, Jul 7, 2012 at 11:13 AM, Jim Gettys ><<mailto:jg@freedesktop.org>jg(a)freedesktop.org> wrote: >On 07/07/2012 01:35 PM, Bob Briscoe wrote: > > Michael, Bill, > > > > The proposed logic for focusing on the R-T transport is that network > > fixes will only be deployed piecemeal, so some parts of the Internet > > won't have the new functions in them, therefore any fix has to be done > > in the e2e transport. This sounds logical if you don't think too hard > > about it, but... > > > > 1/ If the chosen problem to address is that TCP flow(s) are running up > > to the tail of a slow buffer and causing delays and losses that make > > simultaneous r-t delivery quality poor, then no amount of improvement > > to RTP alone will fix this. The impairment would be caused by the TCP > > traffic even if the RTP flow(s) weren't there, so adding an RTP flow > > cannot /reduce/ impairments caused by other transports (unless it > > includes a magic anti-delay-sucking nano-worm). > >Bob is exactly correct: no programming around bufferbloat will work for >real time, no protocols magic will work that I can see. > >Ledbat only works because you are trying to do the opposite: keep it >from interfering with TCP. And even there, Ledbat stops working once >AQM (e.g. CoDel) keeps the delays low. The inverse just won't work. > >c.f. ><http://gettys.wordpress.com/2012/05/14/the-next-nightmare-is-coming/>http://gettys.wordpress.com/2012/05/14/the-next-nightmare-is-coming/ > >And even a single TCP connection will do you in today. > > > > > For instance, if we added delay sensing to the R-T transport, it will > > sense delay, back-off and TCP will just continue, while the RTP > > starves itself (cf Vegas). > > > > If TCP-induced impairment is indeed the chosen problem, then limiting > > the scope to R-T transport only will therefore achieve precisely nothing. > > > > 2/ If the chosen problem is to prevent an R-T transport doing harm to > > other elastic (TCP) traffic (or other R-T traffic for that matter), > > then focusing on RTP makes perfect sense. > > > > 3/ If problem #1 (preventing TCP harming RT) is in scope, then network > > changes are the *only* way to solve this aspect. They won't solve it > > anywhere but where they are deployed, but this is better than solution > > #1 (focus on R-T transport alone), which solves it precisely nowhere. > >I think we must presume the network gets fixed. Broadband (and WiFi) are >both broken well beyond real time standards required for good audio to >be reliable. > >The biggest parts of the bufferbloat problem (at least that we know >today; we may be looking for keys under the lamppost) are the two common >bottlenecks at the edge of the network. In your house, those are your >broadband connection, and your WiFi hop (both sides of the WiFi hop; >your operating system needs to be fixed too). Cellular wireless is >somewhat similar, but also somewhat different. > >I think the right strategy for rtcweb are two fold: > a) making sure that everything works well for real time when the >network has been fixed. > cf. ><http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-t…>http://gettys.wordpress.com/2012/06/26/the-internet-is-screwed-up-and-how-t… > b) detecting the problem, so that people know to go get it fixed, >and which hops are broken. Preferably by pointing the finger to the >offending component, so that it gets fixed, whether your operating >system, your home router, your broadband cpe, your broadband head end. > >So Bob is exactly correct on this; you can't engineer real time traffic >around bufferbloat in today's broken internet by protocol magic. You >can, however fix the broken components (and in your home, with care, do >pretty well even today if you are clever). cf. ><http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferb…>http://gettys.wordpress.com/2010/12/13/mitigations-and-solutions-of-bufferb… >And you can come help fix the problem for real, in home routers, and >elsewhere in the network. > - Jim > > > > > > > > > > Bob > > > > > > > > At 16:03 07/07/2012, Michael Welzl wrote: > >> I agree. > >> > >> It seems clear to me that the ability to work everywhere is the top > >> goal of rtcweb; interactions with the network have to be considered, > >> of course (any congestion control algorithm will have to consider > >> queue behavior). > >> > >> More below, in line: > >> > >> > >> On Jul 6, 2012, at 6:20 PM, Bill Ver Steeg (versteb) wrote: > >> > >>> I agree that this is not the right forum for discussing middlebox > >>> buffer management algorithms. I would add that even if the network > >>> elements do creep into scope, the host-based congestion control > >>> algorithms still have to work with the existing systems found in the > >>> wild. In other words, we could suggest that the middleboxes > >>> implement [insert your favorite AQM algorithm here]and [insert your > >>> pick of ECN, PCN, or maybe even Conex, etc] but the hosts still need > >>> to deal with [tail drop, RED, WRED, etc]. > >>> > >>> Stated another way, the algorithm is going to get a variety of > >>> congestion signals. When running on networks with primitive buffer > >>> management algorithms, one of those signals is going to be delay. On > >>> more modern systems, we can hope that the middleboxes' buffer > >>> management algorithms do not introduce persistent delay. > >>> > >>> So, the RMCAT work will have to consider delay, packet loss and > >>> explicit packet markings. In a perfect world, the network will never > >>> give us persistent delay - but the world is rarely perfect. > >>> > >>> Bill VerSteeg > >>> > >>> -----Original Message----- > >>> From: > <mailto:rtp-congestion-bounces@alvestrand.no>rtp-congestion-bounces(a)alvestrand.no > >>> [mailto:rtp-congestion-bounces@alvestrand.no ] On Behalf Of John Leslie > >>> Sent: Friday, July 06, 2012 11:38 AM > >>> To: Bob Briscoe > >>> Cc: > <mailto:rtp-congestion@alvestrand.no>rtp-congestion(a)alvestrand.no; > Michael Welzl > >>> Subject: Re: [R-C] BoF approved > >>> > >>> Bob Briscoe <<mailto:bob.briscoe@bt.com>bob.briscoe(a)bt.com> wrote: > >>>> At 11:41 06/07/2012, Michael Welzl wrote: > >>>>> On 6/26/12 4:05 PM, Wesley Eddy wrote: > >>>>>> The RMCAT BoF was approved to meet at IETF 84 in Vancouver. > >>> > >>> From > <http://trac.tools.ietf.org/bof/trac/>http://trac.tools.ietf.org/bof/trac/ : > >>> ] > >>> ] Transport > >>> ] > >>> ] RTP Media Congestion Avoidance Techniques (RMCAT) > >>> ] > >>> ] Description: WG-forming BoF on RTP congestion control > >>> ] Responsible AD: Wesley Eddy > >>> ] BoF Chairs: Michael Welzl and Colin Perkins > >>> ] Number of people expected to attend: 100 > >>> ] Length of session: 2 hours > >>> ] Conflicts to avoid: RTCWEB, AVTCORE, MMUSIC, ICCRG, CODEC, TSVWG, > >>> TCPM, > >>> ] CONEX, PCN, MPTCP, IPPM, CORE > >>> ] Webex: not sure > >>> ] Meetecho: not sure > >>> ] Mailing > list: <mailto:rtp-congestion@alvestrand.no>rtp-congestion(a)alvestrand.no > >>> ] I-Ds: > >>> > <http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion/>http://datatracker.ietf.org/doc/draft-alvestrand-rtcweb-congestion/ > >>> ] > >>> http://datatracker.ietf.org/doc/draft-jesup-rtp-congestion-reqs/ > >>> ] Draft charter: > >>> ] > >>> > <http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000381.html>http://www.alvestrand.no/pipermail/rtp-congestion/2012-May/000381.html > >>> ] Status: APPROVED > >>> > >>>>>> When it was discussed by the IESG and IAB, one topic that really > >>>>>> needs to be clarified by/within the group is the scope of the > >>>>>> mechanisms being developed. For instance, it needs to be more > >>>>>> clear what stack the group wants to be chartered to operate on. > >>>>>> Whether the group would be doing a mechanism that works for RTP > >>>>>> itself, or a new SCTP mechanism will need to be very clear. > >>>>> > >>>>> I would like to get a grip on exactly *what* really *is* decided > >>>>> regarding the way the stack looks. Which protocol over which > >>>>> protocol(s) for which type of data. > >>>>> ... > >>>> > >>>> Michael, > >>>> > >>>> Recall at the Paris ICCRG I asked the wider question of whether > >>>> changes to the network are in scope. > >> > >> Personally, for the sake of keeping focus, I would say it's out of > >> scope. > >> > >> > >>> This is Transport area, with Wes the expected Responsible AD. > >>> > >>> That means Network-Layer isn't expected to be in-scope for the WG. > >>> > >>> I would hope, however, that discussion of potential Network-Layer > >>> work which would be helpful would be in-scope for the BoF. > >>> > >>>> I know those proposing this believe the scope is v definitely e2e > >>>> protocols only (at least, if not specified down to a specific e2e > >>>> protocol), but the scope determines very greatly how much of the > >>>> problem we're going to solve: > >>>> > >>>> * If RTP-only, we don't solve TCP harming RTP, only the other way > >>>> round (which is fine if that's the scope we want) > >> > >> I don't understand that. > >> > >> > >>>> * If SCTP-only, I'm not sure what we solve? > >> > >> I get the impression that SCTP-only is not an option. > >> > >> > >>>> * If we allow network to be in scope, we might be able to address > >>>> bufferbloat-style issues, or perhaps good policer designs to protect > >>>> apps from each other. > >> > >> Good policer designs that work well with rtcweb would be cool to have, > >> but why can't that be done e.g. in ICCRG? > >> > >> > >>> I expect to do a rant at the Workshop on Congestion Control for > >>> Interactive Real-Time Communication July 28th, to the effect that this > >>> can't be solved at the Transport Layer only. > >>> > >>> It looks as if enough of us will be there to discuss Bob's question. > >> > >> I agree, but I think we should try to get consensus on some key issues > >> earlier than that. > >> > >> > >>> > >>>> My personal opinion is that this w-g should be trying to solve the > >>>> problem. And the problem has three halves: > >>>> * RTP harming elastic > >>>> * elastic harming RTP > >>>> * network arbitrating between the two > >>> > >>> Clearly the first needs to be in-scope for the WG. > >>> > >>> IMHO the other two halves need to be discussed at the BoF. > >> > >> If I understood it correctly, Matt Mathis argued that neither the > >> first nor the second should be in scope. I'd like to hear some more > >> views on that. > >> > >> Having read RFC5434, I think a general goal, and the role of Colin and > >> me, is to try to maximize consensus and minimize the amount of > >> discussion-at-the-BOF beforehand. > >> So naturally I disagree, for now, that these things need to be > >> discussed there. Let's try to agree on as much as possible before it. > >> > >> Cheers, > >> Michael > > > > ________________________________________________________________ > > Bob Briscoe, BT Innovate & Design > > _______________________________________________ > > 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

3 3

Support for Remote Participation at the July 28 IAB / IRTF Workshop on Congestion Control for Interactive Real-Time Communication
by Bernard Aboba 21 Jun '12

21 Jun '12

The Program Committee has received inquiries about remote participation at the IAB/IRTF Congestion Control Workshop to be held on July 28, 2012 in Vancouver, Canada. While participants are strongly encouraged to attend the meeting in person, arrangements for remote participation are planned (for those with accepted papers). Therefore if you were considering submitting a paper but could not make the workshop in person, we would encourage you to go ahead and submit; please indicate in your submission if you are only able to participate remotely. Call for Papers 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. More information on the workshop is available at http://www.iab.org/cc-workshop/ This is an invitation-only workshop. Every prospective workshop participant must submit a position paper. The position paper reflects your views on a particular area of the workshop theme. We are interested in your opinion as an expert rather than your official company position. Keep your submission short and focused. The focus should be on the problems and challenges that exist, rather than a detailed solution. If your expertise allows you to write about a range of topics, please pick the one topic you think would bring the most value to the workshop. Papers up to 3 pages, formatted in HTML, PDF, or plain text (for example, as a submitted Internet-Draft) are ideal. Authors of accepted papers will be invited to the workshop. Accepted position papers will be published. Please use the following Website for submitting your papers: http://iab.org/ccirtc/paper?p=new Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 Note: please contact us if you are interested in submitting a paper but have an issue with the submission deadline. IPR Policy Due to the close relationship to ongoing IRTF and IETF work, the IPR policies described in RFC 5378 and RFC 3979 apply, both to submitted position papers and to discussions at the workshop. Privacy Notice Paper submissions have to contain a name and an email address. We use this information to subscribe you to a mailing list for sharing workshop related information prior to the workshop (e.g., updates regarding the meeting venue, feedback on the position paper submissions). This specially created mailing list is only used for the duration of the workshop and will be deleted after the publication of the workshop report (which may take several months). You may at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop related postings). Your name will be listed in the meeting minutes and the workshop report. We will also publish all accepted position papers. There will be an audio recording of the workshop discussion. This workshop recording will not be distributed to the workshop participants nor to the public; the purpose of the recording is to ensure that the workshop report and the meeting minutes accurately reflect the discussions. Meeting Venue The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html) Additional details about the meeting venue will be provided to authors of accepted papers. While participants are strongly encouraged to attend the meeting in person, arrangements for remote participation are planned (for those with accepted papers). Please indicate in your submission if you are only able to participate remotely. Sponsorship 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! Contact Information In case of questions please send email to mary.ietf.barnes at gmail.com

1 0

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

16 Jun '12

Call for Papers 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. More information on the workshop is available at http://www.iab.org/cc-workshop/ This is an invitation-only workshop. Every prospective workshop participant must submit a position paper. The position paper reflects your views on a particular area of the workshop theme. We are interested in your opinion as an expert rather than your official company position. Keep your submission short and focused. If your expertise allows you to write about a range of topics, pick the one topic you think would bring the most value to the workshop. 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. Please use the following Website for submitting your papers: http://iab.org/ccirtc/paper?p=new Important Dates Position paper submission deadline: June 23, 2012 Notification to paper authors: June 30, 2012 Workshop date: July 28, 2012 IPR Policy Due to the close relationship to ongoing IRTF and IETF work, the IPR policies described in RFC 5378 and RFC 3979 apply, both to submitted position papers and to discussions at the workshop. Privacy Notice Paper submissions have to contain a name and an email address. We use this information to subscribe you to a mailing list for sharing workshop related information prior to the workshop (e.g., updates regarding the meeting venue, feedback on the position paper submissions). This specially created mailing list is only used for the duration of the workshop and will be deleted after the publication of the workshop report (which may take several months). You may at any time decide to unsubscribe from the mailing list (at your risk of missing information workshop related postings). Your name will be listed in the meeting minutes and the workshop report. We will also publish all accepted position papers. There will be an audio recording of the workshop discussion. This workshop recording will not be distributed to the workshop participants nor to the public; the purpose of the recording is to ensure that the workshop report and the meeting minutes accurately reflect the discussions. Meeting Venue The workshop will be held in Vancouver, Canada on Saturday, July 28th, 2012 prior to the IETF-84 meeting (see http://www.ietf.org/meeting/84/index.html) Additional details about the meeting venue will be provided to authors of accepted papers. Sponsorship 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! Contact Information In case of questions please send email to mary.ietf.barnes at gmail.com

1 0

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