Performance of WebRTC's congestion control in multi-party calls

[Eran]

I recently came across two papers from 2013 (see refs below) which evaluate the congestion control mechanism used by WebRTC.  Both independently conclude that the congestion control doesn’t do such a great job of fairly sharing the bandwidth when there are multiple simultaneous media flows across the same network.  If I understand this correctly, this implies that video streaming problems can be expected (and are unavoidable) when using WebRTC for multi-party conferencing under a mesh topology.  Is this true?  Has the congestion control improved since the papers were written?

 

Thanks

 

References:

Performance analysis of receive-side real-time congestion control for WebRTC

V Singh, AA Lozano, J Ott - Packet Video Workshop (PV), 2013 20th International, 2013

 

Experimental investigation of the google congestion control for real-time flows

L De Cicco, G Carlucci, S Mascolo - Proceedings of the 2013 ACM SIGCOMM workshop on …, 2013

 

[Sergio Garcia Murillo]

Well, being pedantic, there is no congestion control in WebRTC yet ;)

Google implemented their own congestion control ( there are some drafts available about it) and there was source code for multi stream already a couple of years ago, but have not followed the changes so not sure what is current status.

Check IETFs RMCAT group where the "official" discussion is taking place, but I have not seen much movement in the last two years.

Best regards
Sergio

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7d4fa7ff-baf2-4050-99d8-f3b189388be5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Varun Singh]

Hi Eran,

I wrote one of those papers, the study was done in 2012-13, early days. My personal opinion is that the performance has improved, especially the late starting flows are not starved as visibly as before.

The results for GCC (a version of it is implemented in Chrome and Firefox) and other proposals are documented in Internet Drafts in the RMCAT WG, see the various proceedings (IETF 94, 93, 90, etc) [1]

[1] https://www.ietf.org/proceedings/94/rmcat.html, http://www.ietf.org/proceedings/interim/2014/11/09/rmcat/proceedings.html

Cheers,

Varun

[Stefan Holmer]

We've made many significant improvements since 2013. Slides 24-28 here may be of particular interest to you as they cover our fairness improvements, which are part of Chrome M50 (current beta channel).

If you are having problems related to fairness we would very much like to hear about them so that we can improve further.

/Stefan

--

[Ying Yin]

Hi Stefan,

Does the Android build for WebRTC have the same congestion control implementation?

Thanks,

Ying

[Stefan Holmer]

Yes, we only have one, with some variations depending on rtp header extensions negotiated.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5a295726-ffbf-4a97-bc16-b098684d6a45%40googlegroups.com.