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

[Bernard Aboba <[e-mail]>]

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 <[e-mail]>
wrote:

> > 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 <[e-mail]>
> *Sent:* Sunday, February 3, 2019 7:48 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; IETF discussion list <[e-mail]>;
> [e-mail]
> *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:
>
>       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 <[e-mail]>
> 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
> [e-mail] 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?
>
>
>
>
>
>