Questions about the video rate control and QoS in webrtc

[Fu Jiantao]

Hi all,

   Does anybody know how video rate control is done in webrtc?  How did it adjust the rate according to the bandwidth available? I haven't found the relating code of congestion control, however i've seem some code to do QoS, which set the DSCP in the packet.

   I'm really curious about how webrtc coordinate between different kinds of applications, for example, when there's file transfer and video call. I've familiar with libjingle code, and seems it lack of thus QoS and traffic control logic.

   Thanks in advance!


Regards,
Jeromy

[Randell Jesup]

See src/modules/rtp_rtcp/source/bandwidth_management.cc, and related
files and uses of REMB rtcp messages.

This is an ongoing discussion on the rtp-congestion IETF mailing list,
which was spun out of the rtcweb (IETF side of webrtc) mailing list.
We're presenting some I-D's at IETF paris, and if you read the archives
of the list, we have proposals for how to congestion-control multiple
streams and also we hope to include the data-channels in the congestion
regime. libsctp includes a congestion module that provides low-delay,
and Cx-TCP is based on the same research and provides low-delay when
possible and switches to higher-delay, loss-based functionality if it
finds it can't stay in low-delay mode (fighting a saturating TCP
connection(s)).

--
Randell Jesup
randel...@jesup.org

[Fu Jiantao]

Thanks Randell for giving me the direction, it's extremely helpful for me.

2012/3/9 Randell Jesup <rand...@jesup.org>

[Fu Jiantao]

Hi Randell,

   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, 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.

  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.

  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.

  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.

  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)

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


Thanks,
Jeromy
 

2012/3/9 Fu Jiantao <fuj...@gmail.com>

[Harald Alvestrand]

In order to discuss congestion control algorithm development, please
join the rtp-con...@alvestrand.no mailing list -
http://www.alvestrand.no/mailman/listinfo/rtp-congestion should give
you the info you need.

The delay-based congestion control algorithm is documented in
draft-alvestrand-rtcweb-congestion-01.txt

Good luck!

[Luca De Cicco]

Dear Jeromy,

my comments are inline.

Best regards,

Luca

On Friday, March 9, 2012 8:17:21 AM UTC+1, jeromy wrote:

Hi Randell,

   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, 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.

  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.

  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.

  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.

About Skype bandwidth adaptation you might look at our work:

L. De Cicco, S. Mascolo, V. Palmisano
Skype Video Congestion Control: an Experimental Investigation
Computer Newtorks, Elsevier, vol. 55, n.3, pp. 558-571, 2011

L. De Cicco, S. Mascolo
A Mathematical Model of the Skype VoIP Congestion Control Algorithm
IEEE Transactions on Automatic Control, vol. 55, n. 3, pp. 790-795, Mar 2010

both available at: http://c3lab.poliba.it/index.php/LDC:Publications