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

[Bernard Aboba <[e-mail]>]

1. " Suggested additional section (new 1.1.5):"

[BA] Thank you.  This looks good.

"It is not possible to configure a ToP value that allows the sender to send
both FEC and rtx, and all valid values for ToP are listed in the spec.
This is what is meant by the current text under ToP for each type
registration:   “There can only be one value listed for ToP.”  An offer
that attempts to list multiple ToP values must be rejected. We can add the
clarifying sentence:  “An offer that lists more than one ToP value MUST be
rejected.”

[BA] The "MUST be rejected" clarification seems helpful.  If ToP is not
contained in the Offer (as shown in the Example in Section 7.1.1), Section
5.1.4 says:

      The absence of the ToP field means that all protection types are
      allowed.


So by not including a ToP value in the Offer, it would be possible to
use flexfec for both FEC and retransmission, correct?


BTW, if no ToP value is provided in the Offer, does the ToP value in
the Answer determine what is used?  And if there is no ToP value in
the Answer, then anything is ok?


2. RTX and flexfec retransmission.

"If by RTX you mean the use of RTP RTX for retransmission of repair
packets, then this is not prohibited by the spec but is not a configuration
that the editors anticipate will be widely-used."

[BA] Agree that it makes little sense to negotiate both conventional RTX
and flexfec retransmission, but I wanted to understand how the negotiation
would work in a scenario where the Offerer did not know whether the
Answerer supported flexfec and therefore offered both RTX and flexfec (with
no ToP value).

Can the Answerer assume that not including ToP means that the Offerer
supports flexfec retransmission and well as forward error correction?

Assuming that the Answerer would prefer to use flexfec retransmission
instead of conventional RTX and that it didn't want FEC, would the Answerer
then respond with ToP indicating a desire for flexfec retransmission (and
no RTX, so that conventional retransmission is turned off)?

3. Flexible mode.

"If L and D are not specified in the SDP, then the sender will utilize a
flexible mask (assuming rtx is not selected)."

[BA] If neither Offer nor Answer contain ToP for retransmission, does that
count as "rtx is not selected"?  Or is it necessary to explicitly select
ToP for forward error correction so as to rule out retransmission?

"Implementations are not required to support all F/R combinations as there
may be implementations limitations depending on the repair window offered
(e.g. insufficient buffer space).  The answerer can indicate lack of
support through rejection using the methodology described in
https://tools.ietf.org/html/rfc3264#section-6."

[BA] If L and D are not specified in the SDP offer, is that considered an
indication that the Offerer can both send and receive flexible mask?  Is
the presence of L and D an indication that it does not support flexible
mask?



On Mon, Feb 11, 2019 at 11:02 AM Giridhar Mandyam <[e-mail]>
wrote:

>
>
>
>
> Thank you for the careful review.  Enclosed are proposed responses.
>
>
>
> > 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.
>
>
>
> Suggested additional section (new 1.1.5):
>
>
>
> 1.1.5 FEC Protection with Flexible Mask
>
>
>
> It is possible to define FEC protection for selected packets in the source
> stream.  This would enable differential protection, i.e. application of FEC
> selectively to packets that require a higher level of reliability then the
> other packets in the source stream.  The sender will be required to send a
> bitmap indicating the packets to be protected, i.e. a “mask”, to the
> receiver.  Since the mask can be modified during an RTP session (“flexible
> mask”), this kind of FEC protection can also be used to implement FEC
> dynamically (e.g. for adaptation to different types of traffic during the
> RTP session).
>
>
>
> >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?
>
>
>
> It is not possible to configure a ToP value that allows the sender to send both FEC and rtx, and all valid values for ToP are listed in the spec.  This is what is meant by the current text under ToP for each type registration:   “There can only be one value listed for ToP.”  An offer that attempts to list multiple ToP values must be rejected. We can add the clarifying sentence:  “An offer that lists more than one ToP value MUST be rejected.”
>
>
>
> >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?
>
>
>
> We assume by RTX you mean the RTP RTX option, but specifically for source packets.  It is possible to offer RTP RTX and FLEX FEC in an offer.  An example of when such an offer is appropriate is if the FLEX FEC RTX fails to recover the packet, and RTP RTX is required to recover the packet for a given application that requires a corresponding level of reliability.  If by RTX you mean the use of RTP RTX for retransmission of repair packets, then this is not prohibited by the spec but is not a configuration that the editors anticipate will be widely-used.
>
>
>
> >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?
>
>
>
> If L and D are not specified in the SDP, then the sender will utilize a flexible mask (assuming rtx is not selected).  Implementations are not required to support all F/R combinations as there may be implementations limitations depending on the repair window offered (e.g. insufficient buffer space).  The answerer can indicate lack of support through rejection using the methodology described in https://tools.ietf.org/html/rfc3264#section-6.
>
>
>
> >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?
>
>
>
> Switching without re-negotiation may not be possible unless the sender is aware of the capabilities of the receiver e.g. through out-of-band information.  If the sender does not have full information on receiver capabilities, then re-negotiation may be necessary as per the procedures of  https://tools.ietf.org/html/rfc3264#section-8.
>
>
>
> *From:* Bernard Aboba <[e-mail]>
> *Sent:* Sunday, February 3, 2019 7:30 PM
> *To:* [e-mail]
> *Cc:* [e-mail]; IETF discussion list <[e-mail]>;
> [e-mail]
> *Subject:* TSVART telechat review of
> draft-ietf-payload-flexible-fec-scheme-16
>
>
>
> 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?
>
>
>
>
>
>