April 2012 - Rtp-congestion

LEDBAT - introductions?
by Harald Alvestrand 12 Apr '12

12 Apr '12

Query: LEDBAT has been battered about several times in recent threads. I don't know what it is (apart from being a WG active at http://tools.ietf.org/wg/ledbat/ ) - could anyone give a quick summary of: - what it is - where it's at in its talk/develop/deploy/learn ycle - what the core properties are? harald

12 20

Getting a WG for RTP congestion Control
by Magnus Westerlund 11 Apr '12

11 Apr '12

Folks, I think it is excellent that people are interested in discussing possible solutions and obstacles for a congestion control algorithm suitable for real-time interactive media over best-effort Internet paths. However, I think there is more important things to discuss at this stage, namely the planning for the BOF in Vancouver. Time is actually much shorter than people may realize. The request must be sent to the AD no later than: 2012-06-18 (Monday) by at 17:00 PT (UTC -7). For this the BOF procedures applies and the following rules applies: http://www.ietf.org/iesg/bof-procedures.html If you go look at what information the IESG expect at their discussion teleconf shortly after the cut-off (http://trac.tools.ietf.org/bof/trac/) it is informations such as proposed charter, Internet-drafts, existence of mailing list, existence of both proponents and hopefully intended BOF chairs. As a former IESG member a reasonable solid charter, existence of related Internet drafts and a clear and active community (as shown by activity on the mailing list) is the most important to get the BOF approved. I also recommend that people read RFC 5434 "Considerations for Having a Successful Birds-of-a-Feather (BOF) Session" http://www.rfc-editor.org/rfc/rfc5434.txt Thus I think it is important that we focus on these matters that leads to a successful BOF. Thus I think we need to focus on two things. Ensure that we have an agreeable charter. My general understanding of the idea for the WG was the following: 1. A WG with the long term goal of eventually be able to recommend a congestion control algorithm suitable for real-time interactive media. 2. To get to that we need a WG that does the following: a) Discuss what requirements and consideration real-time media imposes b) Determine how we can evaluate and discuss different proposals in a constructive way c) Allows people to present, discuss and most likely publish experimental proposals for solution. I believe the WG charter should be solution neutral as I am not willing to bet on a particular horse this early. The ADs attempt on a charter is documented here: http://www.ietf.org/iesg/evaluation/rmcat-charter.txt I don't know if it has been updated with the feedback provided. I think everyone should review and provide feedback on the charter proposal anyway. For a successful BOF at the Vancouver IETF meeting I think we need the following things being discussed at the BOF: 1) The high level requirements that Interactive Real-time media imposes 2) Why existing solutions such as TFRC(-SP), AIMD, LEDBAT aren't working well enough and need more work. 3) Some short presentation of ideas for solutions. No more than 10 minutes preferably 2 to show multiple interest and multiple solutions. 4) Discussion of the charter and how a WG would work addressing these topics. The BOF also needs sufficient discussion time of at least 1 hour. This as you see would need that we have a number of presenters preparing different presentations. We also need several people with sufficient aligned views to actively argue in the same general direction. We also need some one taking the responsibility for driving the process and ensuring that the right things happens in a sufficiently timely fashion. To make it clear, that one is not me! I have WGs to run. 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

One congestion control to bind them all!
by Michael Welzl 09 Apr '12

09 Apr '12

Dear all, First, let me apologize for giving you "Michael's view of how our transport should be built" in this piecemeal fashion... you're getting a glimpse at how gradual my brain operates :-( I just can't help it. I have now figured out that the best way to do transport for RTCWEB would involve using only ONE type of congestion control for everything (note that I'm not making any specific argument here about whether this is based on draft-alvestrand-rtcweb-congestion or LEDBAT or whatever). Why? Simply because your goal is to keep the delay low, by avoiding queue growth. TCP - and also SCTP's standard congestion control - will always try to push up the bottleneck queue until it sees a packet loss (or ECN), and therefore always be detrimental. Now, that's just a fact of life that we have to deal with - there may be other TCP traffic sharing the same bottleneck, and we want to do reasonably well in competition while trying to minimize queuing delay. This is not an ideal situation but it's what we have to live with. However, what we really don't want to do is to embed a standard-TCP-like congestion control mechanism WITHIN RTCWEB?! If an RTCWEB user wants to have a video phone conversation and at the same time sends a file, if I understand it correctly, that file would be transferred using SCTP and its standard TCP-like congestion control. So the file transfer would push up the queue at the bottleneck and thereby increase the delay experienced by the user - the user would shoot her/himself in her/his foot by sending the file. You really don't want that to happen, I guess? I think that the correct solution to that problem is to have only one type of congestion control, make it (mostly) delay-based to minimize queuing delay, and let that congestion control dictate the total rate available to the RTCWEB sender. Then, let the sender schedule packets across the video-, audio- and file-transfer streams based on some fairness policy. This gives you the best possible control over fairness as an extra - it's much better than trying to influence how the flows compete with each other on the bottleneck. Well, and again it seems to me that SCTP looks ideal for that type of usage. Theoretically, it could perhaps be okay to use multiple different types of delay-based (delay-minimizing) controls in parallel, e.g. using draft-alvestrand-rtcweb-congestion-01 for video / audio and LEDBAT for data transfer, but that just seems to make the situation more complicated and it would give you less control over the fairness among the streams. Curious to hear what you think :-) because I *know* I'm right :-D Cheers, Michael

4 8

The rate control behavior strange during test
by Fu Jiantao 09 Apr '12

09 Apr '12

Hi, I've give the rate control implemented in webrtc a test, seems its behavior is abnormal. I'm using the peerconnection_client to do the test, and use netlimit to set one-way bandwidth to 50KB/s, the rate of other direction fluctuate dramatically, from 10KB/s to 200KB/s, I tried to open the relating logs, but after that, the connection won't setup, there seems some bug in the connection setup, I've updated the code, and it failed to compile. Seems the jsep is not ready now. And I can't test on it now. So, it's there any problem in my test? Is there any existing test report on this? Thanks, Jeromy

3 3

General thoughts about the congestion control for RTC web
by Matt Mathis 08 Apr '12

08 Apr '12

I assembled the following text for possible inclusion in an introduction or problem statement: ---- The RTC web congestion control is distinctly different from other congestion control problems. The goal is to choose a codec and/or codec parameters that simultaneously minimize self inflicted queueing delay while maximizing [multi-media image/signal] quality. In almost all cases the selected network operating point will be well below the operating point that would be chosen by any traditional throughput maximizing congestion control algorithm. The traditional congestion control problem is to maximize throughput for some "TCP-friendly" capacity allocation, and typically involves creating standing queues at bottlenecks. Without AQM, TCP and other throughput maximizing protocols generally control against queue full. Even with AQM or delay sensing congestion control algorithms, these protocols generally strive to establish at least a small standing queue, because they get their self clock from queued data passing through the bottleneck, and the standing queue helps to smooth jitter in the ACKs and other phenomena that might otherwise cause idle (wasted) link capacity. The RTC web congestion control is explicitly designed to detect if a given encoding causes persistent queues, and to select a lower rate if so. This is nearly guaranteed to leave some unused network capacity and would be considered suboptimal for a throughput maximizing protocol. Thus it is unlikely that any properly functioning RTC web application will endanger any throughput maximizing protocol. The inverse is not at all true. It can be anticipated that TCP and other throughput maximizing protocols have the potential to cause unacceptable queueing delays for RTC web based application, unless one of two strategies are implemented: the traffic is segregated into separate queues such that delay sensitive traffic does not get queued behind throughput maximizing traffic, or alternatively that the AQM is tuned to maintain very short queues under all conditions. This latter strategy is likely to imply that the AQM creates sufficient losses or ECN marks where the throughput maximizing protocols can't fill the link, and leaves idle capacity. We assume that the RTC web traffic is somehow protected from other throughput maximizing traffic. Enabling RTC web and throughput maximizing protocols to simultaneously meet their respective objectives in a single queue is beyond the scope of this work. --- Comments? Debate? Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay

3 4

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