[R-C] LEDBAT vs RTCWeb

[Randell Jesup]

On 4/10/2012 3:14 PM, Jim Gettys wrote:
> On 04/10/2012 02:58 PM, Randell Jesup wrote:
>>
>> 100ms is just bad, bad, bad for VoIP on the same links.  The only case
>> where I'd say it's ok is where it knows it's competing with
>> significant TCP flows.  If it reverted to 0 queuing delay or close
>> when the channel is not saturated by TCP, then we might be ok (not
>> sure).  But I don't think it does that.
>>
> You aren't going to see delay under saturating load under 100ms unless
> the bottleneck link is running a working AQM; that's the property of
> tail drop, and the "rule of thumb" for sizing buffers has been of order
> 100ms.  This is to ensure maximum bandwidth over continental paths of a
> single TCP flow.

You missed part of the point: LEDBAT is a "scavenger" protocol that 
currently targets 100ms of queuing delay using a one-way-delay estimator 
and an estimate of base transfer delay based on history.  This means it 
won't necessarily saturate to the full buffer-bloat level that TCP 
would, but it may well keep the link at or above 100ms queuing *all* the 
time (given a target for this protocol is bittorrent clients).


-- 
Randell Jesup
randell-ietf at jesup.org