[R-C] Fwd: Questions about the video rate control and QoS in webrtc

[Randell Jesup]

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