Fwd: Questions about the video rate control and QoS in webrtc
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<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. 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 <fuji246@gmail.com>
Thanks Randell for giving me the direction, it's extremely helpful for me.
2012/3/9 Randell Jesup <randell1@jesup.org>
On 3/8/2012 12:42 AM, Fu Jiantao wrote:
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.
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 randell-ietf@jesup.org
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@jesup.org
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....)
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
participants (3)
-
Fu Jiantao -
Harald Alvestrand -
Randell Jesup