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