On 3/14/2012 4:41 PM, Harald Alvestrand wrote:
On 03/09/2012 06:18 PM, Randell Jesup wrote:
As for the queue-length, as far as i know, there are some ISPs are using policing instead of shaping, so delay-based congestion control should not work.
By policing you mean ? RED? Some other form of AQM (Active Queue Management)? Jim Gettys has been taking some part in these discussions; he's the main crusader for rolling out AQM and limiting router buffer queue sizes.
i think policing (usually leaky bucket) is quite common for doing bandwidth limiting - making sure subscribers don't exceed their bandwidth allotment while not having to adjust the physical line speed. (At the moment, my local fiber, with a 10 Mbit subscription, seems to be ~67 Mbits upload and 10.00 Mbits download; it's obvious which direction has a policing mechanism applied to it....)
Leaky bucket, however, does normally involve queuing (though I suppose the bucket could be 1 packet deep). However, per the Wikipedia page (http://en.wikipedia.org/wiki/Leaky_bucket) on Leaky Bucket, when the "Leaky Bucket as meter" is used in policing (instead of traffic shaping), there would be no queuing, just loss. This is what I assume the original questioner was referring to. The bucket still regulates the time period over which traffic bandwidth is "averaged" to decide if the flow is over-bandwidth. But the original poster is correct, there is no delay signal for our algorithm to receive, just a loss signal. This is very good for bufferbloat issues and end-2-end delay, kindof bad for throughput and quality due to the loss. But when we're competing with TCP connections, we won't lose (I believe) as we normally would with queues. There's still the question of how common this is. -- Randell Jesup randell-ietf@jesup.org