Subject: Re: [payload] Updates on FLEX FEC (ver -19)

From: "Ali C. Begen" <[email-masked]>
Date: Tue, 2 Apr 2019 01:57:32 +0300

Folks, please provide feedback. There are important changes in the flex fec
and in a few days, the draft will be shipped to the RFC editor.

Thanks.

On Thu, Mar 28, 2019 at 9:19 PM Giridhar Mandyam <[email-masked]>
wrote:

> Dear Payload WG,
>
> After offline discussion with the editors and reviewers (special thanks to
> Bernard Aboba), we have decided that the spec needed to be slightly
> modified.  Version -19 contains the following changes:
>
> a) Recommendation against negotiation of RTP RTX when FLEX FEC is used.  A
> new section 1.1.7 on the use of FLEX FEC retransmissions has been added to
> indicate as such.
>
> b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields).
> This means that the sender can send any FEC configuration (as indicated by
> the FEC header) as long as it stays consistent with the mandatory SDP
> parameters (rate and repair window).  Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are
> the primary impacted sections.  We believe this will greatly simplify SDP
> O/A and while retaining the "flexibility" of FLEX FEC to adapt FEC repair
> data on a packet-by-packet basis.
>         - Note that L and D cannot be larger than 255, respectively.  As
> we gain implementation experience, if we decide that 255 is not sufficient
> then it could be possible to extend the corresponding header fields in the
> future. Currently there are header values that are reserved (R=F=1 and
> L=D=0) that could be used to indicate the use of an extended L and D field,
> as an example of one way to implement extended fields for L and D.
>
> c) Slight adjustment of Sec. 6.3.1.2 to correct for sequence numbering
> errors in the abstract procedure for grouping of source packets using their
> RTP sequence numbers.
>
> d) Accounting for the remaining nit's in Benjamin Kaduk's last review.
>
> e) Explicitly defining "FLEX FEC" in the abstract.
>
> Please provide any feedback within 7 days of the sending of this
> notification.
>
> Thank you,
>
> -The Editors of FLEX FEC
>
>
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 2 Apr 2019 10:59:14 -0600

> On Mar 28, 2019, at 12:18 PM, Giridhar Mandyam <[email-masked]> wrote:
> 
> b) Elimination of all optional SDP parameters (e.g. ToP, L and D fields).  This means that the sender can send any FEC configuration (as indicated by the FEC header) as long as it stays consistent with the mandatory SDP parameters (rate and repair window).  Sec. 1.1.6, 1.1.7, 4.2.2, and 5 are the primary impacted sections.  We believe this will greatly simplify SDP O/A and while retaining the "flexibility" of FLEX FEC to adapt FEC repair data on a packet-by-packet basis. 
> 	- Note that L and D cannot be larger than 255, respectively.  As we gain implementation experience, if we decide that 255 is not sufficient then it could be possible to extend the corresponding header fields in the future. Currently there are header values that are reserved (R=F=1 and  L=D=0) that could be used to indicate the use of an extended L and D field, as an example of one way to implement extended fields for L and D.

I’m strongly apposed to making this huge change at this late stage. It means the receiver has no ability to influence the FEC even thought on small device it may need to. It is just as important for the receiver to be able to have influence over what happens as the sender. We should not remove this. Removing this will cause some people to just keep using old FEC schemes instead of moving to something even as simply 1D with flex fec. 

I know we wish everyone would implement the most advanced version of everything we specify, but this will have the opposite effect of just deciding not to implement it at all.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 2 Apr 2019 13:54:45 -0400

Here is my feedback.

IMHO the new draft is an improvement, because it makes clear what is
mandatory to implement (almost everything) as well as clarifying the SDP
negotiation (which seemed quite unclear before).

Both of these issues had been encountered in implementations and were
likely to lead to interoperability problems.

The clarifications do raise the bar in terms of what an implementation
needs to be able to handle, but AFAICT not to an unreachable level (at
least in a browser or a game console environment).

In terms of specific comments:

1.1.7 <https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-19#section-1.1.7>.
FEC Protection with Retransmission

   This specification supports both forward error correction, i.e.
   before any loss is reported, as well as retransmission of source
   packets after loss is reported.  The retransmission includes the RTP
   header of the source packet in addition to the payload.  Therefore,
   endpoints supporting other RTP retransmission methods (see [RFC4588
<https://tools.ietf.org/html/rfc4588>])
   in addition to FLEX FEC MUST only use the FLEX FEC retransmission
   method.

[BA] I would like to see this rephrased in Offer/Answer terminology.
For example,

"If a peer supporting both FLEX FEC and other RTP retransmission
methods (see [RFC4588])

receives an Offer including both FLEX FEC and another RTP
retransmission method, it

MUST respond with an Answer containing only FLEX FEC."

On Mon, Apr 1, 2019 at 6:57 PM Ali C. Begen <[email-masked]>
wrote:

> Folks, please provide feedback. There are important changes in the flex
> fec and in a few days, the draft will be shipped to the RFC editor.
>
> Thanks.
>
>> After offline discussion with the editors and reviewers (special thanks
>> to Bernard Aboba), we have decided that the spec needed to be slightly
>> a) Recommendation against negotiation of RTP RTX when FLEX FEC is used.
>> A new section 1.1.7 on the use of FLEX FEC retransmissions has been added
>> to indicate as such.
>>
>> b) Elimination of all optional SDP parameters (e.g. ToP, L and D
>> fields).  This means that the sender can send any FEC configuration (as
>> indicated by the FEC header) as long as it stays consistent with the
>> mandatory SDP parameters (rate and repair window).  Sec. 1.1.6, 1.1.7,
>> 4.2.2, and 5 are the primary impacted sections.  We believe this will
>> greatly simplify SDP O/A and while retaining the "flexibility" of FLEX FEC
>> to adapt FEC repair data on a packet-by-packet basis.