Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-fec-00.txt

From: [email-masked]
Date: Fri, 06 Feb 2015 08:56:14 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

        Title           : WebRTC Forward Error Correction Requirements
        Author          : Justin Uberti
	Filename        : draft-ietf-rtcweb-fec-00.txt
	Pages           : 7
	Date            : 2015-02-05

Abstract:
   This document makes recommendations for how Forward Error Correction
   (FEC) should be used by WebRTC applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 07 Feb 2015 08:49:06 +0100

I have two comments to draft-ietf-rtcweb-fec-00

1. Use of redundancy.
Section 3.2 "Redundant encoding" informs about RFC 2198 .
The last sentence says "This approach is also only applicable to audio 
content."
RFC 2198 redundancy is successfully used in SIP and RTP for real-time 
text content (RFC 4103), because of its robustness, very low cost in 
bandwidth for low bandwidth media, and no risk for excessive delays.
Chapter 3 seems to be a general overview of available methods without 
specific scope to WebRTC.
Therefore, I suggest to either replace the sentence

"This approach is also only applicable to audio content."
with
"This approach is also not applicable to video content."
or delete it.

2. Use of SHOULD and MUST in abstract and introduction
There are a couple of places in the document where the use of "must" and "should" may be confusing and should be avoided.

The last sentence in the introduction says:
"This document describes what FEC mechanisms should be used by WebRTC client implementations."
There is a similar sentence in the abstract.
There is also a "must" in the first sentence of the introduction, even if it is not thought to be normative.
In the document body, there are varying normative levels on the different methods.
Therefore I suggest to avoid the must and should in the abstract and introduction.

2.1 The last sentence of the introduction can be changed to:
"This document provides information and requirements on the use of FEC mechanisms by WebRTC client implementations."

2.2 The abstract could be changed from:
"This document makes recommendations for how Forward Error Correction (FEC) should be used by WebRTC applications."
to
"This document provides information and requirements on the use of Forward Error Correction (FEC) mechanisms by WebRTC applications."

2.3 The first sentence in the introduction, starting:
"In situations where packet loss is high, or media quality must be perfect,"
could be changed to:
"In situations where packet loss is high, or high media quality is essential,"
to avoid the use of "must" that apparently is not intended to be normative.

Regards

Gunnar Hellström

[email-masked] skrev den 2015-02-06 17:56:
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Justin Uberti <[email-masked]>
Date: Sat, 7 Feb 2015 10:24:22 -0800

Thanks for the quick review and comments. I'll incorporate this into the
-01 version I am working on.

On Fri, Feb 6, 2015 at 11:49 PM, Gunnar Hellström <
[email-masked]> wrote:

> RFC 2198 redundancy is successfully used in SIP and RTP for real-time text
> content (RFC 4103), because of its robustness, very low cost in bandwidth
> for low bandwidth media, and no risk for excessive delays.
> There are a couple of places in the document where the use of "must" and
> "should" may be confusing and should be avoided.
>
> "This document provides information and requirements on the use of FEC
> mechanisms by WebRTC client implementations."
>
> "This document makes recommendations for how Forward Error Correction
> (FEC) should be used by WebRTC applications."
> to
> "This document provides information and requirements on the use of Forward
> Error Correction (FEC) mechanisms by WebRTC applications."
>
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Barry Dingle <[email-masked]>
Date: Sun, 8 Feb 2015 12:44:34 +1100

The new "WebRTC Forward Error Correction Requirements" draft refers solely
to 'media' FEC requirements.

It does not refer to non-media (or DataChannel) uses of FEC.

If this draft is intended to concentrate on the media FEC requirements,
then the Title should be changed to reflect that, namely:

"WebRTC *Media* Forward Error Correction Requirements",

If it intended to also cover DataChannel uses of FEC then the draft should
have a new section after Section 5 with a Heading of "FEC for DataChannel
Content".

/Barry Dingle

---

From: Justin Uberti <[email-masked]>
Date: Sat, 7 Feb 2015 22:17:49 -0800

Interesting point. I don't think the WG has really discussed data FEC in
detail yet, so your title suggestion makes sense to me.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Sun, 08 Feb 2015 04:47:01 -0800

> detail yet, so your title suggestion makes sense to me.

Wouldn't we just use SCTP retransmissions? Something more sophisticated 
than that seems like it would require application knowledge, so it 
should probably be handled at the application layer.

---

From: Barry Dingle <[email-masked]>
Date: Mon, 9 Feb 2015 00:10:41 +1100

Justin Uberti wrote:

> than that seems like it would require application knowledge, so it should
> probably be handled at the application layer.
>
> For non-realtime data - Yes.

For realtime data applications - such as realtime text - with low delay
requirements from text entry a Sender to display at Receiver, you often
need FEC particularly on wireless connections.

/Barry Dingle

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Sun, 8 Feb 2015 14:54:21 +0000

Media FEC is necessary within WebRTC internals because apps have no access to the RTP media. Apps obviously have full access to data channel messages, as well as reliability settings, so app layer FEC is always possible. It may be useful to extend SCTP reliability settings with FEC options, but that would need new tsvwg work before any rtcweb work. I would not support normative dependencies on such work in this draft, although I would support the new work.

Mo

On Feb 8, 2015, at 8:11 AM, "Barry Dingle" <[email-masked]<mailto:[email-masked]>> wrote:

Justin Uberti wrote:

Wouldn't we just use SCTP retransmissions? Something more sophisticated than that seems like it would require application knowledge, so it should probably be handled at the application layer.

For realtime data applications - such as realtime text - with low delay requirements from text entry a Sender to display at Receiver, you often need FEC particularly on wireless connections.

/Barry Dingle
_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Jozsef Vass <[email-masked]>
Date: Wed, 11 Feb 2015 09:01:59 -0800

I just wondering what kind of FEC is recommended (or will be supported) for
G.711. The draft does not recommend neither redundant encoding nor a
separate FEC stream.

Jozsef

Jozsef Vass
SDK Engineering
 <http://www.twilio.com/?utm_source=email_signature>
MOBILE(415) [email-masked]
SIGNAL: The modern communications conference
<http://signal.twilio.com/?utm_source=employee_signature&utm_medium=email&utm_content=signal>
May 19/20 2015, Fort Mason Festival Pavilion, SF, CA
<http://signal.twilio.com/?utm_source=employee_signature&utm_medium=email&utm_content=signal>
<https://www.twilio.com/> <https://www.facebook.com/TeamTwilio>
<https://plus.google.com/u/0/+twilio/posts> <https://twitter.com/twilio>
<https://www.linkedin.com/company/twilio-inc.>
<http://www.glassdoor.com/Overview/Working-at-Twilio-EI_IE410790.11,17.htm>

---

From: Simon Perreault <[email-masked]>
Date: Wed, 11 Feb 2015 14:39:17 -0500

On Wed, Feb 11, 2015 at 12:01 PM, Jozsef Vass <[email-masked]> wrote:

> I just wondering what kind of FEC is recommended (or will be supported)
> for G.711. The draft does not recommend neither redundant encoding nor a
> separate FEC stream.

Isn't this what you're looking for?

3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00#section-3.1>.
Separate FEC Stream

   This approach, as described in [RFC5956], Section 4.3
<http://tools.ietf.org/html/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.

Simon

---

From: Jozsef Vass <[email-masked]>
Date: Wed, 11 Feb 2015 11:44:53 -0800

Later, in 4.1 Recommended Mechanisms:

   When using constant-bitrate codecs, e.g.  PCMU, use of [RFC2198
<http://tools.ietf.org/html/rfc2198>]
   redundant encoding is NOT RECOMMENDED, as this will result in a
   potentially significant bitrate increase.  Furthermore, suddenly
   increasing the bitrate to deal with packet losses 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.

So what is recommended for PCMU?

Jozsef

Jozsef Vass
SDK Engineering

On Wed, Feb 11, 2015 at 11:39 AM, Simon Perreault <[email-masked]>
wrote:

> 3.1 <http://tools.ietf.org/html/draft-ietf-rtcweb-fec-00#section-3.1>.  Separate FEC Stream
>
>    This approach, as described in [RFC5956], Section 4.3 <http://tools.ietf.org/html/rfc5956#section-4.3>, sends FEC

---

From: Justin Uberti <[email-masked]>
Date: Thu, 12 Feb 2015 16:01:35 -0800

If we do any FEC with PCMU, it would probably be 2198-style for simplicity
(counter to what the current text says). Is this something that you would
use?

On Wed, Feb 11, 2015 at 11:44 AM, Jozsef Vass <[email-masked]> wrote:

>    When using constant-bitrate codecs, e.g.  PCMU, use of [RFC2198 <http://tools.ietf.org/html/rfc2198>]

---

From: Jozsef Vass <[email-masked]>
Date: Tue, 17 Feb 2015 15:07:00 -0800

Yes, that would work for us. Our main use case is audio only. In addition,
implementers may add PLC (Appendix I) to G.711.

Jozsef

Jozsef Vass
SDK Engineering