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

From: "David Harrington" <[email-masked]>
Date: Sun, 15 May 2011 11:47:31 -0400

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.

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.

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.

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.

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? 

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."

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."

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.  

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Tuesday, March 01, 2011 7:38 PM
> To: Sean Turner; Russ Housley; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: FEC Framework DISCUSSes (was RE: [Fecframe] 
> Ops/Management Cons. text for fecframe)
> 
> We are dangerously getting close to the submission deadline 
> and as the authors, we would like to complete this draft so 
> that remaining work can move forward.
> 
> Russ, Sean, David, 
> 
> Could you please review the changes and let us know whether 
> you are ok with them or require further changes?
> https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework
> /ballot/ 
> 
> -acbegen
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Wednesday, February 16, 2011 5:14 AM
> > To: Ali C. Begen (abegen); [email-masked]
> > Cc: [email-masked]; Sean Turner; Russ Housley
> > Subject: RE: [Fecframe] Ops/Management Cons. text for fecframe
> > 
> > I cleared.
> > 
> > Thank you for addressing my concerns.
> > 
> > Regards,
> > 
> > Dan
> > 
> > 
> > > -----Original Message-----
> > > From: Ali C. Begen (abegen) [mailto:[email-masked]]
> > > Sent: Wednesday, February 16, 2011 12:09 AM
> > > To: [email-masked]
> > > Cc: Romascanu, Dan (Dan); [email-masked]; Sean Turner; 
> Russ Housley
> > > Subject: RE: [Fecframe] Ops/Management Cons. text for fecframe
> > >
> > > 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
> > >
> > > > -----Original Message-----
> > > > 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
> > > > Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe
> > > >
> > > > Ali,
> > > >
> > > > Yes, please submit a revision with these changes.
> > > >
> > > > Thanks,
> > > > Greg
> > > >
> > > > On Mon, Feb 14, 2011 at 3:35 AM, Ali C. Begen (abegen)
> > > <[email-masked]> wrote:
> > > > >
> > > > >> 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
> > > > >
> > > > >> Regards,
> > > > >>
> > > > >> Dan
> > > > >>
> > > > > _______________________________________________
> > > > > Fecframe mailing list
> > > > > [email-masked]
> > > > > https://www.ietf.org/mailman/listinfo/fecframe
> > > > >
> > >
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 16 May 2011 12:07:52 -0700

Hi David,

> From: David Harrington [mailto:[email-masked]]
> Sent: Sunday, May 15, 2011 11:48 AM
> Subject: RE: FEC Framework DISCUSSes (was RE: [Fecframe] Ops/Management Cons. text for fecframe)
> 
> Hi,
> 

OK, we will make "recommendations" uppercase.
 
>       instance along with the associated FEC schemes.

This is also fine.
 
>       reporting mechanism, such as syslog or SNMP notifications, is

OK, will add this last paragraph.
 
>       the responsibility of the sender to select the appropriate

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?
 
> 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.
 
> 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.
 
> authorized to receive all the associated ADU

Sounds good to me.
 
> 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

---

From: Vincent Roca <[email-masked]>
Date: Wed, 18 May 2011 13:13:34 +0200

Hello David,

I'm okay too.

>   [...]

I have several comments WRT the above paragraph.

* syslog is standardized in RFC 5424, so we probably need to refer
to this RFC, and similarly we need to refer to RFC 3411 for SNMP.
Since implementing/using one of these protocols is RECOMMENDED, these
references should go to the Normative References section (both are
Standards Track documents, so there's no downward ref issue here).

* Otherwise I'm a little confused by the juxtaposition of the two
sentences. The first one says that an in-band solution, e.g. RTCP
based, is RECOMMENDED (as one solution among others), while the
second sentences RECOMMENDS the use of an out-of-band solution.

If I put these two comments together, I would suggest something like:

    Implementers SHOULD make feedback available using either an in-band
    or out-of-band asynchronous reporting mechanism. When an out-of-band
    solution is preferred, a standardized reporting mechanism, such as
    syslog [RFC5424] or SNMP [RFC3411], is RECOMMENDED.

* Is that sufficient to increase the probability that independent
products interoperate? No, we need to go a bit further and define
SNMP notification/syslog message formats. So the followup should be
to start defining a MIB... Unless the implementer chooses an in-band,
RTCP based, approach, which already includes useful information
from the FECFRAME point of view.

* We RECOMMEND two different out-of-band solutions, which creates
interoperability risks. As I understand, mappings exist between the
syslog/SNMP solution: RFC 5675 explains how to map SNMP notifications
to syslog messages, while RFC 5676 discusses the opposite mapping.
I don't know if these mappings are common or not, but this may also
increase the probability that different products interoperate.
So we can perhaps add a third sentence:

    When required, a mapping mechanism between the syslog and SNMP
    reporting mechanisms COULD be used, as described in [RFC5675]
    and [RFC5676].

I'm okay with your proposal plus Ali's update.

I admit understanding this paragraph is somewhat difficult.
The first RECOMMENDATION is within the first paragraph:

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

This is only a RECOMMENDATION and in practice, for whatever reason,
there MIGHT be a packet loss/reordering/delayed delivery on this
path (i.e. sending application -> FECFRAME middlebox). Therefore
the FECFRAME instance MUST NOT break if ever this happens, so we
need to look a little bit further and give RECOMMENDATIONS on
how to design a FEC Scheme that tolerates it. Just in case...

It turns out the issue only arises with FEC Schemes that do NOT
use any Explicit Source FPI (since there is no renumbering of
symbols that are actually part of a source block). There are a few
solutions (some of them mentioned). Which one is preferred is
use-case specific (depends on the flow nature).

IMO this discussion SHOULD be included in the framework document
and any FEC Scheme that is concerned by the problem SHOULD at least
highlight the general requirement and point to this framework
discussion.

Initial discussion:
http://www.ietf.org/mail-archive/web/fecframe/current/msg00841.html
More recently, WRT RTP for Raptor(Q):
http://www.ietf.org/mail-archive/web/fecframe/current/msg00884.html
The same applies to our draft-galanos-fecframe-rtp-reedsolomon-03
document, of course.

In order to help clarify the point, here's what I suggest:

NEW:
<added>
    At the sending side, the general reliability RECOMMENDATION
    for the path between the sending applications and the middlebox
    is important but it MAY NOT guaranty that a loss, reordering or
    important delivery delay cannot happen, for whatever reason.
    If such a rare event happens, this event SHOULD NOT compromize
    the operation of the FECFRAME instances, neither at the sending
    nor receiving side.
    This is particularly important
</added>
    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 agree with Ali's comment.

>      authorized to receive all the associated ADU flows."

No, the new text changes the initial intent. The "SHOULD" is for the
sender, not for the receiver. Since there's a misunderstanding, this
means that the original text is bad, so you can blame us for that.
So here is a new proposal:

OLD:
      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.
NEW:
      Therefore, when defining the bundle of ADU flows that
      are globally protected and when defining which receiver receives
      which flow, the sender SHOULD make sure that the ADU flow(s) and
      repair flow(s) of that bundle will only be received by receivers
      that are authorized to receive all the ADU flows of that bundle.

Cheers,

   Vincent