- Rtp-congestion - example.com

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

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