Re: [Fecframe] Ops/Management Cons. text for fecframe

["Luby, Michael" <[e-mail]>]

This looks good Ali.  One thing to perhaps add at the end of Section 10.2 is
that if multiple "source flows" are protected by a single FEC repair stream
(generated from the bundle of the source flows) then it should be the case
that all of these flows are received by receivers who expect to receive and
use the FEC repair stream generated from them (as otherwise the source flows
that are not received will be considered as loss by the receiver, and also
it might allow the receiver to recover flows that are not meant for it to
receive, a security concern).

I guess perhaps it is good to add a general security statement that says
that it is important to only allow FEC repair be received by receivers for
which all of the original source from which the FEC repair is generated can
be received by those receivers.  (Otherwise, the receivers might be able to
recover source flows using FEC repair that they are not supposed to
receive.) 


On 2/10/11 12:51 PM, "Ali C. Begen (abegen)" <[e-mail]> wrote:

> We have not seen any email from the DISCUSS holders (except David) regarding
> the framework draft in the mailing list (I did not see any private email,
> either and for some reason the system is not including me in the emails from
> IESG). We need to publish this specification as it is holding several other
> documents, and even the WG itself (Clearly, many of us are eager to close the
> WG).
> 
> Here is a summary of where we stand now:
> 
> The DISCUSS from Russ H. is about some inconsistency in section 5, which was
> fixed 2 versions ago.
> 
> The DISCUSS Sean T. is about the security related issues, which were addressed
> in the last revision.
> 
> Russ, Sean, if you still have issues with the revised text, please raise them.
> 
> The DISCUSS from Dan R. and David H. are related to ops/management issues. We
> had a lot discussion on this in the mailing list, and the text below attempts
> to reflect the view of the WG on this subject.
> 
> We would like to get your (WG individuals but in particular the DISCUSS
> holders) comments on this text. The sooner the better as we would like to
> close this issue before the next meeting and ship the draft to the editor.
> 
> Approvals/objections are welcome as usual.
> 
> -acbegen
> 
> 
> 10.  Operations and Management Considerations
> 
>    The question of operating and managing the FEC Framework and the
>    associated FEC scheme(s) is of high practical importance.  The goals
>    of this section are to discuss the general requirements, aspects
>    related to a specific deployment and solutions whenever possible.
> 
>    In particular, this section discusses the questions of
>    interoperability across vendors/use cases and whether defining
>    mandatory to implement (but not mandatory to use) solutions is
>    beneficial.
> 
> 10.1.  What are the Key Aspects to Consider?
> 
>    Several aspects need to be considered since they will directly impact
>    the way the FEC Framework and the associated FEC schemes can be
>    operated and managed.
> 
>    This section lists them as follows:
> 
>    o  A Single Small Generic Component within a Larger (and Often
>       Legacy) Solution: The FEC Framework is one component within a
>       larger solution which includes both one or several upper-layer
>       applications (that generate one or several ADU flows) and an
>       underlying protocol stack.  A key design principle is that the FEC
>       Framework should be able to work without making any assumption
>       with respect to either the upper-layer application(s) or the
>       underlying protocol stack, even if there are special cases where
>       assumptions are made.
> 
>    o  One-to-One with Feedback vs. One-to-Many with Feedback vs. One-to-
>       Many without Feedback Scenarios: The FEC Framework can be used in
>       use cases that completely differ from one another.  Some use cases
>       are one-way (e.g., in broadcast networks), with either a one-to-
>       one, one-to-many or many-to-many transmission model, and the
>       receiver(s) cannot send any feedback to the sender(s).  Other use
>       cases follow a bidirectional one-to-one, one-to-many, or many-to-
>       many scenario, and the receiver(s) can send feedback to the
>       sender(s).
> 
>    o  Non-FEC Framework Capable Receivers: With the one-to-many and
>       many-to-many use cases, the receiver population might have
>       different capabilities with respect to the FEC Framework itself
>       and the supported FEC schemes.  Some receivers might not be
>       capable of decoding the repair packets belonging to a particular
>       FEC scheme, while some other receivers might not be supporting the
>       FEC Framework at all.
> 
>    o  Internet vs. non-Internet Networks: The FEC Framework can be
>       useful in many use cases that use a transport network that is not
>       the public Internet (e.g., with IPTV or Mobile TV).  In such
>       networks, the operational and management considerations can be
>       achieved through an open or proprietary solution, which is
>       specified outside of the IETF.
> 
>    o  Congestion Control Considerations: See Section 8 for a discussion
>       on whether congestion control is needed or not, and its
>       relationships with the FEC Framework.
> 
>    o  Within End-Systems vs. within Middleboxes: The FEC Framework can
>       be used within end-systems, very close to the upper-layer
>       application, or within dedicated middleboxes, for instance when it
>       is desired to protect one or several flows while they cross a
>       lossy channel between two or more remote sites.
> 
>    o  Protecting a Single Flow vs. Several Flows Globally: The FEC
>       Framework can be used to protect a single flow, or several flows
>       globally.
> 
> 10.2.  Operational and Management Recommendations
> 
>    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 tool that works well for all of
>    them does not exist.  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 was one of the main goals of the FEC
>    Framework.  However, this section gives some recommendations.
> 
>    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 associated
>       tools to operate and manage the FEC Framework instance along with
>       the associated FEC schemes.
> 
>    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.
> 
>    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.
> 
>    o  Congestion Control Considerations: See Section 8 for a discussion
>       on whether congestion control is needed or not, and its
>       relationships with the FEC Framework.
> 
>    o  Within End-Systems vs. within Middleboxes: When the FEC Framework
>       is used within middleboxes, it is RECOMMENDED that the paths
>       between the hosts where the sending applications run and the
>       middlebox that performs FEC encoding be as reliable as possible,
>       since these paths are not protected against erasures by default.
>       Similarly, it is RECOMMENDED that the paths between the
>       middleboxes that perform FEC decoding and the end-systems where
>       the receiving applications operate, in situations where this is a
>       different host, be as reliable as possible since these paths are
>       not protected against losses by default.
> 
>       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, a loss on this path directly leads to a gap in the RTP
>       sequence number space seen by the FECFRAME instance.  This MUST be
>       considered during source block creation by the FEC scheme.  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, an ADU
>       loss requires to switch to a new source block.  This SHOULD be
>       discussed in the FEC scheme when there is a chance of losing a
>       packet.
> 
>    o  Protecting a Single Flow vs. Several Flows Globally: In the
>       general case, the various ADU flows that are globally protected
>       can have different features, and in particular different real-time
>       requirements (in case of real-time flows).  The process of
>       globally protecting these flows SHOULD take into account the
>       requirements of each individual flow.  In particular, it would be
>       counter-productive to add repair traffic to a real-time flow for
>       which the FEC decoding delay at a receiver makes decoded ADUs for
>       this flow useless because they do not satisfy the associated real-
>       time constraints.  From a practical point of view, this means that
>       the source block creation process at the sending FEC Framework
>       instance, SHOULD consider the most stringent real-time
>       requirements of the ADU flows being globally protected.
> 
> 
> _______________________________________________
> Fecframe mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe