[Fecframe] Ops/Management Cons. text for fecframe

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

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.