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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 10 Feb 2011 12:51:02 -0800

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.

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 10 Feb 2011 15:57:16 -0800

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)" <[email-masked]> 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).
> 
> 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.
> 
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 11 Feb 2011 06:15:09 -0800

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

Good point.
 
> recover source flows using FEC repair that they are not supposed to

Better point.

Thanks.
-acbegen

---

From: Vincent Roca <[email-masked]>
Date: Fri, 11 Feb 2011 14:43:52 +0100

Hello Mike,

That's an important operational aspect that we omitted,
I agree. I suggest to add the following text as you suggest:

---
ADU Flow Bundle Definition and Flow Delivery Considerations:

By design a repair flow may enable a receiver to recover the
ADU flow(s) that it protects even if none of the associated FEC
source packet is received. Therefore, when defining the bundle
of ADU flows that are globally protected and when defining
which receiver receives which flow, the repair flow(s) SHOULD
only be received by receivers that are authorized to receive all
the associated ADU flows. See Section 9.4 for additional
recommendations for situations where a strict access control
to ADU flows is needed.

Additionally when multiple ADU flows are globally protected,
a receiver who wants to benefit from FECFRAME loss protection
SHOULD receive all the ADU flows of the bundle. Otherwise the
missing FEC source packets would be considered as lost which
may significantly reduce the efficiency of the FEC Scheme.
---

Cheers,

    Vincent

On 11/02/11 00:57, Luby, Michael wrote:
> On 2/10/11 12:51 PM, "Ali C. Begen (abegen)"<[email-masked]>  wrote:
>

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 11 Feb 2011 13:44:46 -0800

Looks good.

On 2/11/11 5:43 AM, "Vincent Roca" <[email-masked]> wrote:

>>> The DISCUSS Sean T. is about the security related issues, which were
>>> addressed
>>> in the last revision.
>>>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sun, 13 Feb 2011 14:04:37 -0800

> From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Sent: Sunday, February 13, 2011 5:58 AM
> Cc: Russ Housley; Sean Turner; [email-masked]
> Subject: RE: Ops/Management Cons. text for fecframe
> 
> Hi,
> 
> Thank you for addressing the issue. See comments in-line.
> 
> Regards,
> 
> Dan
> 
> 
> > From: Ali C. Begen (abegen) [mailto:[email-masked]]
> > Sent: Thursday, February 10, 2011 10:51 PM
> > To: [email-masked]
> > Cc: Russ Housley; Sean Turner; [email-masked];
> > Romascanu, Dan (Dan)
> > Subject: Ops/Management Cons. text for fecframe
> >
> > 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).
> >
> > 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.
> >
> > 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.
> >
> >    them does not exist.
> I am not sure that we are talking here about 'tools' or rather methods
> and/or protocols. Also 'does not exist' is not the question - the
> question is whether managing CDPs and FEC schemes compatible with the
> FEC framework is too complex a task to be solved by one standard method
> or protocol. I suggest adjusting the text to make this clear.

Your proposed wording is more accurate. Thanks.

> > Thus, as a design choice, the FEC Framework
> By 'associated tools' you mean here tools using RTCP?

I will change it to "tools using (or used by) RTCP".
 
> I am not sure that Congestion Control belongs here or rather in
> Transport Considerations.

Well, we can remove it as we already detailed congestion control issues earlier in the document.

-acbegen

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 14 Feb 2011 03:35:16 -0800

> I am OK with your proposed changes.

Thanks.

David,

Should we submit a revision with these changes (and addressing the comments from the list)?

-acbegen

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 15 Feb 2011 07:59:06 -0800

Ali,

Yes, please submit a revision with these changes.

Thanks,
Greg

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Tue, 15 Feb 2011 14:08:51 -0800

Revision has been submitted. 

Dan, David, Russ and Sean,

Please let us know if this revision addressed your concerns and DISCUSSes.
https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ 

Thanks.
-acbegen

> From: Greg Shepherd [mailto:[email-masked]]
> Sent: Tuesday, February 15, 2011 10:59 AM
> To: Ali C. Begen (abegen)
> Cc: Romascanu, Dan (Dan); [email-masked]; Sean Turner; Russ Housley

---

From: "Luby, Michael" <[email-masked]>
Date: Tue, 15 Feb 2011 17:40:23 -0800

Looks good.  One thing that I still think worth adding is something about
potential packet reordering, i.e., whereever loss is an issue it perhaps
should be mentioned that packet reordering can also be an issue that needs
to be considered addressed.  This is all wrt the Management/Deployment
section.

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 16 Feb 2011 18:26:43 -0800

OK, I got a revised text from Mike that incorporated "packet reordering" in 10.2 and fixed a typo. The text is below. We can make this change before we ship the draft to the editor.

-acbegen

      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,
      i.e., are not prone to packet loss, packet reordering, or varying
      delays in delivering packets.
      
      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.

      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 and other 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.  Thus, all the ADUs SHOULD be fed into the FEC encoder in
      their proper sequence and within a desired certain delay.  For
      cases when this cannot be guaranteed, the sender and receiver
      implementations need to consider a potential solution and its
      consequences.

> Sent: Tuesday, February 15, 2011 8:40 PM
> To: Ali C. Begen (abegen); Greg Shepherd
> Cc: Romascanu, Dan (Dan); Sean Turner; Russ Housley; [email-masked]

---

From: Vincent Roca <[email-masked]>
Date: Thu, 17 Feb 2011 17:44:57 +0100

Ali, Mike, all,

>        leads to a gap in the RTP sequence number space seen by the
VR: "lead" rather than "leads"
>        over this path can lead to significant timing and other issues.
VR: "and others"? That's too vague IMHO. Remove it.
>        switch to a new source block.
VR: rather than the following text...
>        However, some FEC schemes and/or
VR: ...I suggest to say (since we have already RECOMMENDED this path
to be as reliable as possible and are only focusing on situations where
this is not achieved):

       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 should be carefully considered
       (e.g., by duplicating the last packet received before the loss, or by
       inserting a zero'ed packet, depending on the ADU flow nature).

Cheers,

    Vincent

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 17 Feb 2011 09:34:09 -0800

Vincent, this is all good.
Best, Mike

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 19 Feb 2011 13:06:48 -0800

Changes are made, but I am holding on submitting a revision to wait for the ADs' resolutions of their discusses.

-acbegen

> Sent: Thursday, February 17, 2011 12:34 PM
> To: Vincent Roca; Ali C. Begen (abegen)
> Cc: Greg Shepherd; Sean Turner; Russ Housley; [email-masked]