[R-C] LEDBAT - introductions?

[Randell Jesup]

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 at jesup.org