Subject: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

From: Sergio Garcia Murillo <[email-masked]>
Date: Fri, 21 Apr 2017 11:30:10 +0200

Hi all, Justin,

I have been reviewing current FEC draft and I have a couple of comments:

1. Usage of RED and in band FEC and header extensions in Sections 3.2, 
3.3 and 4

I think it would be worth noting that neither red/audio nor in-band fec 
allows to recover RTP header extensions from previous packets. The 
impact of loosing the header extensions will be dependent of its meaning 
as, for example, this would cause minor problems to SFUs as client to 
mixer audio level info of previous packets will be lost, but could make 
it unusable for PERC (as it is currently defined) as it requires the OHB 
header extension.

2. Adaptive use of FEC for bandwidth probing (section 8)

I think it would be a good addition to recommend FEC usage for bandwidth 
proving instead of other alternatives like RTX or padding only packets.

Best regards

Sergio

---

From: Justin Uberti <[email-masked]>
Date: Sat, 22 Apr 2017 12:51:02 -0700

On Fri, Apr 21, 2017 at 2:30 AM, Sergio Garcia Murillo <
[email-masked]> wrote:

> 1. Usage of RED and in band FEC and header extensions in Sections 3.2, 3.3
> and 4
>
> allows to recover RTP header extensions from previous packets. The impact
> of loosing the header extensions will be dependent of its meaning as, for
> example, this would cause minor problems to SFUs as client to mixer audio
> level info of previous packets will be lost, but could make it unusable for
> PERC (as it is currently defined) as it requires the OHB header extension.
>

This is a good observation. Can you summarize the issue with the OHB
extension?

https://github.com/juberti/draughts/issues/48

> proving instead of other alternatives like RTX or padding only packets.

Another good point. Need to think about whether this should go into Section
8, or perhaps be its own section/sub-section.

https://github.com/juberti/draughts/issues/49

---

From: Roni Even <[email-masked]>
Date: Sun, 23 Apr 2017 05:32:12 +0000

Hi,
Inline
Roni Even

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Sergio Garcia
> Murillo
> Sent: יום ו 21 אפריל 2017 12:30
> To: [email-masked]; Justin Uberti
> Subject: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
> 
> Hi all, Justin,
> 
> I think it would be worth noting that neither red/audio nor in-band fec allows
> to recover RTP header extensions from previous packets. The impact of
> loosing the header extensions will be dependent of its meaning as, for

[Roni Even] This is not a FEC problem but general RTP header extensions reliability discussed in RFC5285 and RC5285-bis draft and in the specific RTP header extension.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Justin Uberti <[email-masked]>
Date: Sun, 23 Apr 2017 11:48:01 -0700

On Sat, Apr 22, 2017 at 10:32 PM, Roni Even <[email-masked]> wrote:

> allows
> [Roni Even] This is not a FEC problem but general RTP header extensions
> reliability discussed in RFC5285 and RC5285-bis draft and in the specific
> RTP header extension.
>

Roni, what would you suggest we say in this document?

---

From: Roni Even <[email-masked]>
Date: Mon, 24 Apr 2017 05:43:04 +0000

Hi Justin,
I am not sure that this is something to discuss here, RTP header extensions are discussed in https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26 , which points to RFC5285 soon to be replaced  by the rfc5285-bis draft.
The bis draft has a section about transmission considerations see https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-09#section-4.1.1 discussing reliability of RTP header extension delivery by sending them in multiple RTP packets.

If you still want to say something you can probably add to section 1 “ Web Real-Time Communication (WebRTC) Media Transport and Use of RTP are discussed in https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26”

Roni

From: Justin Uberti [mailto:[email-masked]]
Sent: יום א 23 אפריל 2017 21:48
To: Roni Even
Cc: Sergio Garcia Murillo; [email-masked]
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

On Sat, Apr 22, 2017 at 10:32 PM, Roni Even <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
Inline
Roni Even

> From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Sergio Garcia
> Murillo
> To: [email-masked]<mailto:[email-masked]>; Justin Uberti

> [email-masked]<mailto:[email-masked]>

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 10:28:00 +0200

Hi Roni,

Not following you. Neither RFC 5265 nor RFC 5265-bis references 
red/audio, also webrtc-rtp-usage references the fec draft when speaking 
about redundancy.

Also, please note that I am not proposing to change current RED behavior 
or its usage within webrtc, just proposing to add a "warning" note to 
make it implicit what is the current situation: When using rtp red for 
audio, only payload is protected, and rtp headers are not, which is 
almost harmless currently but could cause some issues in the future if 
not taken into consideration when using new rtp header extensions.

Best regards
Sergio

On 24/04/2017 7:43, Roni Even wrote:
>
> Hi Justin,
>
> I am not sure that this is something to discuss here, RTP header 
> extensions are discussed in 
> https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26 , which 
> points to RFC5285 soon to be replaced  by the rfc5285-bis draft.
>
> The bis draft has a section about transmission considerations see 
> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-bis-09#section-4.1.1discussing 
> reliability of RTP header extension delivery by sending them in 
> multiple RTP packets.
>
> If you still want to say something you can probably add to section 1 “ 
> Web Real-Time Communication (WebRTC) Media Transport and Use of RTP 
> are discussed in 
> https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26”
>
> Roni
>
> *From:*Justin Uberti [mailto:[email-masked]]
> *Sent:* יום א 23 אפריל 2017 21:48
> *To:* Roni Even
> *Cc:* Sergio Garcia Murillo; [email-masked]
> *Subject:* Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04
>
> > From: rtcweb [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Sergio Garcia
> > Murillo
> > Sent: יוםו 21 אפריל 2017 12:30
> > To: [email-masked] <mailto:[email-masked]>; Justin Uberti
> [Roni Even] This is not a FEC problem but general RTP header 
> extensions reliability discussed in RFC5285 and RC5285-bis draft and 
> in the specific RTP header extension.
>
>     > [email-masked] <mailto:[email-masked]>

---

From: Roni Even <[email-masked]>
Date: Mon, 24 Apr 2017 09:04:54 +0000

Hi Sergio,
What I said that the redundancy of RTP header extensions in not a FEC issue. FEC addresses the payload and not the RTP header.  RTP header extensions are discussed in the RFC5285-bis draft and each new RTP header extension must address the issue of loss since RTP over UDP is unreliable.
I am not sure we need any text in rtcweb-fec about RTP header extensions.  General RTP usage in RTCweb is in the RTCweb RTP usage and this is where general redundancy of RTP is discussed, and as a general RTP usage it points at redundancy for payload and for RTP header extensions reference RFC5285 (rfc5285-bis will obsolete it and have a section about transmission consideration.

In this rtcweb-fec document audio/red is a payload; it is not an RTP packet for which you need to address the RTP header redundancy.

Roni Even

From: Sergio Garcia Murillo [mailto:[email-masked]]
Sent: יום ב 24 אפריל 2017 11:28
To: Roni Even; Justin Uberti
Cc: [email-masked]
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

Hi Roni,

Not following you. Neither RFC 5265 nor RFC 5265-bis references red/audio, also webrtc-rtp-usage references the fec draft when speaking about redundancy.

Also, please note that I am not proposing to change current RED behavior or its usage within webrtc, just proposing to add a "warning" note to make it implicit what is the current situation: When using rtp red for audio, only payload is protected, and rtp headers are not, which is almost harmless currently but could cause some issues in the future if not taken into consideration when using new rtp header extensions.

Best regards
Sergio

Roni

From: Justin Uberti [mailto:[email-masked]]
Sent: יום א 23 אפריל 2017 21:48
To: Roni Even
Cc: Sergio Garcia Murillo; [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Mon, 24 Apr 2017 11:08:45 +0200

AFAIK, FEC (at least ulpfec) protects the full packet, including header 
extensions. When we are addressing the usage of RED vs FEC for audio we 
should note the difference in behavior  and it's possible consequences.

Best regards
Sergio

On 24/04/2017 11:04, Roni Even wrote:
>
> Hi Sergio,
>
> What I said that the redundancy of RTP header extensions in not a FEC 
> issue. FEC addresses the payload and not the RTP header.  RTP header 
> extensions are discussed in the RFC5285-bis draft and each new RTP 
> header extension must address the issue of loss since RTP over UDP is 
> unreliable.
>
> I am not sure we need any text in rtcweb-fec about RTP header 
> extensions.  General RTP usage in RTCweb is in the RTCweb RTP usage 
> and this is where general redundancy of RTP is discussed, and as a 
> general RTP usage it points at redundancy for payload and for RTP 
> header extensions reference RFC5285 (rfc5285-bis will obsolete it and 
> have a section about transmission consideration.
>
> In this rtcweb-fec document audio/red is a payload; it is not an RTP 
> packet for which you need to address the RTP header redundancy.
>
> Roni Even
>
> *From:*Sergio Garcia Murillo [mailto:[email-masked]]
> *Sent:* יום ב 24 אפריל 2017 11:28
> *To:* Roni Even; Justin Uberti
> *Cc:* [email-masked]
> red/audio, also webrtc-rtp-usage references the fec draft when 
> speaking about redundancy.
>
> Also, please note that I am not proposing to change current RED 
> behavior or its usage within webrtc, just proposing to add a "warning" 
> note to make it implicit what is the current situation: When using rtp 
> red for audio, only payload is protected, and rtp headers are not, 
> which is almost harmless currently but could cause some issues in the 
> future if not taken into consideration when using new rtp header 
> extensions.
>
> Best regards
> Sergio
>
>     If you still want to say something you can probably add to section
>     1 “ Web Real-Time Communication (WebRTC) Media Transport and Use
>     of RTP are discussed in
>     *Cc:* Sergio Garcia Murillo; [email-masked] <mailto:[email-masked]>
>     extensions reliability discussed in RFC5285 and RC5285-bis draft
>     and in the specific RTP header extension.
>

---

From: Roni Even <[email-masked]>
Date: Mon, 24 Apr 2017 09:59:12 +0000

Hi Sergio,
I understand your distinction between FEC (ulpfec) and  RED with regards to the RTP header. Still, the RTP header extensions have their own redundancy recommendations so they less less problem for packet loss.
Maybe it will be good in section 3 to add a section that mention that FEC will protect the whole RTP packet while RED and in-band fec will only protect the RTP payload.

Roni

From: Sergio Garcia Murillo [mailto:[email-masked]]
Sent: יום ב 24 אפריל 2017 12:09
To: Roni Even; Justin Uberti
Cc: [email-masked]
Subject: Re: [rtcweb] Review comments on draft-ietf-rtcweb-fec-04

AFAIK, FEC (at least ulpfec) protects the full packet, including header extensions. When we are addressing the usage of RED vs FEC for audio we should note the difference in behavior  and it's possible consequences.

Best regards
Sergio

Roni Even

Cc: [email-masked]<mailto:[email-masked]>

Hi Roni,

Best regards
Sergio

Roni

---

From: Justin Uberti <[email-masked]>
Date: Mon, 24 Apr 2017 11:15:38 -0700

The differences in protection that you mention are what I was planning to
discuss in the new text.

On Mon, Apr 24, 2017 at 2:59 AM, Roni Even <[email-masked]> wrote:

> Hi Sergio,
>
> I understand your distinction between FEC (ulpfec) and  RED with regards
> to the RTP header. Still, the RTP header extensions have their own
> redundancy recommendations so they less less problem for packet loss.
>
> Maybe it will be good in section 3 to add a section that mention that FEC
> will protect the whole RTP packet while RED and in-band fec will only
> protect the RTP payload.
>
>
>
>
>
> Roni
>
>
>
> *From:* Sergio Garcia Murillo [mailto:[email-masked]]
> *Sent:* יום ב 24 אפריל 2017 12:09
> extensions are discussed in the RFC5285-bis draft and each new RTP header
> extension must address the issue of loss since RTP over UDP is unreliable.
>
> I am not sure we need any text in rtcweb-fec about RTP header extensions.
> General RTP usage in RTCweb is in the RTCweb RTP usage and this is where
> general redundancy of RTP is discussed, and as a general RTP usage it
> points at redundancy for payload and for RTP header extensions reference
> RFC5285 (rfc5285-bis will obsolete it and have a section about transmission
> consideration.
>
>
>
> *From:* Sergio Garcia Murillo [mailto:[email-masked]
> <[email-masked]>]
> Not following you. Neither RFC 5265 nor RFC 5265-bis references red/audio,
> also webrtc-rtp-usage references the fec draft when speaking about
> redundancy.
>
> or its usage within webrtc, just proposing to add a "warning" note to make
> it implicit what is the current situation: When using rtp red for audio,
> only payload is protected, and rtp headers are not, which is almost
> harmless currently but could cause some issues in the future if not taken
> into consideration when using new rtp header extensions.
>
> Best regards
> Sergio
>
> extensions are discussed in https://tools.ietf.org/html/
> draft-ietf-rtcweb-rtp-usage-26 , which points to RFC5285 soon to be
> replaced  by the rfc5285-bis draft.
>
> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5285-
> bis-09#section-4.1.1 discussing reliability of RTP header extension
> delivery by sending them in multiple RTP packets.
>
>
>
> If you still want to say something you can probably add to section 1 “ Web
> Real-Time Communication (WebRTC) Media Transport and Use of RTP are
> discussed in https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-26”
>
>
>
> Roni
>
>
>
>
>
> *From:* Justin Uberti [mailto:[email-masked] <[email-masked]>]

---

From: Justin Uberti <[email-masked]>
Date: Mon, 24 Apr 2017 11:31:38 -0700

Agree - the differences in protection that you mention are what I was
planning to discuss in the new text.