Re: [Fecframe] FEC Framework DISCUSSes (was RE: Ops/Management Cons. text for fecframe)

["Ali C. Begen (abegen)" <[e-mail]>]

Hi David,

> -----Original Message-----
> From: David Harrington [mailto:[e-mail]]
> Sent: Sunday, May 15, 2011 11:48 AM
> To: Ali C. Begen (abegen)
> Cc: [e-mail]; [e-mail]
> Subject: RE: FEC Framework DISCUSSes (was RE: [Fecframe] Ops/Management Cons. text for fecframe)
> 
> Hi,
> 
> I updated my DISCUSS for the -14- revision.
> I think it is still lacking.
> 
> Part of the problem is that the recommendation section is written
> using passive voice rather
> than active voice, so it is unclear who should do what. It should be
> clearer
> what ***actions*** SHOULD be taken by the implementations of
> recievers, senders,
> and middleboxes.
> 
> Here are my suggestions for 10.2:
> 
> 1)
> OLD:
>    Overall, from the discussion of Section 10.1, it is clear that the
>    CDPs and FEC schemes compatible with the FEC Framework widely
> differ
>    in their capabilities, application and deployment scenarios such
> that
>    a common operation and management method or protocol that works
> well
>    for all of them would be too complex to define.  Thus, as a design
>    choice, the FEC Framework does not dictate the use of any
> particular
>    technology or protocol for transporting FEC data, managing the
> hosts,
>    signaling the configuration information or encoding the
> configuration
>    information.  This provides flexibility and is one of the main
> goals
>    of the FEC Framework.  However, this section gives some
>    recommendations.
> NEW:
>    Overall, from the discussion of Section 10.1, it is clear that the
>    CDPs and FEC schemes compatible with the FEC Framework widely
> differ
>    in their capabilities, application and deployment scenarios such
> that
>    a common operation and management method or protocol that works
> well
>    for all of them would be too complex to define.  Thus, as a design
>    choice, the FEC Framework does not dictate the use of any
> particular
>    technology or protocol for transporting FEC data, managing the
> hosts,
>    signaling the configuration information or encoding the
> configuration
>    information.  This provides flexibility and is one of the main
> goals
>    of the FEC Framework.
> 
>    However, this section gives some RECOMMENDATIONS. From RCF2119
> "Best
>    Current Practices for RFC Key Words":
>      "SHOULD   This word, or the adjective "RECOMMENDED", mean that
> there
>       may exist valid reasons in particular circumstances to ignore a
>       particular item, but the full implications must be understood
> and
>       carefully weighed before choosing a different course."
>    Where a technology is RECOMMENDED, an implementer SHOULD include
> the
>    technology in their implementation, so end users will have
>    the option of enabling it when the situation calls for it. If an
>    implementer feels that their implementation is not likely to be
> used
>    in the relevant scenario, that would be a valid reason not to
> implement
>    the RECOMMENDED technology in their implementation.

OK, we will make "recommendations" uppercase.
 
> 2)
> OLD:
>  o  A Single Small Generic Component within a Larger (and Often
>       Legacy) Solution: It is anticipated that the FEC Framework will
>       often be used to protect one or several RTP streams.  Therefore,
>       there are use cases that may take advantage of RTCP to collect
>       feedback information, and one can take advantage of the tools
>       using (or used by) RTCP to operate and manage the FEC Framework
>       instance along with the associated FEC schemes.
> NEW:
>  o  A Single Small Generic Component within a Larger (and Often
>       Legacy) Solution: It is anticipated that the FEC Framework will
>       often be used to protect one or several RTP streams.  Therefore,
>       Implementations SHOULD make feedback information accessible via
>       RTCP to enable users to take advantage of the tools
>       using (or used by) RTCP to operate and manage the FEC Framework
>       instance along with the associated FEC schemes.

This is also fine.
 
> 3)
> OLD:
>    o  One-to-One with Feedback vs. One-to-Many with Feedback vs.
> One-to-
>       Many without Feedback Scenarios: With use cases that are
> one-way,
>       the FEC Framework sender does not have any way to gather
> feedback
>       from receivers.  With use cases that are bidirectional, the FEC
>       Framework sender can collect detailed feedback (e.g., in case of
> a
>       one-to-one scenario) or at least occasional feedback (e.g., in
>       case of a multicast, one-to-many scenario).  All these
>       applications have naturally different operational and management
>       aspects.  If any, they also have different requirements or
>       features for collecting feedback, processing it and acting on
> it.
>       The data structures for carrying the feedback also vary.
> NEW:
>    o  One-to-One with Feedback vs. One-to-Many with Feedback vs.
> One-to-
>       Many without Feedback Scenarios: With use cases that are
> one-way,
>       the FEC Framework sender does not have any way to gather
> feedback
>       from receivers. With use cases that are bidirectional, the FEC
>       Framework sender can collect detailed feedback (e.g., in case of
> a
>       one-to-one scenario) or at least occasional feedback (e.g., in
>       case of a multicast, one-to-many scenario).  All these
>       applications have naturally different operational and management
>       aspects.  If any, they also have different requirements or
>       features for collecting feedback, processing it and acting on
> it.
>       The data structures for carrying the feedback also vary.
> 
>       Implementers SHOULD make feedback available using an in-band or
>       out-of-band asynchronous reporting mechanism. A standardized
>       reporting mechanism, such as syslog or SNMP notifications, is
>       RECOMMENDED.

OK, will add this last paragraph.
 
> 4)
> OLD:
>    o  Non-FEC Framework Capable Receivers: Section 5.3 gives
>       recommendations on how to provide backward compatibility in
>       presence of receivers that cannot support the FEC scheme being
>       used, or the FEC Framework itself: basically the use of Explicit
>       Source FEC Payload ID is banned.  Additionally, a non-FEC
>       Framework capable receiver MUST also have a means not to receive
>       the repair packets that it will not be able to decode in the
> first
>       place or a means to identify and discard them appropriately upon
>       receiving them.  This can be achieved by sending repair packets
> on
>       a different transport-layer flow.  In case of an RTP source
> flow,
>       this can also be achieved by using an RTP framing for FEC repair
>       packets with a different payload type.  Both source and repair
>       packets can then be sent on the same transport-layer flow.  It
> is
>       the responsibility of the sender to select the appropriate
>       mechanism when needed.
> NEW:
>    o  Non-FEC Framework Capable Receivers: Section 5.3 gives
>       recommendations on how to provide backward compatibility in
>       presence of receivers that cannot support the FEC scheme being
>       used, or the FEC Framework itself: basically the use of Explicit
>       Source FEC Payload ID is banned.  Additionally, a non-FEC
>       Framework capable receiver MUST also have a means not to receive
>       the repair packets that it will not be able to decode in the
> first
>       place or a means to identify and discard them appropriately upon
>       receiving them.  This SHOULD be achieved by sending repair
> packets on
>       a different transport-layer flow.  In case of an RTP source
> flow,
>       this SHOULD be achieved by using an RTP framing for FEC repair
>       packets with a different payload type.  Both source and repair
>       packets can then be sent on the same transport-layer flow.  It
> is
>       the responsibility of the sender to select the appropriate
>       mechanism when needed.

Actually, in case of RTP, source and repair flows can still be still in different transport-layer flows. So, I suggest:

"In case of RTP transport and if both source and repair packets will be sent on the same transport-layer flow, this SHOULD be achieved by using an RTP framing for FEC repair packets with a different payload type."

Ok with this?
 
> 5)
> OLD:
>       The recommendation for the sending side is particularly
> important
>       with FEC schemes that do not modify the ADU for backward
>       compatibility purposes (i.e. do not use any Explicit Source FEC
>       Payload ID) and rely for instance on the RTP sequence number
> field
>       to identify FEC source packets within their source block.  In
> this
>       case, packet loss or packet reordering leads to a gap in the RTP
>       sequence number space seen by the FECFRAME instance.  Similarly,
>       varying delay in delivering packets over this path can lead to
>       significant timing issues.  With FEC schemes that indicate in
> the
>       Repair FEC Payload ID, for each source block, the base RTP
>       sequence number and number of consecutive RTP packets that
> belong
>       to this source block, a missing ADU or an ADU delivered out of
>       order could cause the FECFRAME sender to switch to a new source
>       block.  However, some FEC schemes and/or receivers may not
>       necessarily handle such varying source block sizes.  In this
> case,
>       another solution SHOULD be considered that is use-case specific
>       and whose consequences need to be carefully considered (e.g., by
>       duplicating the last ADU received before the loss, or by
> inserting
>       a zero'ed ADU, depending on the ADU flow nature).
> 
> I don't knowe how to propose a NEW section for this text, because I do
> not understand this text.
> The paragraph starts with "the recommendation is particularly
> importat, but then never seems to actually make a recommendation. and
> then it suggest that "another solution SHOULD" be used. Another as
> comperade to what? what is
> the first recommended solution?

So for the fec schemes that indicate a base seqnum and number of consecutive RTP packets for each source block, there is no problem. A missing/late ADU may cause the sender to ship a smaller source block. If the fec scheme can handle this, this does not create a problem.

A problem raises if the fec scheme cannot handle varying size of source blocks. For those, a solution is to put empty ADUs or repeating the last ADU to make up for the full size. Whether the implementer should do one of these depends on the use case.

I suggest:

... However, some FEC schemes and/or receivers may not necessarily handle such varying source block sizes.  In this case, one could consider duplicating the last ADU received before the loss, or inserting zero'ed ADU(s), depending on the ADU flow nature. Implementers SHOULD consider the consequences of such alternative approaches based on their use cases.
 
> 6)
> In the next block, about protecting a single flow vs several flows
> globally, I don't see any recommendations about
> "the use of any particular technology or protocol for transporting FEC
> data, managing the hosts,
>    signaling the configuration information or encoding the
> configuration information." or any discussion of
> "the questions of interoperability across vendors/use cases and
> whether defining mandatory to implement (but not mandatory to use)
> solutions is beneficial."

I do not think there is any interop consideration here. It only says if you wanna protect multiple flows together, you need to pay attention to the delay requirements of each flow. E.g., it would be simply wrong to protect a real-time video flow with a non-real-time data flow if the FEC encoding/decoding would render video packets late for arrival.
 
> 7) regarding ADU Bundles, the use of passive voice hurts this text:
> OLD
> 	"the repair flow(s) SHOULD only be received by
>       receivers that are authorized to receive all the associated ADU
>       flows."
> NEW:
>       "receivers SHOULD drop the repair flow(s) unless they are
> authorized to receive all the associated ADU
>       flows."

Sounds good to me.
 
> I think this whole section could be substantially better if it was
> written using actionable recommendations. I think these proposed
> changes are a step toward more actionable recommendations.

So, most of your changes look good to me, I will get them in. For a few, I proposed an alternative text. Please let us know if you are ok with them.

-acbegen
 
> 
> David Harrington
> Director, IETF Transport Area
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)