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

["David Harrington" <[e-mail]>]

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
[e-mail] (preferred for ietf)
[e-mail]
[phone] (cell)

  

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[e-mail]] 
> Sent: Tuesday, March 01, 2011 7:38 PM
> To: Sean Turner; Russ Housley; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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:[e-mail]]
> > Sent: Wednesday, February 16, 2011 5:14 AM
> > To: Ali C. Begen (abegen); [e-mail]
> > Cc: [e-mail]; 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:[e-mail]]
> > > Sent: Wednesday, February 16, 2011 12:09 AM
> > > To: [e-mail]
> > > Cc: Romascanu, Dan (Dan); [e-mail]; 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:[e-mail]]
> > > > Sent: Tuesday, February 15, 2011 10:59 AM
> > > > To: Ali C. Begen (abegen)
> > > > Cc: Romascanu, Dan (Dan); [e-mail]; 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)
> > > <[e-mail]> 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
> > > > > [e-mail]
> > > > > https://www.ietf.org/mailman/listinfo/fecframe
> > > > >
> > >
>