Subject: [payload] TSVART telechat review of draft-ietf-payload-flexible-fec-scheme-16

From: Bernard Aboba <[email-masked]>
Date: Sun, 3 Feb 2019 22:29:31 -0500

Reviewer:  Bernard Aboba
Review result:  Needs clarifications

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the
IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

Document: draft-ietf-payload-flexible-fec-scheme-16

My reading of the document raised questions relating to implementation
requirements as well as the configuration and use of the Flexible Mask mode
(R=0, F=0).  Presumably, this mode can be used to choose arbitrary packets
to protect. There is not much discussion of flexible mode early in the
document, and no use cases are presented relating to this mode.  However,
it would appear to me that flexible mode can be used to implement scenarios
such as differential protection for Scalable Video Coding.

For example, the sender could use flexible mode to only protect base layer
packets by using a flexible mask to select only packets sent with TID = 0
and SID = 0.  Since with flexible mode the mask is not negotiated and thus
can be varied on the fly, it would appear to me that differential
protection can be provided even in situations where the number of layers
encoded (and even the temporal/spatial encoding mode) vary on the fly.

If this interpretation is correct, I would suggest adding a section after
1.1.4 covering the flexible mask mode and a differential protection use
case for it.
It also would appear to me that flexible mode could be used to implement
dynamic FEC, but I'll leave it to the authors to decide whether to mention
that use case.

With respect to SDP parameters (L, D, ToP) defined in Section 5.1.1, I was
unclear on several points:

1. Is it possible to configure a ToP value to indicate that the sender
desires to utilize both FEC and retransmission?  Or must the sender choose
to utilize this payload for one or the other but not both?

2. What happens if both RTX and flexible FEC with retransmission are
Offered in SDP?  Could this result in the sender being allowed to send both
types of retransmission (though presumably only one at a time)?  Are the
type(s) of retransmission used determined by which retransmission schemes
are provided in the Answer?

3. If L and D are not specified, does this imply that the sender will
operate in flexible mode?  Are implementations of the specification
required to support all of the modes except for the F=1, R=1 mode that is
forbidden?  If not, how does an Answerer indicate that it doesn't support
the mode that is Offered?

4. Does the negotiation of L, D and ToP in SDP imply that the sender cannot
switch to use of another configuration without renegotiation?  Since the
flexible FEC format is self-describing, it would appear to me that
switching should be possible as long as the implementation requirements are
clear.  For example, do all implementations needs to support all mask
sizes?

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 3 Feb 2019 22:48:26 -0500

Some additional notes:

1. The spec says that absence of a ToP value means that any ToP is
allowable, but it doesn't explicitly say that implementations needs to
support all ToP types.  So I was unclear whether it might be necessary to
Offer multiple potential flexible FEC configurations so as to be able to
negotiate what ToP values each side can handle, and if so, how this would
work. Personally, things would be simpler if the spec were to mandate
support for as many features as possible so as to avoid the need to put
multiple potential configurations into an Offer.

2. With respect to Offer/Answer, Section 5.2.1 strikes me as potentially
quite complex:

      Each combination of the L and D parameters produces a different
      FEC data and is not compatible with any other combination.  A
      sender application may desire to offer multiple offers with
      different sets of L and D values as long as the parameter values
      are valid.  The receiver SHOULD choose the offer that has a
      sufficient amount of interleaving.  If multiple such offers exist,
      the receiver may choose the offer that has the lowest overhead or
      the one that requires the smallest amount of buffering.  The
      selection depends on the application requirements.

[BA] By "multiple Offers" I presume you are not talking about multiple
rounds of O/A or multiple Offers sent at once,
but rather multiple SDP lines describing potential configurations.  In
this paragraph, "choosing" the offer
presumably refers to the configurations that are provided in the
Answer?  What if the Answerer wants to utilize a very
configuration from what is in the Offer?

On Sun, Feb 3, 2019 at 10:29 PM Bernard Aboba <[email-masked]>
wrote:

> 4. Does the negotiation of L, D and ToP in SDP imply that the sender
> cannot switch to use of another configuration without renegotiation?  Since
> the flexible FEC format is self-describing, it would appear to me that

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 4 Feb 2019 05:25:29 +0000

> What if the Answerer wants to utilize a very configuration from what is in the Offer?

What is “a very configuration” actually meant to convey?  Did you mean “every configuration”?

Thanks,

-Giri Mandyam

From: Bernard Aboba <[email-masked]>
Sent: Sunday, February 3, 2019 7:48 PM
To: [email-masked]
Cc: [email-masked]; IETF discussion list <[email-masked]>; [email-masked]
Subject: Re: TSVART telechat review of draft-ietf-payload-flexible-fec-scheme-16

CAUTION: This email originated from outside of the organization.
Some additional notes:

1. The spec says that absence of a ToP value means that any ToP is allowable, but it doesn't explicitly say that implementations needs to support all ToP types.  So I was unclear whether it might be necessary to Offer multiple potential flexible FEC configurations so as to be able to negotiate what ToP values each side can handle, and if so, how this would work. Personally, things would be simpler if the spec were to mandate support for as many features as possible so as to avoid the need to put multiple potential configurations into an Offer.

2. With respect to Offer/Answer, Section 5.2.1 strikes me as potentially quite complex:

[BA] By "multiple Offers" I presume you are not talking about multiple rounds of O/A or multiple Offers sent at once,

but rather multiple SDP lines describing potential configurations.  In this paragraph, "choosing" the offer

presumably refers to the configurations that are provided in the Answer?  What if the Answerer wants to utilize a very

On Sun, Feb 3, 2019 at 10:29 PM Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
Reviewer:  Bernard Aboba
Review result:  Needs clarifications

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked]<mailto:[email-masked]> if you reply to or forward this review.

My reading of the document raised questions relating to implementation requirements as well as the configuration and use of the Flexible Mask mode (R=0, F=0).  Presumably, this mode can be used to choose arbitrary packets to protect. There is not much discussion of flexible mode early in the document, and no use cases are presented relating to this mode.  However, it would appear to me that flexible mode can be used to implement scenarios such as differential protection for Scalable Video Coding.

For example, the sender could use flexible mode to only protect base layer packets by using a flexible mask to select only packets sent with TID = 0 and SID = 0.  Since with flexible mode the mask is not negotiated and thus can be varied on the fly, it would appear to me that differential protection can be provided even in situations where the number of layers encoded (and even the temporal/spatial encoding mode) vary on the fly.

If this interpretation is correct, I would suggest adding a section after 1.1.4 covering the flexible mask mode and a differential protection use case for it.
It also would appear to me that flexible mode could be used to implement dynamic FEC, but I'll leave it to the authors to decide whether to mention that use case.

With respect to SDP parameters (L, D, ToP) defined in Section 5.1.1, I was unclear on several points:

1. Is it possible to configure a ToP value to indicate that the sender desires to utilize both FEC and retransmission?  Or must the sender choose to utilize this payload for one or the other but not both?

2. What happens if both RTX and flexible FEC with retransmission are Offered in SDP?  Could this result in the sender being allowed to send both types of retransmission (though presumably only one at a time)?  Are the type(s) of retransmission used determined by which retransmission schemes are provided in the Answer?

3. If L and D are not specified, does this imply that the sender will operate in flexible mode?  Are implementations of the specification required to support all of the modes except for the F=1, R=1 mode that is forbidden?  If not, how does an Answerer indicate that it doesn't support the mode that is Offered?

4. Does the negotiation of L, D and ToP in SDP imply that the sender cannot switch to use of another configuration without renegotiation?  Since the flexible FEC format is self-describing, it would appear to me that switching should be possible as long as the implementation requirements are clear.  For example, do all implementations needs to support all mask sizes?

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 4 Feb 2019 00:35:50 -0500

Meant very different. For example, in a conferencing scenario a participant
sends SVC with differential protection via flexible mode and the
conferencing server sends a single layer with 2D.

On Mon, Feb 4, 2019 at 12:31 AM Giridhar Mandyam <[email-masked]>
wrote:

> *From:* Bernard Aboba <[email-masked]>
> *Sent:* Sunday, February 3, 2019 7:48 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; IETF discussion list <[email-masked]>;
> [email-masked]
> *Subject:* Re: TSVART telechat review of
> draft-ietf-payload-flexible-fec-scheme-16
>
>
>
> *CAUTION*: This email originated from outside of the organization.
>
> Some additional notes:
>
>
>

---

From: Giridhar Mandyam <[email-masked]>
Date: Mon, 11 Feb 2019 16:39:28 +0000

Hello,
For these two specific comments, the editors’ response is enclosed below.  There will be a separate email regarding the other TSVART questions on FLEX FEC.
-Giri Mandyam
>1. The spec says that absence of a ToP value means that any ToP is allowable, but it doesn't explicitly say that implementations needs to support all ToP types.  So I was unclear whether it might be…
 It may not be possible to support all ToP types for arbitrary repair windows for all classes of FLEX FEC endpoints, so mandating support does not look feasible.  An Offerer can choose to offer multiple m-lines (streams) to allow for ToP flexibility, and the Answerer can choose to reject unsupported ToP’s (see https://tools.ietf.org/html/rfc3264#section-6, “An offered stream MAY be rejected in the answer …”).

Yes, multiple SDP lines was the intent.  Choosing the offer corresponds to accepting/rejecting m-lines as per RFC 3264.  The Answerer can choose to initiate a FLEX FEC session based on the initial Offer, but modify the session by making its own Offer if the chosen configuration is undesirable.  In addition, non-SDP signaling is always possible between the endpoints if the Answerer does not find the offered streams suitable.  But such signaling is beyond the scope of this specification.

From: Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 3, 2019 9:36 PM
To: Giridhar Mandyam <[email-masked]<mailto:[email-masked]>>
Cc: IETF discussion list <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: TSVART telechat review of draft-ietf-payload-flexible-fec-scheme-16

Meant very different. For example, in a conferencing scenario a participant sends SVC with differential protection via flexible mode and the conferencing server sends a single layer with 2D.

Thanks,

-Giri Mandyam

From: Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Sent: Sunday, February 3, 2019 7:48 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; IETF discussion list <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: TSVART telechat review of draft-ietf-payload-flexible-fec-scheme-16