- Rtp-congestion - example.com

About the all-SCTP way of doing it
by Michael Welzl 05 Apr '12

05 Apr '12

Hi all, I've been giving this some more thought, and now think that it is a mistake to try to build a RTP-UDP-based congestion control mechanism with logic at the receiver, to plan when to send feedback and minimize it accordingly. The reason is that you want to sample the path often enough anyway, and that you may have SCTP operating on the data stream in parallel too. So that can give you a situation where you get a lot of ACKs all the time in SCTP, which will be ignored by the UDP-based algorithm, which is meanwhile struggling to reduce its own feedback. All this feedback is really only about the congestion status on the path anyway, i.e. SCTP ACKs give you all the information you need. So my proposal would be: - use SCTP for everything - add per-stream congestion control to it, all on the sender side - use some other RTCWeb based signalling to negotiate the congestion control mechanism, in the style of DCCP - let all streams benefit from SCTP's ACKs; if we anyhow need to reduce the amount of feedback, we could use an appropriate means that's related to transport, and not the RTCP rule which has nothing to do with congestion control: ACK-CC, RFC 5690 would give a good basis for that. (on a side note, when you run RTP over SCTP, you don't break any RTP rules regarding the amount of feedback I think...) This way, with all the congestion control logic happening on the sender side, it would be much easier to manage the joint congestion control behavior across streams - to control fairness among them, as desired by this group. Note that this can yield MUCH more benefits than meets the eye: e.g., if an ongoing transfer is already in Congestion Avoidance, a newly starting transfer across the same bottleneck (which you'll have to - correctly or not - assume for RTCWeb anyway) can skip Slow Start. In a prototypical example documented in: Michael Welzl, Florian Niederbacher, Stein Gjessing: "Beneficial Transparent Deployment of SCTP: the Missing Pieces", IEEE GlobeCom 2011, 5-9 December 2011, Houston, Texas (fig.7) ...we transferred two files across a testbed where we used the (at least then, very large) default Linux queue length (txqueuelen). The transfer time of the shorter file was reduced by almost 4 seconds, at no significant cost for the other transfer. In such a setup, a mechanism based on LEDBAT could perhaps be used (in a similar style as in the current proposal, using the TCP equation as a lower limit, and maybe tuning some parameters to be a bit more aggressive?), giving the benefit that LEDBAT has already been tested. What do y'all think? Cheers, Michael

4 5

Re: [R-C] [AVTCORE] I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
by Colin Perkins 04 Apr '12

04 Apr '12

Mark, So far, we haven't really considered RTP/AVPF rapid feedback (Section 5 of the draft is essentially a placeholder, and the mechanisms in Section 4 are specifically for baseline RTCP). As you've noticed, it changes the dynamics significantly, and we need to think carefully on how the various rapid feedback modes interact with the circuit breaker conditions before we define anything. Colin On 4 Apr 2012, at 02:55, Mark Handley wrote: > Colin, Varun, > > Can you clarify how the circuit breaker mechanism would work with RFC > 4585 extended feedback. To make things concrete, I'm thinking about > the following scenario: > > - Sender is sending 2Mb/s video into a 4Mb/s DSL line. RTT is 100ms. > - Receiver is allowed to send up to 2.5% of this as RTCP feedback in > ACK mode, so that's 6.5 packets per RTT if I got the maths right. > - A TCP flow slowstarts, doubles the window for the last time and > collides with the RTP flow in the wonderful way slowstart sometimes > does. If you're unlucky, you'll get 33% packet loss for one full RTT > before TCP backs off. > - The RTCP receiver sends 6 successive RTCP reports over one RTT > indicating 33% loss. If doesn't really matter if ACKs or NACKs are > sent in this scenario. > > The calculated TCP rate would be ~18Kb/s for those parameters, so the > circuit breaker would kick in if I understood the draft correctly > because that's more than two reporting intervals with excessively high > loss. > > This is the main reason for loss event rate in the TFRC specification > - you avoid responding to such transients too strongly. > > Cheers, > Mark > > > > On 5 March 2012 23:32, Colin Perkins <csp(a)csperkins.org> wrote: >> Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution. >> >> Colin >> >> >> >> Begin forwarded message: >>> From: internet-drafts(a)ietf.org >>> Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt >>> Date: 5 March 2012 20:17:59 GMT >>> To: i-d-announce(a)ietf.org >>> Reply-To: internet-drafts(a)ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>> >>> Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions >>> Author(s) : Colin Perkins >>> Varun Singh >>> Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt >>> Pages : 14 >>> Date : 2012-03-05 >>> >>> The Real-time Transport Protocol (RTP) is widely used for telephony, >>> video conferencing, and telepresence applications. These >>> applications are often used over best-effort UDP/IP networks. If >>> congestion control is not implemented then network congestion will >>> deteriorate the user's multimedia experience. This document does not >>> propose a congestion control algorithm. Instead, it specifies a >>> minimal set of "circuit-breakers". Circuit-breakers are conditions >>> under which an RTP flow should cease to transmit 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. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-break… >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt(a)ietf.org >> https://www.ietf.org/mailman/listinfo/avt -- Colin Perkins http://csperkins.org/

2 1

Fwd: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt
by Colin Perkins 04 Apr '12

04 Apr '12

Here's our initial attempt at a "circuit breakers" draft for RTCWeb. Comments welcome - this is very much a straw-man for discussion, rather than a final solution. Colin Begin forwarded message: > From: internet-drafts(a)ietf.org > Subject: I-D Action: draft-perkins-avtcore-rtp-circuit-breakers-00.txt > Date: 5 March 2012 20:17:59 GMT > To: i-d-announce(a)ietf.org > Reply-To: internet-drafts(a)ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : RTP Congestion Control: Circuit Breakers for Unicast Sessions > Author(s) : Colin Perkins > Varun Singh > Filename : draft-perkins-avtcore-rtp-circuit-breakers-00.txt > Pages : 14 > Date : 2012-03-05 > > The Real-time Transport Protocol (RTP) is widely used for telephony, > video conferencing, and telepresence applications. These > applications are often used over best-effort UDP/IP networks. If > congestion control is not implemented then network congestion will > deteriorate the user's multimedia experience. This document does not > propose a congestion control algorithm. Instead, it specifies a > minimal set of "circuit-breakers". Circuit-breakers are conditions > under which an RTP flow should cease to transmit 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. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-perkins-avtcore-rtp-circuit-break… -- Colin Perkins http://csperkins.org/

6 15

Decision on rate control
by Harald Alvestrand 02 Apr '12

02 Apr '12

Given the difficulties involved in defining fairness in new congestion control algorithms, the leadership has decided that RSVP will be mandatory for all use of WebRTC. Harald -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

5 4

Re: [R-C] [Iccrg] Re: Timely reaction time (Re: Comments on draft-alvestrand-rtcweb-congestion-01)
by Michael Welzl 02 Apr '12

02 Apr '12

Argh, yes, I guess this one letter was the cause of a misunderstanding... Thanks! Sent from my iPod On Apr 1, 2012, at 23:56, Lachlan Andrew <lachlan.andrew(a)gmail.com> wrote: > Greetings Michael, > > Are you saying you need an emergency "brake" (i.e., slowing down) > rather than emergency "break" (i.e., termination, with or without a > restart later)? > > Cheers, > Lachlan > > On 30 March 2012 21:17, Michael Welzl <michawe(a)ifi.uio.no> wrote: >> >> On Mar 30, 2012, at 10:33 AM, Harald Alvestrand wrote: >> >>> On 03/29/2012 01:55 PM, Michael Welzl wrote: >>>> >>>> >>>> >>>>> Section 4: par 3, "This algorithm is run every time a receive >>>>> report >>>>> arrives..." => so in case of severe congestion, when nothing >>>>> else arrives, >>>>> this algorithm waits for 2 * t_max_fb_interval... so can we rely >>>>> on the >>>>> mechanism to react to this congestion after roughly an RTO or >>>>> not? (sounds >>>>> like not) Is that bad? (I guess) >>>>> >>>>> There is a need for some emergency break mechanism if no >>>>> feedback gets >>>>> through. >>>> >>>> >>>> I totally agree - what I meant is, it isn't clear to me if that >>>> emergency >>>> break is activated in time or too late. It should be in time >>>> (i.e. after >>>> roughly an RTO). >>> >>> This seems to be a subject that should be discussed in the context >>> of the >>> circuit-breakers draft: What kind of response time is appropriate >>> for such a >>> mechanism, and why? >> >> >> I think not: we're talking about two kinds of situations here. The >> context >> here is: there was congestion, we should react to it within an RTO >> (and have >> an "emergency break" to always do that - but maybe that term was >> misleading). The circuit-breakers draft is about a much more serious >> condition (such as persistent congestion), warranting a much more >> serious >> reaction (terminating the connection). >> >> Cheers, >> Michael > > > > -- > Lachlan Andrew Centre for Advanced Internet Architectures (CAIA) > Swinburne University of Technology, Melbourne, Australia > <http://caia.swin.edu.au/cv/landrew> > Ph +61 3 9214 4837

2 2

Comments on draft-alvestrand-rtcweb-congestion-01
by Michael Welzl 01 Apr '12

01 Apr '12

Hi all, I have read draft-alvestrand-rtcweb-congestion-01. High-level comments: Today, this has been called a "strawman proposal". I agree with this way of looking at it. There are some quite interesting ideas there; however, a lot seems to appear "out of the blue", leaving the reader puzzled about the rationale behind some design choices. I wonder if these design choices are based on some academic papers out there - could citations help? Anyway, instead of trying to discuss the algorithm "in the air", it would be better to first work with some data: how does the mechanism really work in a real-life system? How does it interact with TCP? How sensitive is this mechanism to the typical issues raised for delay-based controls (the latecomer unfairness problem, behavior with very small queues, ..)? How likely is it for the derived rate of the mechanism to fall below the TFRC- function limit, under what conditions will this happen? As for the writing style, around the middle of section 3.2 you depart from what I would consider a reasonable amount of equations for an RFC. It might be better to point to a document where the derivation is given. Finer-grain comments: I got confused by your usage of "frame" - typically, to me, a frame is a packet at the link layer, or a picture in a video. Generally I have the impression that you use the word "frame" to refer to packets, but then towards the end of section 3.2 you talk about "the highest rate at which frames have been captured by the camera". On a side note, that is anyhow inappropriate, I guess, as this mechanism shouldn't necessarily be restricted to video (could be audio too), right? Same paragraph: "Since our assumption that v(i) should be zero mean WGN is less accurate in some cases" => why? Section 3.1: "Since the time ts to send a frame of size L over a path with a capacity C is" => this should at least say "roughly", as it omits a lot of (arguably, perhaps irrelevant) factors. Equation 5: I don't think that m(i) and v(i) have been defined before. (even though it seems obvious what is meant) Section 3.4: it's confusing to talk about increasing or decreasing "the available bandwidth" - if I got this right, what you do increase or decrease is the *receiver-side estimate* of the available bandwidth. Section 4: par 3, "This algorithm is run every time a receive report arrives..." => so in case of severe congestion, when nothing else arrives, this algorithm waits for 2 * t_max_fb_interval... so can we rely on the mechanism to react to this congestion after roughly an RTO or not? (sounds like not) Is that bad? (I guess) I hope that's useful, Cheers Michael

7 18

ICCRG meeting minutes
by Michael Welzl 01 Apr '12

01 Apr '12

Hi all, I have uploaded the minutes to: http://www.ietf.org/proceedings/83/minutes/minutes-83-iccrg.txt Thanks a lot to Gorry Fairhurst for taking them!! Please send any comments / corrections to the ICCRG list. Thanks! Cheers, Michael

1 0

Discussion on Congestion Control for RTP
by Ashwin Rao 29 Mar '12

29 Mar '12

Hi, At the iccrg presentations at IETF there were a good number of people who were interested in working on congestion control for RTP. I am interested in working on congestion control for RTP I have expressed my interest to a few people working on RTCWeb at Mozilla. I would like to know if any one is interested in discussing the problems in this area. I would like to discuss some problems after the conex meeting that ends at 19:40 in room 253. We could meet in this room after the conex presentation and if required move to another room. Topics that I would like to discuss include 1. Is RTCWeb [ http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-01 ] being too conservative with respect to increasing the rate of sending packets. 2. How to address issues that affect the performance of delay based congestion control algorithms like TCP Vegas. 3. Lessons learned from LEDBAT. Regards, Ashwin

1 0

Circuit Breaker draft adaptation
by Magnus Westerlund 29 Mar '12

29 Mar '12

Hi, I have started a call for adoption as WG item work on the circuit breaker in the AVTCORE. Please comments on the call in AVTCORE. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund(a)ericsson.com ----------------------------------------------------------------------

1 0

Simplifying the TCP throughput algorithm
by Harald Alvestrand 29 Mar '12

29 Mar '12

I did some extremely rough numerical experiments with the TCP throughput algorithm. Results for TCP throughput in bits/sec at MSS=1440 bytes at various loss rates: 0.001% loss: Throughput 4.5 Mbits/sec (HD can survive) 0.01% loss: Throughput 1.4 Mbits/sec 0.1% loss: Throughput 458 Kbits/sec (VGA can survive) 1% loss: Throughput 144 Kbits/sec (good audio can survive) 10% loss: Throughput 43 Kbits/sec (crappy audio can survive) These are stable in the first 2 digits over a large range of RTT (1 ms to 100 ms). Interesting numerical result: In all cases, the second term of the TCP throughput denominator is less than 1% of the first term, so a reasonable approximation is: T = s / sqrt(p * 2/3) That's a simple formula. Harald

7 12