Re: [rtcweb] A proposal for FEC

[Varun Singh <[e-mail]>]

On Mon, May 19, 2014 at 4:21 PM, Justin Uberti <[e-mail]> wrote:
> RFC 5109 defines a basic XOR-based scheme that should be useful in certain
> cases (e.g. high RTT). The concern expressed today about this not working in
> BUNDLE situations is addressed in RFC 5956, S 4.3, using ssrc-group to allow
> SSRC multiplexing, and this is endorsed by Unified Plan, S 3.3.
>
> I would like to see ULPFEC/5109 move forward as a baseline FEC mechanism for
> 1.0. We can look into other options for future versions of WebRTC.

I would like to +1 the use of FEC.

There have been a couple of studies done on Google's congestion
control algorithm,
the results show the use of FEC.

See Figure 5 in [1] shows the proportion of FEC and RETX at different
latencies, and
Table 2 in [2] shows that the use of FEC and RETX can be used as a
error-resilience mechanism.
Stefan Holmer from Google also published [3] which makes the case of
FEC in WebRTC.

Further, we have experimented with varying the amount of FEC to
perform congestion
control with promising results [4].



[1] Experimental Investigation of the Google Congestion Control for
Real-Time Flows; L. De Cicco et al.,
http://c3lab.poliba.it/images/0/07/Webrtc_cc-Fhcmn2013.pdf
[2] Performance Analysis of Receive-Side Real-Time Congestion Control
for WebRTC; Singh et al.,
http://www.netlab.tkk.fi/~jo/papers/2013-12-pv-webrtc-cc.pdf
[3] Handling Packet Loss in WebRTC, Holmer et al.
http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41611.pdf
[4] Congestion Control using FEC for Conversational Multimedia
Communication; Nagy et al.
http://www.netlab.tkk.fi/~varun/nagy2014mmsys.pdf