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

From: Justin Uberti <[email-masked]>
Date: Tue, 4 Jul 2017 19:45:20 -0700

This is now addressed in the latest version of the draft -
https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06, Section 3.

On Mon, Apr 24, 2017 at 11:31 AM, Justin Uberti <[email-masked]> wrote:

> Agree - 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
>> *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
>>
>> 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]
>> <[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
>>
>> 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/dr
>> aft-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] <[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]> wrote:
>>
>> 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 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.
>>
>>
>> [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?
>>
>>
>>
>> >
>> > 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
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>>
>>
>>
>>
>
>

---

From: Justin Uberti <[email-masked]>
Date: Tue, 4 Jul 2017 19:46:09 -0700

Thanks for the review. These issues have all been resolved in the latest
version of the draft, https://tools.ietf.org/html/draft-ietf-rtcweb-fec-06.

On Sat, Apr 22, 2017 at 12:46 PM, Justin Uberti <[email-masked]> wrote:

>
>
> On Fri, Apr 21, 2017 at 2:07 AM, Magnus Westerlund <
> [email-masked]> wrote:
>
>> Hi,
>>
>> I have review the -04 version of the FEC. I think the document is mostly
>> done. I only have these few comments that should be addressed before going
>> forward.
>>
>> 1. Section 4.2:
>>
>>    Support for redundant encoding MUST be indicated by offering "red" as
>>    a supported payload type in the offer.
>>
>> I think it is unclear what "red" refers to here. This as it is not made
>> clear that RFC 2198 has the media type audio/red and text/red. I think
>> there are two things that would make this clearer. One would be to change
>> "red" into media type "audio/red". The other would be to add the reference
>> afterwards.
>
>
> Adding the reference seems like a good idea. With that, the fact that it
> is audio/red seems implicit.
>
> https://github.com/juberti/draughts/issues/46
>
>>
>
>
>> 2. Section 12.1:
>>
>> It is missing this normative reference: [3GPP.26.114]
>>
>
> Agreed. I need to remember how to format such non-IETF references.
>
> https://github.com/juberti/draughts/issues/28
>
>>
>> 3. Section 12.1:
>>
>> I think that the following references have usages in the text that make
>> them normative:
>>
>> [RFC7587] and [RFC4867]
>>
>
> Agreed.
>
> https://github.com/juberti/draughts/issues/47
>