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

[Randell Jesup]

On 3/9/2012 5:24 AM, Fu Jiantao wrote:
>     I've follow your directions, seems webrtc is using TFRC to give an
> estimation of the bandwidth, I've read chapter 10 of "*RTP: Audio and
> Video for the Internet" *written by Colin Perkins
> <http://www.informit.com/safari/author_bio.asp@ISBN=0672322498>,
> according to the description on this, "/This seems to be a simple
> matter, but in practice there are issues to be resolved. The most
> critical matter is how the loss rate is measured and averaged, but there
> are secondary issues with packet sizing, slow start, and noncontinuous
> transmission/", I've got no hands-on TFRC yet, and wondering how well it
> works.

Actually, no, TFRC is being used as an upper-bound.  TFRC isn't 
low-delay (just as TCP isn't low-delay), and we want low-delay for 
interactive audio and video.

>    Another question is about "Google disclosed an algorithm for doing
> "predictive" bottleneck-buffer queue-length sensing based on packet
> arrival times compared to RTP timestamps." you mentioned, I've searched
> but no found of the relating publication.

Harald Alvestrand published an IETF I-D back around October for it. 
Search for draft-alvestrand-rtcweb-congestion

>    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've test on Skype, seems it does well in the rate control, it reacts
> on the bandwidth changes well, in both shaping and policing links( I use
> linux traffic control toolset to emulate different network
> environments), and it has done QoS control over different kinds of
> applications(In shaping network, when during video call, start a file
> transfer will not hurt the quality of video, the rtt is control around
> 90ms(2ms when no congestion), and when cancel the video call, the delay
> ramps up to about 120ms to make full use of the bandwidth. However, the
> video quality will affected in policing link when the congestion control
> probe for more bandwidth due to packet loss even there maybe FEC.

>
>    Another difficult problem when coordinate interactive app and data
> app is how to identify the shared bottleneck, in shaping network, using
> the correlation of queuing delay seems work fine, but I've no idea how
> to do this in policing link. And I'm not very sure the congestion occurs
> at the access network.

The algorithm we're using doesn't care where the bottleneck is, just 
that it exists.

I developed and used an algorithm similar (very) to Google's many years 
ago for my old company, and it worked very well in practice, even in 
corporate networks.

>    We're going to gather network statistics in the real network, in
> intrusive way currently. The metrics including RTT, Qdelay, Loss,
> Bandwidth, Lossy link information, protocol used, route etc. And I hope
> these can be used to improve the congestion control algorithm.(For
> example, as you suggested, using the user history bandwidth as a hint as
> the initial value)

Real world tests are great (if they're really real-world).

>    I've got numerous questions remains, listed above is some what messy.
> Very appreciate to your insights on these.

-- 
Randell Jesup
randell-ietf at jesup.org