Subject: [payload] Update on FLEX FEC (ver -20)

From: Giridhar Mandyam <[email-masked]>
Date: Thu, 16 May 2019 23:00:13 +0000

Hello,
Please note that a new version addressing the comment below has been uploaded.

Thanks,

-Giri Mandyam

From: Bernard Aboba <[email-masked]>
Sent: Tuesday, April 2, 2019 10:55 AM
To: Ali C. Begen <[email-masked]>
Cc: Giridhar Mandyam <[email-masked]>; [email-masked]
Subject: Re: [payload] Updates on FLEX FEC (ver -19)

CAUTION: This email originated from outside of the organization.
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]<mailto:[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.

On Thu, Mar 28, 2019 at 9:19 PM Giridhar Mandyam <[email-masked]<mailto:[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]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/payload
_______________________________________________
payload mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/payload