On 4/10/2012 10:40 AM, Stefan Holmer wrote:
On Tue, Apr 10, 2012 at 4:02 PM, Randell Jesup <randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>> wrote: As do I. Also, I *REALLY* worry about the interaction of LEDBAT flows and rtcweb flows... If it targets 100ms queuing delay as the "I'm out of the way of TCP" level, that could seriously negatively impact us (and general VoIP as well, but even more so us, since we'll again get driven into the ground trying to keep the queues drained. It may take longer, but LEDBAT flows tend to be close-to-infinite I would assume. If it targets 25ms, that's less problematic I suspect.
I'm not saying I know there will be a problem here, but that I fear there will be since LEDBAT has a non-0 queuing target - it may "poison the waters" for any delay-based algorithm that wants to target a lower number.
Yes, having two algorithms with different delay targets compete should be approximately the same thing as having a delay-based algorithm compete with a loss-based algorithm, although the effects seen may be more or less bad depending on how close the targets are. To be clear, our draft (draft-alvestrand-rtcweb-congestion) has a 0 delay target, which means that it will always let the queues drain before increasing the rate.
Right - which means someone should raise this issue about LEDBAT ASAP. Which WG is handling it? -- Randell Jesup randell-ietf@jesup.org