Subject: [rtcweb] Comments on draft-ietf-rtcweb-fec-01

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Mar 2015 11:13:34 +0100

Hi,

I have reviewed draft-ietf-rtcweb-fec-01 and have some comments.

1. Title:

My impression of the document from the title is that this is only
requirements and no normative specification of FEC for WebRTC. Thus, I
would suggest changing the title. I think one can simply remove
"requirements" by changing the order, i.e. "Forward Error Correction in
WebRTC".

2. Section 3.1:
   This approach, as described in [RFC5956], Section 4.3, sends FEC
   packets as an independent SSRC-multiplexed stream, with its own SSRC
   and payload type.  While by far the most flexible, each FEC packet
   will have its own IP+UDP+RTP+FEC header, leading to additional
   overhead of the FEC stream.

I think this section must have more description of what "Separate FEC
stream" really is. The "FEC Grouping for SSRC-Multiplexed RTP Streams"
reference also appear to restrictive. Based on the transport documents
there actually exists an requirement for supporting fully unbundle
configuration. That is not really matching what Section 4.3 describes.

>From my perspective there are two sets of orthogonal questions around
FEC streams. First the relation between the source flow(s) and the
repair flows, which may be 1 to 1, 1 to M, or N to 1, or N to M. Then we
have the other question of how they are transmitted in relation to the
source flow. Within the same RTP session, on different RTP session,
outside of the RTP session. And if one has many source flows, then one
can also discuss if there is N source RTP sessions and M repair sessions
or 1 source RTP session and 1 repair session.

3. Section 3.4:

I think you want to discuss FEC information as a "redundant" encoding also.

4. Section 4.1:
   When using constant-bitrate codecs, e.g.  PCMU, use of [RFC2198]
   redundant encoding MAY be used, but note that this will result in a
   potentially significant bitrate increase, and that suddenly
   increasing bitrate to deal with losses from congestion may actually
   make things worse.

   Because of the lower packet rate of audio encodings, usually a single
   packet per frame, use of a separate FEC stream comes with a higher
   overhead than other mechanisms, and therefore is NOT RECOMMENDED.

I think this fails to discuss the quite reasonable application of XOR
FEC as a redundant encoding information. That way one can achieve a
bitrate increase that is ~1/N of the source flow bit-rate by including
one XOR packet every N packets covering those N packets. Sure that only
gives single packet loss protection, but might be appropriate anyway.

5. Section 4.2:

I think this more clearer needs to reference and possibly discuss the
signalling context it is operating in, i.e. JSEP.

6. Section 5.1:
   Note that this only allows the FEC stream to protect a single primary
   stream.  Support for protecting multiple primary streams with a
   single FEC stream is complicated by WebRTC's 1-m-line-per-stream
   policy and requires further study.

For efficient application of FEC this is the way one have to go.
Unfortunately that also requires FEC codes that are more complex than
XOR and also more likely to be IPR encumbered. But if ones goal is to
have low delay, be almost independent of loss pattern and have
protection for multi packet loss, then aggregating together all the data
sent in a relatively short intervals (<50 ms) and protect them together
is the way to go.

Unfortunately I don't think we have all the pieces in place here in IETF
to perform such a protection, especially in the context of BUNDLE as
well as the possibility to fully unbundle them. It mostly an exercise to
put the pieces and the necessary identification required for aggregating
flows into a common source block and signal that, and make it clear
where the protection data is sent that is missing.

I was part of doing this in 3GPP Multimedia Broadcast/Multicast Service
(MBMS), but that system performs the FEC operation on UDP Flows as a way
to handle both RTP/RTCP as well as MIKEY messages with the keys to
media. It is also a streaming service with more relaxed timing
requirements.

If you are interested to see how that is specified please see Section
8.2.2 of TS 26.346:
http://www.3gpp.org/ftp/Specs/archive/26_series/26.346/26346-c40.zip

I personally think this is the direction to go to achieve efficient FEC
usage for the real-time media, especially when you have multi-stream
situations. However, I can't contribute the hours needed to make rapid
enough progress on this. Thus, I guess this needs to remain a potential
second phase of the FEC work for WebRTC.

7. Section 6.

I think this section must discuss the fact that the data channel have
several possibilities for dealing with reliability. First one can use a
reliable stream, that will do retransmissions. One can use semi-reliable
stream to not needless continue to try, or the application can select to
repeat the data itself over an unreliable stream. I think the last
should be recommended against as it will waste resources unnecessarily.

8. Section 7:

What about using RFC 2198 and [I-D.ietf-payload-flexible-fec-scheme]? Or
isn't that supported at all by [I-D.ietf-payload-flexible-fec-scheme]?
(Yes, I will review that spec, but haven't gotten to it yet).

9. Section 9.

I think there is a point of discussing how FEC configuration can cause
significant waste of bandwidth. Making even a encoded stream with modest
bandwidth needs into a bandwidth consuming monster simply by influencing
the usage of FEC and its parameters. Thus, I think this document needs
to discuss the issues with possible interference from malicious
applications with the signalling and the need for a WebRTC
implementation to actually control the application and usage of FEC
itself and not rely on the signalling parameters.

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: Justin Uberti <[email-masked]>
Date: Tue, 24 Mar 2015 00:24:45 -0500

Inline:

> "requirements" by changing the order, i.e. "Forward Error Correction in

OK.

> configuration. That is not really matching what Section 4.3 describes.

Even when BUNDLE is not used, unified plan still indicates that the FEC
stream will be sent as a SSRC-muxed stream. I think the text in 3.1 is
accurate, although this could be spelled out better.

> or 1 source RTP session and 1 repair session.

The salient issue is that there is no current way with unified to have a
FEC stream as its own m= line. This will require some thinking to resolve.

> I think you want to discuss FEC information as a "redundant" encoding also.

There is no section 3.4 - are you suggesting clarifying 3.2's use of
"Redundant Encoding" to refer to 2198?

> gives single packet loss protection, but might be appropriate anyway.

I'll bring this up on Wednesday. I didn't get the sense from Honolulu that
there was support for doing any nontrivial FEC for audio.

> signalling context it is operating in, i.e. JSEP.

OK.

> second phase of the FEC work for WebRTC.

Agreed.

> should be recommended against as it will waste resources unnecessarily.

If the application wants to send redundant data as an application-level FEC
mechanism, that seems fine to me. The SCTP CC will prevent the application
from harming others.

> (Yes, I will review that spec, but haven't gotten to it yet).

Do you mean using these two in conjunction? I am not sure there is any
advantage to doing so, but open to discussing this.

> itself and not rely on the signalling parameters.

True, but it will still be capped by the congestion control, so I don't
think there is a real-world attack here.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 25 Mar 2015 12:44:02 -0500

Hi,

Removing the parts where there is nothing further to discuss.

On 2015-03-24 00:24, Justin Uberti wrote:
> On Wed, Mar 18, 2015 at 3:13 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     2. Section 3.1:

I am not fully convinced. I would think that if you completely unbundle
that would imply that you can have separate RTP sessions for FEC. The
reason I raise this is that if one actually have flow based QoS you
might actually want to operate the FEC stream on a higher drop
probability than the main media stream.

I note that it doesn't appear that we have any documentation going into
a document that we intended to publish that discusses this issue.

https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-media-rtp-session/

does in Section 7.2 have a short discussion of this.

> FEC stream as its own m= line. This will require some thinking to resolve.

What encodes unified really. Bundle encodes certain properties as long
as you actually do bundling. However, if I don't include bundle
attributes then we what prevents anyone from having a different m= line
with the FEC payload format and bind it to a media description using the
a=Group: FEC-FR to bind them together.

> "Redundant Encoding" to refer to 2198? 

It was suggestion for a new section. What I mean is that one rune XOR
based but include it in the RTP session using RFC2198. OR at least
discuss why you excluded this possible inclusion.
> I'll bring this up on Wednesday. I didn't get the sense from Honolulu
> that there was support for doing any nontrivial FEC for audio.

Good.

> If the application wants to send redundant data as an application-level
> FEC mechanism, that seems fine to me. The SCTP CC will prevent the
> application from harming others. 

Sure, this might not be that dangerous, but I think it is worth spending
some few words pointing out that the Datachannel actually have several
modes to achieve full or partial reliability and don't really need to
use FEC.

> advantage to doing so, but open to discussing this. 

Yes, are there any interest to use them in conjunction?

> think there is a real-world attack here.  

Yes, it might not hurt the external world particular much. It will waste
some resources and reduced the user experience.

Cheers

Magnus Westerlund