Skip to content

WebRTC GCC writeup

Jump to bottom Edit New page
Yancey Wang edited this page Oct 4, 2022 · 1 revision

originally at https://gist.github.com/wangyu-/e6208baf47945d56595872d9af5c6542

Backgroud

What I am doing with WebRTC and reason

I am trying to make the congestion control in whist work better. The articles and papers about GCC( google congestion control) are pretty out of date, so I am looking into the GCC implementation inside webrtc directly.

At the moment the delay-based control of our WCC doesn’t work reliably , WCC is failing back to loss-based only for many cases. For some cases the WCC blow up the link buffer and leads to extra latency of hundreds of ms, and stress the link to near 10% packet loss.

I am trying to get delay-based controller implemented based on the understanding of webrtc. I am also considering a different method of extracting the congestion control module out of webrtc and integrated into whist.

At the same time, I have figured out ways of doing experiment with webrtc and get plots. In future if we have boundary case in congestion control (or general networking problem), we can experiment with webrtc and see how webrtc solves the problem. Many problems we encountered are already solved in webrtc, we can reused their ideas and avoid re-invent similar mechanism.

(the above words are mostly copied and re-used from a chat with Roshan)

GCC has changed many since the last paper and ietf draft

Our WCC is based on the GCC(Google Congestion Control) version descripted in [1] [2] [3]. It's is an early version of GCC, which contains a loss-bassed controller and a delay-based controller based on Kalman filter(Let's call this version Classic GCC ).

The lastest version of WebRTC is WerRTC M104, let's call the GCC implemented inside M104 the Latest GCC.

The Latest GCC differs from Classic GCC a lot, the major changes are:

  1. the delay-based contoller has been moved from receiver-side to sender side.

  2. the kalman filter has been replaced with a trendline filter. first introduced in: https://codereview.webrtc.org/2489323002

  3. an ALRdetector (Application Limit Region) is introduced to detect encoder undershoot and do special handling. first introduced in: https://codereview.webrtc.org/2340763004

  4. a Prober has been introduced to handle various situations which classic GCC doesn't handles well like:

    (1) fast detect the startup bandwith. (where bandwith detection is pretty slow in classic GCC)

    (2) probe the bandwith when there is encoder undershoot, while avoid huge overhead of padding

    (3) other various boundary cases

    first introduced in: https://codereview.webrtc.org/2235373004

In a summary, if compare our WCC with the Lastest GCC we don't only lack a trendline filter.

Methods to make the Congestion Control better in Whist

We basiclly have two methods of improving the congestion control in Whist:

  1. Keep the current framework and code of WCC, read GCC code inside webrtc, graudally implement the missing features of GCC in WCC

  2. We extract the whole congestion control module out of WebRTC, integrate it into Whist, replace WCC completely.

About first method

If our goal is only to make the trendline filter works, this method requires less change to our code, and it should be faster to get improvement for our product.

But if we eventually want to get the ALR detector and Prober working. This method will take more time in total. Since this method needs us to re-write a lot of codes, organize them in a way what works inside the WCC framework. And such a process is very bug-prone(Latest GCC's congestion control module has 6000 lines of codes, imagine we re-write or adapt those codes piece by piece...)

About second method

The seconds mehtod is going to take more initial time. We need to change a lot Whist codes so that the webRTC congestion control module can be ingetrated smoothly.

But once this method works, we got all the lastest feature of GCC.

In addition this mehtod might be better to be broken into phases:

  1. we link webrtc code into whist, and call the congestion code inside webrtc and make integration (this will significantly increase the binary size of whist, but it's easy for proof-of-concept purpose). And make tunings.

  2. we extract congestion control module out of webrtc, so that we don't need to link to webrtc

  3. we port some improvements we done in WCC to the the new method.

My Plan

  1. Get trendline filter and delay based contorller working with first method. And see how well it solves our urgent problems.

  2. (1) If we are happy enough with the result in 1, then we might don't have much motivation of implementing the ALR and prober in Lastest GCC. Then I will switch to work on SVC first, then look back later.

    (2) If it turns out 1 is not good enough, and we might need ALR and prober as well. Then I will abaondon the first method, an switch to the second mehtod.

Current status

  1. the webrtc experiment mehtods are pretty mature. Webrtc can be run inside both xcode and vscode, we can attach debugger to set breakpoints and look at the callstacks pretty easily. And we can plot graphs easily in a similiar way as the Whist Plotter.

  2. for the first method, I have a trendline filter implemented on my branch. Still need some time to get it working. I expect we have a working version next week.

  3. for the second method, I have done some investigate of how it works, and what change we need in whist.

References

[1]A Google Congestion Control Algorithm for Real-Time Communication draft-ietf-rmcat-gcc-02 (Year 2016)

[2] Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC) (Year 2016)

[3] Congestion Control for Web Real-Time Communication (Year 2016)

Add a custom footer
Add a custom sidebar
Clone this wiki locally