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