March 2012 - Rtp-congestion

Slides for the ICCRG session
by Harald Alvestrand 25 Apr '12

25 Apr '12

My slides for the ICCRG session, all in one PDF - as of Friday night. Will send them to the ICCRG chairs by Sunday morning at the latest. Comments welcome; those who wish to comment on the Google Docs document can go to https://docs.google.com/a/google.com/presentation/d/1OfBO_UyxdFaey8R_cwd5Vo… and request access. Harald

3 2

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

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

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

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

Modular Congestion Control in rtcweb
by Luca De Cicco 29 Mar '12

29 Mar '12

Dear all, this mail follows a thread I've recently started at rtcweb(a)ietf.org. and moved to this mailing list following Harald's suggestion. Since congestion control is a fundamental building block for a multimedia communication framework such as webrtc, I think it makes sense to design the framework to allow using different congestion control algorithms such as it is done with audio/video codecs. Are there any plans to make the congestion control algorithm modular for multimedia transmission via PeerConnections? This would require the peers to select a particular congestion control algorithm at the establishment of the PeerConnection similarly to how the DCCP [1] protocol does at kernel level. Best regards, -- Luca De Cicco, PhD, Eng. Politecnico di Bari Dipartimento di Elettrotecnica ed Elettronica Via Re David, 200 - Bari - ITALY Office: +39 080 596 3851 Refs. [1] Datagram Congestion Control Protocol (DCCP), RFC 4340, http://tools.ietf.org/html/rfc4340

13 35

MulTFRC
by Michael Welzl 27 Mar '12

27 Mar '12

Hi, Since the TCP equation seems to be used in several places by this effort and there was some discussion about TFRC today, I thought I should remind people of the existence of MulTFRC. We have made an equation that gives you the throughput of N flows (where N can also be 0.3 or 2.9 or whatever...), and we plugged that into TFRC, leading to what we call MulTFRC. This has been published in a SIGCOMM poster, ACM CCR, a Ph.D. thesis, and now also in IEEE/ACM ToN. Everything about MulTFRC is collected here: http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html The draft: http://tools.ietf.org/html/draft-irtf-iccrg-multfrc has been reviewed by 3 reviewers, who all gave their okay, except for one reviewer who (quite rightfully!) insisted on us developing a fixed- point version of the mechanism. This has turned out to be much harder than we thought, and the draft has been dormant since. We're still on the case, and hope to be able to update it soon. MulTFRC doesn't make TFRC any more delay-friendly and hence probably won't solve any of the problems that people now seems to have with TFRC, but I felt that it could be worthwhile for this crowd to know that this equation, and this mechanism, exist. Cheers, Michael

1 0

A simple comment about draft-perkins-avtcore-rtp-circuit-breakers
by Michael Welzl 27 Mar '12

27 Mar '12

So this is supposed to be for severe situations only, i.e. we want to avoid a false positive... the draft says: The congestion circuit breaker is therefore: when RTCP RR packets are received, estimate the TCP throughput using the above equation and the measured R, p (approximated by the loss fraction), and s. Compare this with the actual sending rate. If the actual sending rate has been more than an order of magnitude greater than the throughput equation estimate for two or more RTCP reporting intervals, stop transmitting. (where "the above equation" is the TCP throughput equation) but in the presentation today, a statement about reacting when you have reached 10 * that value was made. This means that the stream would stop sending when it's as aggressive as 10 TCP flows... on a host where there can easily be many more flows than that active in parallel with the RTP stream, I wouldn't judge that as a "circuit breaker" condition. My simple suggestion is to pick a much higher value, say 100? Cheers, Michael

1 0