<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.