April 2012 - Rtp-congestion

Re: [R-C] [ledbat] LEDBAT vs RTCWeb
by Randell Jesup 30 Apr '12

30 Apr '12

On 4/26/2012 11:49 AM, Nicholas Weaver wrote: > On Apr 26, 2012, at 8:05 AM, Rolf Winter wrote: >>> http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf >>> >>> It seems like AQM causes LEDBAT to promote to behavior similar to TCP, >>> but with low delay. Since it still seems fair, this is ok, but it's no >>> longer a background or scavenger flow, and applications using it need >>> to be aware they can impact "foreground" flows if AQM is in play. >>> Perhaps applications need to be given awareness when LEDBAT detects >>> active AQM (if it can), and there's no "scavenger" CC algorithm for AQM >>> that I know of. >> And the document makes that clear and I am not sure LEDBAT actually can detect AQM. > One thought: Active Queue management will be either ECN or early drop. Which is a signal separate to the delay signal used which is "friendlier than TCP". > > In either case, the scavenger flow property might be, well, not fully maintained but at least encouraged by backing off more than conventional TCP would to the same signal. Correct, and that's a reasonable way to proceed - though it might complicate slightly (and certainly change) the LEDBAT competing with LEDBAT case. In my delay-sensitive CC algorithm, I detected drops, and in particular "fishy" drops where the end-to-end delay in the following packet was lower by roughly the normal arrival interval, and would take those as an indication that we should drop more substantially than 'normal'. This was targeted at tail-drop detection, especially congestion spikes, but for a scavenger protocol the same idea could apply to make it more responsive to AQM. Basically, for a scavenger protocol any drop is a warning that either you or someone else has pushed a queue up to tail-drop levels, or that AQM is in play. In either case you should back off, and if you back off more than TCP would, that that allows TCP to retain it's foreground advantage while not hurting scavenger performance (much?) when it competes with itself. It may want to use drops to develop an estimate of the bottleneck queue depth (if less than the target value), to help avoid triggering tail-drops when not competing with TCP. (I.e. a target of 100ms doesn't make sense if the bottleneck queue is 50ms deep - and you can consider AQM really the equivalent of a minimal-depth queue at the bottleneck.) Such an estimate (which would be near 0 for AQM) might let it properly handle AQM, which is an idea which might help in RRTCC as well. For those looking for the "RRTCC" (horrible name :-) draft, here's the latest: http://tools.ietf.org/html/draft-alvestrand-rtcweb-congestion-02 From: harald(a)alvestrand.no This is mainly a maintenance update. No changes to the algorithm, but reworded to show how it can be applied across multiple SSRCs at one time. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt Date: Wed, 25 Apr 2012 05:03:35 -0700 From: internet-drafts(a)ietf.org To: harald(a)alvestrand.no CC: holmer(a)google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 02 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2012-04-25 WG ID: Individual Submission Number of pages: 17 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. -- Randell Jesup randell-ietf(a)jesup.org

2 3

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

Fwd: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt
by Harald Alvestrand 25 Apr '12

25 Apr '12

This is mainly a maintenance update. No changes to the algorithm, but reworded to show how it can be applied across multiple SSRCs at one time. Harald -------- Original Message -------- Subject: New Version Notification for draft-alvestrand-rtcweb-congestion-02.txt Date: Wed, 25 Apr 2012 05:03:35 -0700 From: internet-drafts(a)ietf.org To: harald(a)alvestrand.no CC: holmer(a)google.com A new version of I-D, draft-alvestrand-rtcweb-congestion-02.txt has been successfully submitted by Harald Alvestrand and posted to the IETF repository. Filename: draft-alvestrand-rtcweb-congestion Revision: 02 Title: A Google Congestion Control Algorithm for Real-Time Communication on the World Wide Web Creation date: 2012-04-25 WG ID: Individual Submission Number of pages: 17 Abstract: This document describes two methods of congestion control when using real-time communications on the World Wide Web (RTCWEB); one sender- based and one receiver-based. It is published to aid the discussion on mandatory-to-implement flow control for RTCWEB applications; initial discussion is expected in the RTCWEB WG's mailing list. The IETF Secretariat

1 0

Admin: Old mail
by Harald Alvestrand 25 Apr '12

25 Apr '12

I've been remiss in cleaning out the spam filter on this list, and it had collected some defintely non-spam messages from non-subscribers. Apologies for the onslaught of old mail. Harald

1 0

Re: [R-C] [ledbat] LEDBAT vs RTCWeb
by Randell Jesup 25 Apr '12

25 Apr '12

On 4/24/2012 4:35 PM, Rolf Winter wrote: >> We know when faced with deep buffers and large loss-based flow, a delay >> flow will lose or have to transition to loss-based and live with delay >> (see Cx-TCP). We also know that in practice, the (residential) >> bottleneck links are almost always the access link (DSL, fiber, etc) or >> sometimes the WiFi connection. Corporate/educational can be a bit >> different, but there's a better chance of AQM or service-based traffic >> shaping there. >> >> We can deal (mostly) with fighting with TCP and expected it. We didn't >> expect scavenger protocols to be pumping the queues up when TCP is idle >> or bursty. > Here is where you lose me a bit. How do you "fight" TCP and its queue build-up exactly. I don't think we talk about protocols with the same design goals, are we. One of LEDBAT's design goals e.g. is to use all available bandwidth. Our (WebRTC/RRTCC's) primary constraints are to a) keep delay near 0, b) use a 'fair' share of bandwidth (all available if the other flows don't use all the available bandwidth). Low delay generally takes precedence over bandwidth, though eventually we hit a wall and can't reasonably reduce bandwidth more. The design goals are not identical to LEDBAT; but these protocols need to share the network "well" with each other and TCP (and inflexible UDP flows like classic VoIP). TCP is a given (unfortunately), and drop-tail routers with deep buffers are also a given (very unfortunately, especially with TCP). We can't stop TCP from grabbing all buffers; though there may be limited ability to "knock TCP back" some periodically when there are a small number of competing TCP flows, at the costs of delay bursts - but that probably isn't practical (a usable experience) for users. >> I note that LEDBAT is now in Linux and MacOS, so it's not just in >> application code anymore, and app developers (even OS developers) may >> assume it's safe to blindly use without user involvement. (And even if >> informed, assuming users understand the interaction of protocols is ... >> a stretch.) > And I think it is good that LEDBAT sees some deployment. It is an experimental congestion control algorithm. These experiments will provide us with good feedback and we might need to revisit some design decisions. There are millions of deployed LEDBAT-enabled clients out there and unfortunately the only thing we know about this "experiment" is that the experimenters have assured us that LEDBAT was deployed with "good success". Millions != experiments. This is wide-scale deployment, and implying it isn't is misleading (as will deployment of WebRTC). And implementation in core OS/X and Linux one assumes will lead to use by OS functions and applications such as cloud file backup, app update, etc. So if this "breaks" the network, we have a problem. >> Note that no routers are likely to recognize rtcweb traffic as VoIP >> since the signaling is opaque and application-dependant, so ALGs and >> the like have nothing to work against. It would have to 'guess' that >> the packet stream leading byte pattern and STUN/ICE traffic signified >> use of the port for VoIP. Eventually they may learn, but it will take >> years. >> >> I stand by the contention this is a real, significant problem which >> could get far worse if non-user-centric services start using LEDBAT. > Maybe, but the alternative protocol that these apps you describe above can use is TCP. I remain unconvinced that TCP makes the problem less severe than LEDBAT would. I think this is a false dichotomy, in that there are other choices for such applications, such as TFRC, RRTCC (which we're defining), TCP-Vegas(?), Cx-TCP (which in testing was ~20ms delay, but switches to loss-based fair sharing when faced with TCP - modifying it can probably lead to it dropping to low BW when competing) and for that matter LEDBAT itself (or a variant thereof) with different tunings. I believe RRTCC could cover a fair amount of of the goals of LEDBAT with alternate tunings, for example. Let me be clear: *if* widespread LEDBAT use, especially by "background"/non-user-visible apps will cause major disruption of VoIP flows on the net (and in particular for flows from within the same residence or enterprise), then there's a real problem with encouraging deployment. If it does not, then the issue is minor. I also believe that we do not know the answer to this question currently, though I believe the answer it is that it will cause significant delay and quality loss, and we have some evidence to that effect. Also (and I haven't checked this yet): how does LEDBAT respond to AQM? From telecom-paristech.fr: The experimental work in [ITC22] exploits instead a own implementation and points that LEDBAT may not work as expected (and actually might be needed) in case active queue management techniques AQM are applied in user modems (the study also suggests AQM to become a default practice in set-top-box devices) http://www.infres.enst.fr/~drossi/DATA/PRJ-Ledbat+AQM.pdf It seems like AQM causes LEDBAT to promote to behavior similar to TCP, but with low delay. Since it still seems fair, this is ok, but it's no longer a background or scavenger flow, and applications using it need to be aware they can impact "foreground" flows if AQM is in play. Perhaps applications need to be given awareness when LEDBAT detects active AQM (if it can), and there's no "scavenger" CC algorithm for AQM that I know of. -- Randell Jesup randell-ietf(a)jesup.org

2 2

Re: [R-C] [ledbat] LEDBAT vs RTCWeb
by Randell Jesup 24 Apr '12

24 Apr '12

On 4/23/2012 5:27 PM, Rolf Winter wrote: >> I searched the email archives and didn't see anything discussing it >> (though I might have missed it) or discussing interaction with VoIP >> (other than that one paper, which also showed the sensitivity to the >> allowed delay and the advantage of a user willing to accept longer >> delays, plus how latecomers could mis-read the buffer state. >> >> The problem is that a 100ms-delay-scavenger algorithm like this >> "poisons the well" for any application that desires/needs lower delay. >> That's why I believe there are only two reasonable targets: 0 (drained >> queues) and full queues (assuming AQM isn't implemented to keep queues >> low). > I think worrying about a poisoned well is a little late with loss-based congestion control being deployed. We know when faced with deep buffers and large loss-based flow, a delay flow will lose or have to transition to loss-based and live with delay (see Cx-TCP). We also know that in practice, the (residential) bottleneck links are almost always the access link (DSL, fiber, etc) or sometimes the WiFi connection. Corporate/educational can be a bit different, but there's a better chance of AQM or service-based traffic shaping there. We can deal (mostly) with fighting with TCP and expected it. We didn't expect scavenger protocols to be pumping the queues up when TCP is idle or bursty. >> I don't think this is just a theoretical problem, I think it's a very >> serious issue, which if LEDBAT gets used a lot will cause a lot of >> problems. Perhaps it's *better* than old-style saturating bittorrent >> flows, in that VoIP will be possible without shutting down bittorrent, >> but that doesn't mean it's good, and the perception that bittorrent >> doesn't break other apps with the new protocols will encourage people >> to leave it running - and depending on the vagaries of bittorrent, it >> might be fine when you start the call and then slam you. I'm >> especially worried about OS's and apps using it for background update >> transfers with no user control or knowledge, etc. > Well, this reads a bit too dramatic for my taste. Perhaps. But I think a fundamental "how does this affect the network" case was glossed over/ignored. > LEDBAT typically comes with the app so you're a bit more agile regarding the congestion control parameterization (and even the implementation as the BitTorrent folks have shown). I note that LEDBAT is now in Linux and MacOS, so it's not just in application code anymore, and app developers (even OS developers) may assume it's safe to blindly use without user involvement. (And even if informed, assuming users understand the interaction of protocols is ... a stretch.) > BTW, as long as update services do not use the uplink capacity of customers, I don't see much of a problem (assuming we agree that the biggest problem is home gateways). It's not just uplink, but also downlinks (though uplinks typically are the worst-configured). An update service for the OS or a large app can fill the downstream buffers with 100ms of packets, and then any incoming VoIP data is delayed with no real way to solve it until the update/download ends. In some cases that might be hours or even days. Other apps like cloud backup services might assume it's safe to use LEDBAT for their background transfers, and keep your upstream saturated at 100ms delay at all times. > Not sure how BITS compares in all of this either. In either case it beats TCP and that is used without the users' knowledge, too. The best you could probably do is design better home gateways which would solve many of the problems we see today (the better ones actually today implement traffic shaping with really good results, probably better than any end-to-end congestion control algorithm). Note that no routers are likely to recognize rtcweb traffic as VoIP since the signaling is opaque and application-dependant, so ALGs and the like have nothing to work against. It would have to 'guess' that the packet stream leading byte pattern and STUN/ICE traffic signified use of the port for VoIP. Eventually they may learn, but it will take years. I stand by the contention this is a real, significant problem which could get far worse if non-user-centric services start using LEDBAT. -- Randell Jesup randell-ietf(a)jesup.org

2 1

Re: [R-C] [ledbat] LEDBAT vs RTCWeb
by Randell Jesup 23 Apr '12

23 Apr '12

On 4/23/2012 8:07 AM, Rolf Winter wrote: > Hi, > > the way I remember how we got to the 100ms was a little different. We started out with 25 ms of extra delay and between version 01 and 02 of the WG draft I believe it "magically" changed. I remember asking about the motivation but I cannot recall an answer. My guess is that 25ms is very few packets in common residential broadband access networks and the algorithm might not quite work that well in those settings _today_. After some debate we ended up accepting 100 ms as a maximum. The problem is that going away from 100 ms in practice is that (assuming more than one app adopts LEDBAT congestion control) the one app that yields the most will get the least throughput, making anything less than 100 ms really unattractive in a competitive environment. So while I am personally OK with the compromise we achieved in the end, I am not happy about the lack of motivation. I am mildly optimistic that it is based on experience in the field rather than making the existing implementation at the tim > atch the spec. I searched the email archives and didn't see anything discussing it (though I might have missed it) or discussing interaction with VoIP (other than that one paper, which also showed the sensitivity to the allowed delay and the advantage of a user willing to accept longer delays, plus how latecomers could mis-read the buffer state. The problem is that a 100ms-delay-scavenger algorithm like this "poisons the well" for any application that desires/needs lower delay. That's why I believe there are only two reasonable targets: 0 (drained queues) and full queues (assuming AQM isn't implemented to keep queues low). I don't think this is just a theoretical problem, I think it's a very serious issue, which if LEDBAT gets used a lot will cause a lot of problems. Perhaps it's *better* than old-style saturating bittorrent flows, in that VoIP will be possible without shutting down bittorrent, but that doesn't mean it's good, and the perception that bittorrent doesn't break other apps with the new protocols will encourage people to leave it running - and depending on the vagaries of bittorrent, it might be fine when you start the call and then slam you. I'm especially worried about OS's and apps using it for background update transfers with no user control or knowledge, etc. -- Randell Jesup randell-ietf(a)jesup.org

3 2

LEDBAT vs RTCWeb
by Harald Alvestrand 20 Apr '12

20 Apr '12

Just to summarize what I currently understand about LEDBAT as compared to the scenario that RTCWEB envisions..... - RTCWEB assumes a set of media streams, possibly supplemented by a set of data streams carrying data with real-time requirements. LEDBAT assumes that there is some amount of data that needs transferring, and that it's appropriate to delay data if congestion occurs. - RTCWEB wants to make sure delay is low as long as it's not fighting with TCP, and wants its "fair share" when competing with TCP. LEDBAT wants to back off when encountering TCP, and uses low delay as a signal of "no competition is occuring"; it doesn't care about the specific delay. - RTCWEB's RTP streams consists of unidirectional streams with (currently) fairly infrequent feedback messages. LEDBAT assumes an acknowledgement stream with nearly the same packet intervals as the forward stream. My conclusion: When discussing behaviour of specific models, we can learn from LEDBAT's experiences and the scenarios it was tested in, but the design goals of LEDBAT do not resemble the design goals for congestion control in the RTCWEB scenario, and we should not expect specific properties of the implementation to fit. If I'm totally off base on any of the above, please holler..... Harald

10 36

Question about the problem with TFRC
by Michael Welzl 17 Apr '12

17 Apr '12

Hi, I noticed that TFRC is, well, unpopular here. I understand the reasons, in particular the group's desire to minimize buffering. So I'm not making a proposal here, just asking a question out of academic curiosity: is this just handwaving and assumptions, or have some people given it a try and found that it doesn't work well? Are there any documented results showing that? I think someone posted earlier on that there were poor experiences with TFRC; I'm just interested in more details about that. Again, I'm not proposing anything here, just interested for my own research. Cheers, Michael

6 7

A site for this activity
by Harald Alvestrand 16 Apr '12

16 Apr '12

In preparation for pushing forward a BOF request for Vancouver, I've started collecting some of the more interesting material from the list on a separate web site. Check out http://rtp-congestion.alvestrand.com/ (note the .com suffix), and tell me what's missing. Harald

1 0