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