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

[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<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 at gmail.com>

> Thanks Randell for giving me the direction, it's extremely helpful for me.
>
> 2012/3/9 Randell Jesup <randell1 at 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 at jesup.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120309/60a24e08/attachment.html>