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
Le 3 avr. 2012 à 13:36, Harald Alvestrand a écrit :
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:
Short summary:
- what it is
- A delay-based congestion control mechanism. - Designed to offer a "scavenger" / lower-than-best-effort service for bulk data. - Sending rate (*) is adapted as a function of changes in the (forward path) one-way delay; the goal is to try to keep e2e delay below a pre-determined threshold. (*) Well, in fact it is a window-based mechanism (like TCP's), but (different from TCP) it uses delays to drive the congestion window up and down.
- where it's at in its talk/develop/deploy/learn ycle
- Currently deployed in BitTorrent clients (it's been so for a while now): http://www.bittorrent.org/beps/bep_0029.html - It has been implemented in MacOS X too: http://opensource.apple.com/source/xnu/xnu-1699.22.81/bsd/netinet/tcp_ledbat... . There may be other implementations, but I can't recall now. - On the IETF side, the draft was "finished" & handed to the IESG last fall, IIRC.
- what the core properties are?
- It tries to (a) keep small standing queues while grabbing as much bandwidth as possible, (b) be as little "intrusive" to competing TCP flows as possible, by yielding when delay increases and by being less aggressive that TCP in grabbing extra bandwidth. - In case of loss (or ECN marks), it behaves like TCP. HTH, David. PS: I have a longer summary, but I tried to keep this short as requested :-) ================================================================= David ROS http://www.rennes.enst-bretagne.fr/~dros/ Deadlines really start to press a week or two after they pass. -- John Perry
On 2012-04-03 15:06, David Ros wrote:
David.
PS: I have a longer summary, but I tried to keep this short as requested :-)
I am interested on your longer summary and perhaps you can educate us about the application of LEDBAT CC algorithm to real-time media specially on this note "by yielding when delay increases and by being less aggressive that TCP in grabbing extra bandwidth".
-- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER M.Sc. Experienced Researcher Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================
On Apr 4, 2012, at 12:56 PM, eemeaesarzah wrote:
On 2012-04-03 15:06, David Ros wrote:
David.
PS: I have a longer summary, but I tried to keep this short as requested :-)
I am interested on your longer summary and perhaps you can educate us about the application of LEDBAT CC algorithm to real-time media specially on this note "by yielding when delay increases and by being less aggressive that TCP in grabbing extra bandwidth".
to answer that bit, let me quote from my own previous email describing LEDBAT: "it's one out of many mechanism that use delay (as a result of increasing queue length) as an earlier indication of congestion. without adding a mechanism like that "use the TCP equation as a lower limit" or something like that, reacting earlier than standard TCP makes you less aggressive - and this is what LEDBAT was designed to be: a mechanism that "gives way" to TCP, making itself suitable for background scavenger-like traffic." I don't think anybody advocated using LEDBAT as it is here. But personally, I would favor "adjusting" LEDBAT by e.g. adding the "TCP equation as a lower limit" trick (which I think is neat!) and tuning its parameters over having a from-scratch design of a new delay-based mechanism. LEDBAT has already undergone some investigation, and so we'd have a more stable basis. Cheers, Michael
There is one especially useful design point to extract here..... I believe that by default ledbat has a 50mS set point. That is, it regulates its rate/window size by sensing if the one way queue time seems to be above or below 50mS. Would this be acceptable for RTCweb, or would it be necessary to choose some other set point? (BTW, Ledbat makes no claims about fairness, etc., just that it can consume most of an otherwise under-filled network.) Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Thu, Apr 5, 2012 at 4:53 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
On Apr 4, 2012, at 12:56 PM, eemeaesarzah wrote:
On 2012-04-03 15:06, David Ros wrote:
David.
PS: I have a longer summary, but I tried to keep this short as requested :-)
I am interested on your longer summary and perhaps you can educate us
about the application of LEDBAT CC algorithm to real-time media specially on this note "by yielding when delay increases and by being less aggressive that TCP in grabbing extra bandwidth".
to answer that bit, let me quote from my own previous email describing LEDBAT:
"it's one out of many mechanism that use delay (as a result of increasing queue length) as an earlier indication of congestion. without adding a mechanism like that "use the TCP equation as a lower limit" or something like that, reacting earlier than standard TCP makes you less aggressive - and this is what LEDBAT was designed to be: a mechanism that "gives way" to TCP, making itself suitable for background scavenger-like traffic."
I don't think anybody advocated using LEDBAT as it is here. But personally, I would favor "adjusting" LEDBAT by e.g. adding the "TCP equation as a lower limit" trick (which I think is neat!) and tuning its parameters over having a from-scratch design of a new delay-based mechanism. LEDBAT has already undergone some investigation, and so we'd have a more stable basis.
Cheers, Michael
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
On Apr 6, 2012, at 1:45 AM, Matt Mathis wrote:
There is one especially useful design point to extract here.....
I believe that by default ledbat has a 50mS set point. That is, it regulates its rate/window size by sensing if the one way queue time seems to be above or below 50mS.
Would this be acceptable for RTCweb, or would it be necessary to choose some other set point?
Good question; I guess you don't want to have a set point at all and back off as soon as delay increases? - but that may be hard when trying to get some bandwidth in competition with standard TCP; actually, how much bandwidth you would get with any such fixed point (yes, including the value 0 !) would depend on the queue length at the bottleneck, which is not under your control. e.g., if the queue >= BDP, it becomes an unavoidable trade-off between acceptable delay and achievable bandwidth. Then, maybe the right thing would really be to make that a knob for the user? Of course, if you assume that your traffic is somehow isolated, as you wrote in previously posted text, you don't need to worry about that; and your assumption, as you also wrote in a recent email, is basically that users would then stop running any other traffic. That would however mean that we might end up developing a very-low-delay system that simply cannot work when anything else is going on. As a user, I'd rather have a knob for that (and I'm not into user interfaces with bells and whistles, mind you :-) but that can be one simple, yet important knob).
(BTW, Ledbat makes no claims about fairness, etc., just that it can consume most of an otherwise under-filled network.)
In my post answering Harald's query, I mentioned this link, where there's a number of papers analyzing LEDBAT: http://perso.telecom-paristech.fr/~drossi/index.php?n=Software.LEDBAT in particular, this one identifies the "latecomer unfairness" problem exhibited by LEDBAT: http://perso.telecom-paristech.fr/~drossi/paper/rossi10globecom-a.pdf I'm not sure if this has then been fixed in the standard, but in my review of draft-alvestrand-rtcweb-congestion: http://www.alvestrand.no/pipermail/rtp-congestion/2012-March/000176.html I mentioned that I'd be concerned about problems like that. To quote the first paragraph of that review: *** 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? *** => my point is not that LEDBAT solves all these problems - I don't know if it does, anyway it would have to be tuned for RTCWEB because it is designed to be *less aggressive* than standard TCP. My point was that we should consider such existing mechanisms as a basis for delay- sensitive schemes rather than conjuring up a totally new and entirely different scheme out of the blue. Note that I only mentioned LEDBAT because that one is undergoing IETF standardization and should therefore have some acceptance here ... this is by no means the only delay-sensitive congestion control, the literature is full of them (Vegas, FAST, CTCP, TCP Illinois and (a variant of) H-TCP, to name but a few). One thing that makes the RTCWEB use different is the non-greedy use that you have described in your text - but really I don't think that this requires building a whole new mechanism, it may just need a departure from the conservative approach that was taken with TCP under these circumstances. So this is a "let's not be so conservative here" design decision, which could probably be applied as a way of adapting an existing controller. Cheers, Michael
On 04/06/2012 01:45 AM, Matt Mathis wrote:
There is one especially useful design point to extract here.....
I believe that by default ledbat has a 50mS set point. That is, it regulates its rate/window size by sensing if the one way queue time seems to be above or below 50mS. That is - 50 ms more than the baseline (lowest observed) RTT? 50 ms absolute would make no sense, since intercontinental conferencing has a longer baseline RTT.
Would this be acceptable for RTCweb, or would it be necessary to choose some other set point? I generally don't like set-points, since they tend to make behaviour converge on the set-point. Sliding scales like the Kalmann filter of Stefan's proposal make more sense to me.
That said, 50 ms seems a little on the high side, given that our total RTT budget is being attacked from all sorts of directions, but not order-of-magnitude wrong.
On Apr 6, 2012, at 10:13 AM, Harald Alvestrand wrote:
On 04/06/2012 01:45 AM, Matt Mathis wrote:
There is one especially useful design point to extract here.....
I believe that by default ledbat has a 50mS set point. That is, it regulates its rate/window size by sensing if the one way queue time seems to be above or below 50mS. That is - 50 ms more than the baseline (lowest observed) RTT? 50 ms absolute would make no sense, since intercontinental conferencing has a longer baseline RTT.
Would this be acceptable for RTCweb, or would it be necessary to choose some other set point? I generally don't like set-points, since they tend to make behaviour converge on the set-point. Sliding scales like the Kalmann filter of Stefan's proposal make more sense to me.
To take a short point out of my previous, maybe too long email: depending on the queue length, which is not under your control, saying "I want 0 delay on top of the baseline" may mean that you'd only get a very small amount of bandwidth. One possibility would be to make that trade-off a knob for the user. Another one is to let the "at least as much as the TCP equation dictates" rule in Stefan's proposal take care of that, but then you don't really know how much delay you'll get... e.g., maybe users could even live with less bandwidth than what the TCP equation dictates, as long as the delay is smaller? I think that's not an option with the currently proposed scheme. Cheers, Michael
And I think you are missing my big point: delays sensing does not work for general purpose congestion control, due to known stability and fairness problems. Unless the scope of the RTCweb problem is somewhat narrowed, it is guaranteed to fail, because the larger problem is already known to be intractable. The 50k meter view: Applications that are expecting to use RTC web need a bound on the queuing delay. We (the WG) have to assume some sort of bound on other traffic (delay or loss sensing) that might be sharing the same bottleneck queue. If we don't assume some bound on other traffic, it is self evident that RTCweb can not possibly guarantee the bound on the delay. Period. There is nothing complicated or subtle here. And the user will know very clearly when the network fails to meet it. It would help move the Internet forward for the RTCweb WG to point out to the rest of the community that QoS like technologies can solve the queue sharing problems. However, specifying any of these details are clearly out of scope for RTCweb. My earlier long message was an attempt at explicitly narrowing the scope to make the problem tractable. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay On Fri, Apr 6, 2012 at 1:25 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
<snip>
To take a short point out of my previous, maybe too long email: depending on the queue length, which is not under your control, saying "I want 0 delay on top of the baseline" may mean that you'd only get a very small amount of bandwidth.
One possibility would be to make that trade-off a knob for the user. Another one is to let the "at least as much as the TCP equation dictates" rule in Stefan's proposal take care of that, but then you don't really know how much delay you'll get... e.g., maybe users could even live with less bandwidth than what the TCP equation dictates, as long as the delay is smaller? I think that's not an option with the currently proposed scheme.
Cheers, Michael
On Apr 6, 2012, at 7:52 PM, Matt Mathis wrote:
And I think you are missing my big point: delays sensing does not work for general purpose congestion control, due to known stability and fairness problems. Unless the scope of the RTCweb problem is somewhat narrowed, it is guaranteed to fail, because the larger problem is already known to be intractable.
The 50k meter view: Applications that are expecting to use RTC web need a bound on the queuing delay.
We (the WG) have to assume some sort of bound on other traffic (delay or loss sensing) that might be sharing the same bottleneck queue.
If we don't assume some bound on other traffic, it is self evident that RTCweb can not possibly guarantee the bound on the delay. Period. There is nothing complicated or subtle here.
And the user will know very clearly when the network fails to meet it.
It would help move the Internet forward for the RTCweb WG to point out to the rest of the community that QoS like technologies can solve the queue sharing problems. However, specifying any of these details are clearly out of scope for RTCweb.
My earlier long message was an attempt at explicitly narrowing the scope to make the problem tractable. Hi Matt,
let us consider an RTCWeb connection. It is clear that other traffic has an influence on the RTCWeb connection and that it is hard to deal with it. But the RTCWeb connection possibly consists on several media flows and one non-media flow (maybe multiple). How the RTCWeb connection shares its bandwidth between the media and non-media flows is something that might be tractable. To be more concrete: I think we should consider the case where on RTCWeb connections consists of a media flow and an non-media flow. It would be good if the non-media flow doesn't drive the media flow useless. Do you agree on this? In this particular example, wouldn't it make sense to consider a LEDBAT like CC for the non-media flow if the suer agrees that the media is more important for him than the non-media? LEDBAT is just an example. Maybe another CC is more appropriate. Best regards Michael
Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay
On Fri, Apr 6, 2012 at 1:25 AM, Michael Welzl <michawe@ifi.uio.no> wrote:
<snip>
To take a short point out of my previous, maybe too long email: depending on the queue length, which is not under your control, saying "I want 0 delay on top of the baseline" may mean that you'd only get a very small amount of bandwidth.
One possibility would be to make that trade-off a knob for the user. Another one is to let the "at least as much as the TCP equation dictates" rule in Stefan's proposal take care of that, but then you don't really know how much delay you'll get... e.g., maybe users could even live with less bandwidth than what the TCP equation dictates, as long as the delay is smaller? I think that's not an option with the currently proposed scheme.
Cheers, Michael
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
Hi, So there are a few convoluted things here: 1) Matt wants to have a statement that says that we assume that RTCweb traffic is somehow isolated from other traffic. I don't think that this statement is useful, but I see Matt's point and I'm generally in favor of narrow scopes too, so I don't have a strong opinion about it and we can stop discussing that bit. It's fine if it stays. 2) The above assumes that the notion of "RTCweb traffic" includes media- and non-media traffic. If you're idea is to say that we should ignore non-media *RTCweb* traffic by assuming that it will somehow be isolated from RTCweb media traffic, then I am very strongly against that and would call it a very bad idea. Because we're in control of both, and simply don't want one to hurt the other! Some more details in line below: On Apr 7, 2012, at 10:40 AM, Michael Tuexen wrote:
On Apr 6, 2012, at 7:52 PM, Matt Mathis wrote:
And I think you are missing my big point: delays sensing does not work for general purpose congestion control, due to known stability and fairness problems. Unless the scope of the RTCweb problem is somewhat
If your goal for that "isolation" paragraph is 1) above, not 2), then what you and I think about delay sensing for congestion control probably doesn't matter much in the context of this discussion. If this is your argument for 2), then yes, it does! Anyway, here's my opinion about that statement: 1) what is the basis for saying that delay sensing does not work for general purpose congestion control? Do you have any evidence for that? (yes, there is counter-evidence; operational experience with LEDBAT in BitTorrent, to name but one) 2) stability => there would be a number of well done papers disagreeing with that. 3) fairness => I think the fairness problems (typically the "late- comer" problem) are known, can be overcome, and in the end, the finer grain feedback signal allows you to have much better control over fairness than what you get with e.g. TCP's horrible pseudo-fairness. 4) without relying on delay, exactly how do you plan to minimize queuing delay? 5) you ARE aware that draft-alvestrand-rtcweb-congestion is delay-based?
narrowed, it is guaranteed to fail, because the larger problem is already known to be intractable.
The 50k meter view: Applications that are expecting to use RTC web need a bound on the queuing delay.
I'd replace "need" with "want" and change what you write below on that basis, but this is the part that I don't have a strong opinion about.
We (the WG) have to assume some sort of bound on other traffic (delay or loss sensing) that might be sharing the same bottleneck queue.
If we don't assume some bound on other traffic, it is self evident that RTCweb can not possibly guarantee the bound on the delay. Period. There is nothing complicated or subtle here.
And the user will know very clearly when the network fails to meet it.
It would help move the Internet forward for the RTCweb WG to point out to the rest of the community that QoS like technologies can solve the queue sharing problems. However, specifying any of these details are clearly out of scope for RTCweb.
My earlier long message was an attempt at explicitly narrowing the scope to make the problem tractable. Hi Matt,
let us consider an RTCWeb connection. It is clear that other traffic has an influence on the RTCWeb connection and that it is hard to deal with it. But the RTCWeb connection possibly consists on several media flows and one non-media flow (maybe multiple). How the RTCWeb connection shares its bandwidth between the media and non-media flows is something that might be tractable. To be more concrete: I think we should consider the case where on RTCWeb connections consists of a media flow and an non-media flow. It would be good if the non-media flow doesn't drive the media flow useless. Do you agree on this? In this particular example, wouldn't it make sense to consider a LEDBAT like CC for the non-media flow if the suer agrees that the media is more important for him than the non-media? LEDBAT is just an example. Maybe another CC is more appropriate.
I agree with everything Michael says here. And as an additional thought, in this example of a greedy data flow, if the user prioritizes the non-greedy step-function based media traffic, using only one congestion control for both mechanisms would make that only ONE greedy flow, and the bandwidth between them decided by scheduling. You end up having no competition for bandwidth between media and non-media traffic, just one flow that's greedy yet trying to keep the queue minimal. There are TCP's that can do that. I just cannot see how having two separate congestion controls competing here could do a better job at minimizing delay. All that could be achieved by using only one single congestion control mechanism for all RTCweb streams, and make that sensitive to delay, and (*only* for the case that there is no RTCweb data traffic) let it work well with non-greedy-senders. Cheers, Michael
Hi Harald, I think there's some misunderstanding here. 1. ledbat is using qeueing delay, not the base rtt, the queuing delay is relative_owd - relative_base_owd, and clock skew is removed. 2. I mentioned ledbat here for i think there's simpler way to get the queuing delay as a hint for congestion, and can be used for give estimation of bandwidth. Thanks Jeromy 2012/4/6 Harald Alvestrand <harald@alvestrand.no>
On 04/06/2012 01:45 AM, Matt Mathis wrote:
There is one especially useful design point to extract here.....
I believe that by default ledbat has a 50mS set point. That is, it regulates its rate/window size by sensing if the one way queue time seems to be above or below 50mS.
That is - 50 ms more than the baseline (lowest observed) RTT? 50 ms absolute would make no sense, since intercontinental conferencing has a longer baseline RTT.
Would this be acceptable for RTCweb, or would it be necessary to choose some other set point?
I generally don't like set-points, since they tend to make behaviour converge on the set-point. Sliding scales like the Kalmann filter of Stefan's proposal make more sense to me.
That said, 50 ms seems a little on the high side, given that our total RTT budget is being attacked from all sorts of directions, but not order-of-magnitude wrong.
______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
On 4/5/2012 7:45 PM, Matt Mathis wrote:
There is one especially useful design point to extract here.....
I believe that by default ledbat has a 50mS set point. That is, it regulates its rate/window size by sensing if the one way queue time seems to be above or below 50mS.
Would this be acceptable for RTCweb, or would it be necessary to choose some other set point?
Actually, the original -00 draft suggested a 25ms TARGET (for queuing delay, not RTT or even OWD (one-way delay). The original draft also considered queuing delay's effect on realtime media streams it would be in competition with and the 150ms mouth-to-ear delay required for high-quality interactive audio. The current LEDBAT draft uses 100ms TARGET, which is well beyond what will generally work well for competing interactive media streams. This also makes me VERY concerned with LEDBAT's fairness (not in bandwidth, but in delay) to competing interactive media flows, both inflexible ones (typical UDP VoIP using fixed-rate codecs like G.711, G.729, etc), and delay-sensing adaptive flows such as harald's draft we're considering here. Does anyone know why consideration for competing VoIP flows was dropped from LEDBAT? I also note discussion on non-infinite sources (paced send, such as used in media flows) was also dropped.
(BTW, Ledbat makes no claims about fairness, etc., just that it can consume most of an otherwise under-filled network.)
under-filled by TCP yes; it may be overly aggressive against VoIP flows (I worry). -- Randell Jesup randell-ietf@jesup.org
On 2012-04-05 13:53, Michael Welzl wrote:
I don't think anybody advocated using LEDBAT as it is here. But personally, I would favor "adjusting" LEDBAT by e.g. adding the "TCP equation as a lower limit" trick (which I think is neat!) and tuning its parameters over having a from-scratch design of a new delay-based mechanism. LEDBAT has already undergone some investigation, and so we'd have a more stable basis.
I am sure LEDBAT CC algorithm has gone through strict examination and serves its purpose but as pointed out by others (Jim) those were not related to real-time interactive media. LEDBAT CC algorithm is window based (Congestion window) that is one extra queue at the sender side. I think Magnus Westerlund has already pointed out the possible issues with this kind of design in another mail. The path of fine tuning of LEDBAT may not be as smooth as one think. BR -- Zahed ============================================ ANM ZAHEDUZZAMAN SARKER Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================
is someone trying rate-based control? On Wed, Apr 11, 2012 at 1:39 PM, Zaheduzzaman Sarker < zaheduzzaman.sarker@ericsson.com> wrote:
On 2012-04-05 13:53, Michael Welzl wrote:
I don't think anybody advocated using LEDBAT as it is here. But personally, I would favor "adjusting" LEDBAT by e.g. adding the "TCP equation as a lower limit" trick (which I think is neat!) and tuning its parameters over having a from-scratch design of a new delay-based mechanism. LEDBAT has already undergone some investigation, and so we'd have a more stable basis.
I am sure LEDBAT CC algorithm has gone through strict examination and serves its purpose but as pointed out by others (Jim) those were not related to real-time interactive media.
LEDBAT CC algorithm is window based (Congestion window) that is one extra queue at the sender side. I think Magnus Westerlund has already pointed out the possible issues with this kind of design in another mail.
The path of fine tuning of LEDBAT may not be as smooth as one think.
BR
-- Zahed
==============================**============== ANM ZAHEDUZZAMAN SARKER
Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.**com <zaheduzzaman.sarker@ericsson.com> www.ericsson.com ==============================**============== ______________________________**_________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it http://c3lab.poliba.it ================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden.
On 11 Apr 2012, at 13:11, Saverio Mascolo wrote:
is someone trying rate-based control?
Google's proposal is essentially rate based.
On Wed, Apr 11, 2012 at 1:39 PM, Zaheduzzaman Sarker <zaheduzzaman.sarker@ericsson.com> wrote:
On 2012-04-05 13:53, Michael Welzl wrote:
I don't think anybody advocated using LEDBAT as it is here. But personally, I would favor "adjusting" LEDBAT by e.g. adding the "TCP equation as a lower limit" trick (which I think is neat!) and tuning its parameters over having a from-scratch design of a new delay-based mechanism. LEDBAT has already undergone some investigation, and so we'd have a more stable basis. I am sure LEDBAT CC algorithm has gone through strict examination and serves its purpose but as pointed out by others (Jim) those were not related to real-time interactive media.
As far as I understand avoiding upset of Voip flows was explicitly something LEDBAT aimed at - it is mentioned both in the Charter and specifically in section 4.3 of the LEDBAT draft - it aims to keep below the ITU's G.114 recommendation of 150ms. There are some studies done here - where LEDBAT does allow voip flows to operate - referenced in the draft (but there is more work to be done in this area): [Sch10] Schneider, J., Wagner, J., Winter, R., and H. Kolbe, "Out of my Way -- Evaluating Low Extra Delay Background Transport in an ADSL Access Network", Proceedings of 22nd International Teletraffic Congress (ITC22), September 2010. Though this paper brings up an additional active component which hasn't really surfaced much in these discussions - the 'Advanced Home Gateway' which typically provides for AQM (which could answer some of Jim's prayers ;) - often in the form of WFQ with multiple classes (which is the case the UK where a substantial number of home gateways are now shipped 'for free' with ADSL and come preconfigured with WFQ). Though these have a curious effect on LEDBAT flows and can serve to increase the priority of the LEDBAT flows and thus increasing their impact somewhat (though this effect is down to actual HGW classification of LEDBAT flows). I'm curious if any large providers have any stats on the deployment of these boxes and their experience of impact on differing traffic types....?
LEDBAT CC algorithm is window based (Congestion window) that is one extra queue at the sender side. I think Magnus Westerlund has already pointed out the possible issues with this kind of design in another mail.
The fact that it is window based doesn't preclude Magnus' suggestions - it is a question of whether the algorithm allows for low latency operation and potentially coping with bursts. If it can only clock out packets on ACKs then it may be problem but there are paced versions of window based algorithms that may suit.
The path of fine tuning of LEDBAT may not be as smooth as one think.
Yes it may be tricky - if LEDBAT wants an algorithm that can be dropped into TCP implementations. Piers
BR
-- Zahed
============================================ ANM ZAHEDUZZAMAN SARKER
Ericsson AB Multimedia Technologies (MMT) Ericsson Research P.O. Box 920, SE-971 28, Luleå, Sweden Phone +46 10 717 37 43 Fax +46 920 996 21 SMS/MMS +46 76 115 37 43 zaheduzzaman.sarker@ericsson.com www.ericsson.com ============================================ _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
-- Prof. Saverio Mascolo Dipartimento di Elettrotecnica ed Elettronica Politecnico di Bari Via Orabona 4, 70125 Bari Italy Tel. +39 080 5963621 Fax. +39 080 5963410 email:mascolo@poliba.it
================================= This message may contain confidential and/or legally privileged information. If you are not the intended recipient of the message, please destroy it. Any unauthorized dissemination, distribution, or copying of the material in this message, and any attachments to the message, is strictly forbidden. _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 4/11/2012 10:18 AM, Piers O'Hanlon wrote:
I am sure LEDBAT CC algorithm has gone through strict examination and serves its purpose but as pointed out by others (Jim) those were not related to real-time interactive media.
As far as I understand avoiding upset of Voip flows was explicitly something LEDBAT aimed at - it is mentioned both in the Charter and specifically in section 4.3 of the LEDBAT draft - it aims to keep below the ITU's G.114 recommendation of 150ms. There are some studies done here - where LEDBAT does allow voip flows to operate - referenced in the draft (but there is more work to be done in this area):
[Sch10] Schneider, J., Wagner, J., Winter, R., and H. Kolbe, "Out of my Way -- Evaluating Low Extra Delay Background Transport in an ADSL Access Network", Proceedings of 22nd International Teletraffic Congress (ITC22), September 2010.
This shows a VoIP flow increased 35ms for a 25ms LEDBAT. One assumes a 100ms LEDBAT would delay VoIP >100ms, and when you count other delays you're probably already over 150ms mouth->ear even on a good, local call.
Though this paper brings up an additional active component which hasn't really surfaced much in these discussions - the 'Advanced Home Gateway' which typically provides for AQM (which could answer some of Jim's prayers ;) - often in the form of WFQ with multiple classes (which is the case the UK where a substantial number of home gateways are now shipped 'for free' with ADSL and come preconfigured with WFQ)
This points out that rtcweb flows will probably not be automatically classified as realtime flows to be given priority; we should look into this and what they use as triggers, and how we can get them to rev their firmware (especially for future designs).
LEDBAT CC algorithm is window based (Congestion window) that is one extra queue at the sender side. I think Magnus Westerlund has already pointed out the possible issues with this kind of design in another mail.
The fact that it is window based doesn't preclude Magnus' suggestions - it is a question of whether the algorithm allows for low latency operation and potentially coping with bursts. If it can only clock out packets on ACKs then it may be problem but there are paced versions of window based algorithms that may suit.
The article mentioned their implementation doesn't do pacing but implied it was allowed. -- Randell Jesup randell-ietf@jesup.org
On 11 Apr 2012, at 21:02, Randell Jesup wrote:
On 4/11/2012 10:18 AM, Piers O'Hanlon wrote:
I am sure LEDBAT CC algorithm has gone through strict examination and serves its purpose but as pointed out by others (Jim) those were not related to real-time interactive media.
As far as I understand avoiding upset of Voip flows was explicitly something LEDBAT aimed at - it is mentioned both in the Charter and specifically in section 4.3 of the LEDBAT draft - it aims to keep below the ITU's G.114 recommendation of 150ms. There are some studies done here - where LEDBAT does allow voip flows to operate - referenced in the draft (but there is more work to be done in this area):
[Sch10] Schneider, J., Wagner, J., Winter, R., and H. Kolbe, "Out of my Way -- Evaluating Low Extra Delay Background Transport in an ADSL Access Network", Proceedings of 22nd International Teletraffic Congress (ITC22), September 2010.
This shows a VoIP flow increased 35ms for a 25ms LEDBAT. One assumes a 100ms LEDBAT would delay VoIP >100ms, and when you count other delays you're probably already over 150ms mouth->ear even on a good, local call.
Agreed 100ms is pretty tight. It seems that the focus on LEDBAT has been about testing with TCP, whilst it seems little work has been done with lower latency applications....
Though this paper brings up an additional active component which hasn't really surfaced much in these discussions - the 'Advanced Home Gateway' which typically provides for AQM (which could answer some of Jim's prayers ;) - often in the form of WFQ with multiple classes (which is the case the UK where a substantial number of home gateways are now shipped 'for free' with ADSL and come preconfigured with WFQ)
This points out that rtcweb flows will probably not be automatically classified as realtime flows to be given priority; we should look into this and what they use as triggers, and how we can get them to rev their firmware (especially for future designs).
In the box I have access to (which is pretty typical for the UK and maybe europe as it's made by Thomson/Technicolor) - it mostly has a bunch of port and DSCP based classifiers. I have seen boxes that have Signalling protocol sniffers in them for SIP/H323 and but I'm not sure about ICE (Which could be handy in RTCweb). These boxes are also mostly configured to be remotely configured and updated usually using the CPE WAN Management Protocol (CWMP)/TR-069.
LEDBAT CC algorithm is window based (Congestion window) that is one extra queue at the sender side. I think Magnus Westerlund has already pointed out the possible issues with this kind of design in another mail.
The fact that it is window based doesn't preclude Magnus' suggestions - it is a question of whether the algorithm allows for low latency operation and potentially coping with bursts. If it can only clock out packets on ACKs then it may be problem but there are paced versions of window based algorithms that may suit.
The article mentioned their implementation doesn't do pacing but implied it was allowed.
-- Randell Jesup randell-ietf@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
On 12 avr. 2012, at 00:41, Piers O'Hanlon wrote:
On 11 Apr 2012, at 21:02, Randell Jesup wrote:
On 4/11/2012 10:18 AM, Piers O'Hanlon wrote:
I am sure LEDBAT CC algorithm has gone through strict examination and serves its purpose but as pointed out by others (Jim) those were not related to real-time interactive media.
As far as I understand avoiding upset of Voip flows was explicitly something LEDBAT aimed at - it is mentioned both in the Charter and specifically in section 4.3 of the LEDBAT draft - it aims to keep below the ITU's G.114 recommendation of 150ms. There are some studies done here - where LEDBAT does allow voip flows to operate - referenced in the draft (but there is more work to be done in this area):
[Sch10] Schneider, J., Wagner, J., Winter, R., and H. Kolbe, "Out of my Way -- Evaluating Low Extra Delay Background Transport in an ADSL Access Network", Proceedings of 22nd International Teletraffic Congress (ITC22), September 2010.
This shows a VoIP flow increased 35ms for a 25ms LEDBAT. One assumes a 100ms LEDBAT would delay VoIP >100ms, and when you count other delays you're probably already over 150ms mouth->ear even on a good, local call.
Agreed 100ms is pretty tight. It seems that the focus on LEDBAT has been about testing with TCP, whilst it seems little work has been done with lower latency applications....
FWIW, the LEDBAT draft talks only (sec. 4.3) about "anecdotal evidence" about a target delay <= 100 ms (and the whole mechanism not harming VoIP flows?) "working well". Also FWIW, I just checked very quickly the full list of papers on LEDBAT we went through when writing RFC 6297 -- in all, about a dozen documents (including the one you mentioned before) and it would seem that, save for the paper you mentioned, no one *actually* studied *explicitly* the interaction of LEDBAT with VoIP. The focus is either LEDBAT vs. TCP or LEDBAT vs. LEDBAT. So yes, IMHO there is definitely more work to be done in this area. Regards, David.
Though this paper brings up an additional active component which hasn't really surfaced much in these discussions - the 'Advanced Home Gateway' which typically provides for AQM (which could answer some of Jim's prayers ;) - often in the form of WFQ with multiple classes (which is the case the UK where a substantial number of home gateways are now shipped 'for free' with ADSL and come preconfigured with WFQ)
This points out that rtcweb flows will probably not be automatically classified as realtime flows to be given priority; we should look into this and what they use as triggers, and how we can get them to rev their firmware (especially for future designs).
In the box I have access to (which is pretty typical for the UK and maybe europe as it's made by Thomson/Technicolor) - it mostly has a bunch of port and DSCP based classifiers. I have seen boxes that have Signalling protocol sniffers in them for SIP/H323 and but I'm not sure about ICE (Which could be handy in RTCweb). These boxes are also mostly configured to be remotely configured and updated usually using the CPE WAN Management Protocol (CWMP)/TR-069.
LEDBAT CC algorithm is window based (Congestion window) that is one extra queue at the sender side. I think Magnus Westerlund has already pointed out the possible issues with this kind of design in another mail.
The fact that it is window based doesn't preclude Magnus' suggestions - it is a question of whether the algorithm allows for low latency operation and potentially coping with bursts. If it can only clock out packets on ACKs then it may be problem but there are paced versions of window based algorithms that may suit.
The article mentioned their implementation doesn't do pacing but implied it was allowed.
-- Randell Jesup randell-ietf@jesup.org _______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
_______________________________________________ Rtp-congestion mailing list Rtp-congestion@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtp-congestion
================================================================= David ROS http://www.rennes.enst-bretagne.fr/~dros/ "It would seem that you have no useful skill or talent whatsoever," he said. "Have you thought of going into teaching?" -- Terry Pratchett
Please, anybody, correct me - here's my personal view, in line: On Apr 3, 2012, at 1:36 PM, Harald Alvestrand wrote:
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
it's one out of many mechanism that use delay (as a result of increasing queue length) as an earlier indication of congestion. without adding a mechanism like that "use the TCP equation as a lower limit" or something like that, reacting earlier than standard TCP makes you less aggressive - and this is what LEDBAT was designed to be: a mechanism that "gives way" to TCP, making itself suitable for background scavenger-like traffic. RFC 6297 is a survey of other, similar mechanisms.
- where it's at in its talk/develop/deploy/learn ycle
Regarding the state of the WG's development, the mechanism itself, it seems pretty much finished; details here: http://www.ietf.org/mail-archive/web/ledbat/current/msg00557.html Regarding experiences with the mechanism, an earlier variant of LEDBAT has been deployed by BitTorrent (the company, I think), and hence widely used and tested. Mirja Kuehlewind, one of the authors of the draft, has a paper about it in her publication list: http://www.ikr.uni-stuttgart.de/~mkuehle/XRDTabSelect=PUBS The group of Dario Rossi has carried out a larger number of experiments: http://perso.telecom-paristech.fr/~drossi/index.php?n=Software.LEDBAT and someone from Apple recently posted some (positive looking) test results to the list.
- what the core properties are?
It's good at giving way to TCP in its presence, and good at saturating a link in its absence, I think. At least that was the design goal - I guess the references above will tell you how good or bad it is at reaching its goal. Cheers, Michael
On 04/03/2012 07:36 AM, Harald Alvestrand wrote:
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?
I'd like to put a bit of perspective back into this discussion. The essential idea letbat has is by using delay, it tries to stay out of the way of TCP, so that it doesn't clobber interactive web traffic. We now know that most of the bittorrent damage was caused by bufferbloat: even a single long lived TCP connection will saturate any edge link and fill any sized buffer (see my demo on youtube: http://www.youtube.com/watch?v=npiG7EBzHOU). Worse, when delays go up, TCP's responsiveness to competing traffic degrades as a quadratic of the delay: 10 times extra delay means TCP won't respond to getting out of the way for 100 times as long. Ledbat has essentially engineered around bufferbloat to avoid hurting interactive web traffic, and to avoid depending on diffserv, though one of bittorrent's properties (using many TCP connections simultaneously in its original incarnation) confused the issue. Bufferbloat is much worse than most understand: "typical" overbuffering in today's broadband is best measured in *seconds* rather than milliseconds in today's internet. Once we have AQM in the edge links, the links will remain low latency (and the many TCP connections problem of bittorrent will reappear; a pile of bittorrent uploads will be competing with your other traffic). And I don't know how to fix bufferbloat in any other real way (unless you can wave a magic wand and make *all* TCP's delay sensitive, and that has other problems). So as a viable congestion avoidance algorithm for real time web, ledbat just isn't viable or useful, as far as I can see. Ironically, diffserv has in fact been deployed without anyone except the gaming industry noticing: this occurred since the default line discipline in Linux is PFIFO_FAST, and it implements a particular diffserv marking. For better or worse, that's what's actually deployed, and some application/devices implement diffserv marking matching that. To be honest, I see no way around fixing bufferbloat, and I'd certainly like some good way to mark such traffic as we can with TCP (via drops or ECN), so the audio/video flows can react to network congestion changes. And the edge of the network *will* normally be congested, at least some of the time. Do we need congestion avoidance in RTP flows? Certainly: I'd really like to use any spare bandwidth for higher quality audio and video. I'd certainly like to mark RTP packets when congestion occurs. And I'd like to be able to normally use all my bandwidth, which means that (given HD sensors are now cheap) I can easily expect outgoing (and maybe incoming) video to saturate my edge links routinely independent of whatever other TCP or bittorrent traffic is underway. Again, we can/should presume the edge links (both inside the house and in the broadband edge links) to be running normally saturated. But ledbat isn't a solution for real time protocol congestion avoidance, unless you have a magic wand to change all the existing TCP's out there in finite time (even if they don't lose relative to other TCP's, which I expect they do; so I believe there is a positive disincentive for anyone to change TCP's congestion avoidance algorithm). - Jim
participants (12)
-
David Ros -
eemea\esarzah -
Fu Jiantao -
Harald Alvestrand -
Jim Gettys -
Matt Mathis -
Michael Tuexen -
Michael Welzl -
Piers O'Hanlon -
Randell Jesup -
Saverio Mascolo -
Zaheduzzaman Sarker