Subject: [rtcweb] A proposal for FEC

From: Justin Uberti <[email-masked]>
Date: Mon, 19 May 2014 06:21:45 -0700

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<http://tools.ietf.org/html/rfc5956#section-4.3>,
using ssrc-group to allow SSRC multiplexing, and this is endorsed by Unified
Plan, S 3.3<http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#page-16>
.

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.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 19 May 2014 13:32:28 +0000

On 2014-05-19 15:22, Justin Uberti 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
> <http://tools.ietf.org/html/rfc5956#section-4.3>, using ssrc-group to
> allow SSRC multiplexing, and this is endorsed by Unified Plan, S 3.3
> <http://tools.ietf.org/html/draft-roach-mmusic-unified-plan-00#page-16>.
>
I didn't raise my hand, but after some thinking I agree with Justin. 1.0 
should be usable for a big variety of operating condition, and for some 
of them FEC is useful.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 May 2014 11:33:53 -0400

> for 1.0. We can look into other options for future versions of WebRTC.

I think adding ULPFEC in WebRTC is reasonable, however despite what RFC
5956 says, we do have a spec issue with the following part of RFC 5109
that will be required to be overridden:

Section 7.2:

   Synchronization Source (SSRC): The SSRC value SHALL be the same as
   the SSRC value of the media stream it protects.

Section 14.1:

   The SSRC of the FEC stream MUST
   be set to that of the protected payload stream.

   So the FEC
   stream and the payload stream SHOULD be sent through two separate RTP
   session, and multiplexing them by payload type into one single RTP
   session SHOULD be avoided.  In addition, the FEC and the payload MUST
   NOT be multiplexed by SSRC into one single RTP session since they
   always have the same SSRC.

>From my perspective this override should be done in a separate document
so that also others can use it and not being RTCWEB specific.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Varun Singh <[email-masked]>
Date: Mon, 19 May 2014 18:40:04 +0300

On Mon, May 19, 2014 at 4:21 PM, Justin Uberti <[email-masked]> wrote:
> 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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 19 May 2014 11:58:06 -0400

> 
> On May 19, 2014, at 11:33 AM, Magnus Westerlund <[email-masked]> wrote:
> 

The following draft accomplishes this, no?
http://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 19 May 2014 12:01:27 -0400

> http://tools.ietf.org/html/draft-lennox-payload-ulp-ssrc-mux

Yes, but it needs some updates and polishing before ready for
publication. Also, it has not been adopted yet in any WG. But, I think
adopting it and getting it moved forward in an expedited fashion would
be the right way forward.

Cheers

Magnus Westerlund

---

From: Justin Uberti <[email-masked]>
Date: Mon, 19 May 2014 09:37:52 -0700

Sounds like a plan.

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 20 May 2014 16:37:52 +0000

> be the right way forward.

Absolutely — it’s a -00 draft, and definitely could use improvement (especially now that BUNDLE has matured).

If there’s agreement that this should go forward, I’m happy to revise the draft, and if you have specific suggestions, please send them!

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 20 May 2014 10:16:30 -0700

I support updating the above mentioned draft in this regard

./Suhas

On Tue, May 20, 2014 at 9:37 AM, Jonathan Lennox <[email-masked]> wrote:

> Absolutely — it’s a -00 draft, and definitely could use improvement
> (especially now that BUNDLE has matured).
>
> If there’s agreement that this should go forward, I’m happy to revise the
> draft, and if you have specific suggestions, please send them!
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 20 May 2014 13:23:15 -0400

On 2014-05-20 12:37, Jonathan Lennox wrote:
>> publication. Also, it has not been adopted yet in any WG. But, I
>> think adopting it and getting it moved forward in an expedited
>> fashion would be the right way forward.
> 
> If there’s agreement that this should go forward, I’m happy to revise
> the draft, and if you have specific suggestions, please send them!
> 

I think you should revise the draft. I will see if I can get any more
detailed feedback in. Uncertain due to the few days until my parental
leave. But, I think you need to check that you address all the relevant
RFC 2119 language places. It looked to me that you missed to address the
one in Section 7.2 of RFC 5109.

Cheers

Magnus Westerlund