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

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

> -----Original Message-----
> From: Luby, Michael [mailto:[e-mail]]
> Sent: Thursday, February 10, 2011 6:57 PM
> To: Ali C. Begen (abegen); [e-mail]
> Cc: Sean Turner; Russ Housley; [e-mail]; Luby, Michael
> Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe
> 
> 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).

Good point.
 
> 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.)

Better point.

Thanks.
-acbegen
 
> 
> 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