July 2012 - Rtp-congestion

Suggesting a "Flow State Exchange" (FSE)
by Michael Welzl 06 Aug '12

06 Aug '12

Hi all, This is a "chair hat taken off and thrown into a corner" message - very much my personal thoughts, and I'm very curious what you all think: Starting point: there is a desire to have priorities between flows, e.g. in rtcweb, but maybe also between other RTP streams. I have been arguing that the right way to do this is to have only a single congestion control entity, and then realize fairness among the flows as a result of scheduling data across them. I still believe that this is the right way to do it (and - Randell please correct me if I'm wrong - it seems that this is the approach already pursued by Mozilla). This thinking led me to propose my all-over-SCTP idea. Now, I don't see how such a thing could be standardized, especially if we don't want to limit ourselves to rtcweb only. HOWEVER: it is clear that flows will need information about other flows - such as: what is their priority? How many are there, that we can assume to traverse the same bottleneck (e.g. because they share the same UDP 5-tuple)? What is their current sending rate? Without having agreed on how to exchange such information, I think it will be hard to implement the above fairness solution or any other good(*) solution in a standard-conformant way. Therefore I propose that we should standardize what I think is the simplest possible, necessary element: a "Flow State Exchange" (FSE). An FSE is a *passive* entity on a host that receives congestion- control-relevant information from RTP flows and provides that information upon request. It resides on a host, and if we define it in the right way it probably doesn't matter at which layer: one could have an FSE inside the browser, and optionally have the browser talk to an additional system-wide FSE in the kernel. Note that this is not the Congestion Manager (RFC3124): the CM was an *active* entity, much more complicated to realize, and much closer to the "single congestion control instance" idea described above. With an FSE, a single congestion control instance could be realized as follows: RTP flows => update the FSE. CC. instance => reads information from the FSE, then controls the sending rate per RTP flow and schedules data across the flows. Alternative implementation (not as good, but simpler, and just to show the flexibility): RTP 1 uses its own CC, RTP 2 uses its own CC, but they feed the priority they got "from above" into the FSE and read each other's priority and total sending rate from there, to adapt their increase/decrease behavior accordingly, leading to the desired total behavior on the wire. It's not hard to imagine that this could be extended in many ways - e.g. the SCTP data channel could access the FSE to also incorporate priorities there... and implementations could provide information about which flows share a bottleneck based on measurements, not only because of the UDP 5-tuple, without requiring to standardize any of that. But the FSE itself would have to be there. What do you all think? Cheers, Michael ----------------------- (*) The only prioritization solution that I can think of which would not require something along the lines of an FSE would be prioritized congestion control, i.e. giving weights to something like MulTCP, MulTFRC ... which means that the fairness you get is essentially what flows produce, as the result of fighting it out on the bottleneck. This will create more delay than any FSE-based solution, working against one main goal of all of us here: reduced delay.

8 13

Interesting talk in ICCRG tomorrow
by Michael Welzl 30 Jul '12

30 Jul '12

Hi, I just wanted to inform you all that in the ICCRG session tomorrow, Monday afternoon, there will be a talk by Grenville Armitage entitled "CAIA Delay-Gradient TCP", which could be of interest to this group. I'm sorry that ICCRG overlaps with RTCWEb - this is very unfortunate, and I asked to have it change, but it didn't work out. Maybe some of you folks could still make it... Cheers, Michael

1 0

BoF approved
by Wesley Eddy 25 Jul '12

25 Jul '12

The RMCAT BoF was approved to meet at IETF 84 in Vancouver. BoF chairs will be announced soon. 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. -- Wes Eddy MTI Systems

14 37

Updated agenda available
by Michael Welzl 24 Jul '12

24 Jul '12

Hi folks, The updated agenda for the RMCAT BOF is now available at: http://www.ietf.org/proceedings/84/agenda/agenda-84-rmcat and below. Cheers, Michael --- RMCAT BOF agenda, IETF #84 13:00 Introduction (Chairs) 13:05 Problem statement draft-jesup-rtp-congestion-reqs-00 (Alvestrand/Jesup) 13:25 Context: IAB/IRTF congestion control workshop 13:35 Context: competing traffic 13:45 Context: buffer bloat and AQM (Gettys) 13:55 Outline proposals for potential solutions draft-alvestrand-rtcweb-congestion-02 draft-ohanlon-rmcat-dflow-00 (Holmer/O'Hanlon) 14:05 Proposed charter (Chairs) 14:15 Discussion 14:50 Wrap-up and next steps (Chairs and ADs)

1 0

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