Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework)

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Jan 2011 15:51:43 -0500

Hi Ali,

I am not a fan of introducing what appear to be additional
requirements late in the process, and I strongly support the idea that
a charter should make sure all aspects will be addressed adequately.
Unfortunately the charter as written does not do a good job of
identifying operations and management considerations as a requirement.
That does not mean the WG, and the IETF in general, and the IESG in
particular, should allow specifications to advance that ignore
important requirements.

The IESG DISCUSS criteria
http://www.ietf.org/iesg/statement/discuss-criteria.html include
specific points to be considered when evaluating whether a document
should be advanced. In my opinion, this document and the rest of the
WG document set fails to meet the following criteria:

.It is unlikely that multiple implementations of the specification
would interoperate, usually due to vagueness or incomplete
specification

.It would present serious operational issues in widespread deployment,
by for example neglecting network management or configuration
entirely. 

As you know, I am not the only IESG member that thinks this document
fails to meet that criteria.
It has been suggested you consult RFC5706 for guidance. I think
RFC5706 is fairly heavyweight for guidance.
I have made some suggestions of things to consider (so you can
document those considerations) that I believe would help satisfy the
DISCUSS criteria.

Saying consideration of operations and management is out of scope is
simply unacceptable, and the document is likely to never be approved
as long as that is the attitude presented to the IESG. The IESG
accepts that no one protocol will be right for all fec schemes and all
environments, but the purpose of standards is interoperability, so the
IESG would consider it perfectly reasonable if the configuration and
management support was fec scheme specific. In that case, the
framework should state that each fec scheme compliant with this
framework MUST identify a mandatory-to-implement protocol and data
model to ensure a minimum level of interoperability between
implementations of that fec scheme from different sources.

dbh

> -----Original Message-----
> From: Ali C. Begen (abegen) [mailto:[email-masked]] 
> Sent: Saturday, December 11, 2010 2:26 PM
> To: David Harrington; [email-masked]
> Subject: RE: [Fecframe] Operations and Management 
> Considerations (text for theframework)
> 
> Hi David, All,
> 
> This was not an attempt for a punt or refusal. This was 
> simply a summary of what has been discussed in the WG and 
> design team in the past three years. I might have done a poor 
> job in summarizing it but your email is not concerned about it.
>  
> I offered the text based on my knowledge and past meetings, 
> and asked the WG to provide input on it. There were no 
> objections. And from what we saw, I can tell that those of us 
> who actually run FEC systems were happy with the points or 
> arguments summarized in this section. I agree there is not 
> much detailed information but the section offers why it is so.
> 
> The list you provided below involves many things that were 
> never discussed in this WG (at least to my knowledge), 
> largely because they were left outside the scope since the 
> beginning. I was still at school when fecframe was formed and 
> chartered but the current charter does not have much 
> (actually anything at all) related to the list below. If 
> these things indeed needed a specification, the charter 
> should have said so and they should have been worked on when 
> the framework draft was still developing and during the time 
> when we had a larger participation in the WG. 
> 
> I am happy with what the WG decides to do. As one of the 
> current editors, I am willing to contribute but this is a 
> daunting task, which will certainly require more than one 
> person. However, first I would like to see what everybody 
> thinks: are we missing essential information that we would 
> need in the field for fecframe apps?
> 
> -acbegen
> 
> > -----Original Message-----
> > From: David Harrington [mailto:[email-masked]]
> > Sent: Friday, December 10, 2010 8:31 AM
> > To: Ali C. Begen (abegen); [email-masked]
> > Subject: RE: [Fecframe] Operations and Management 
> Considerations (text for theframework)
> > 
> > Hi,
> > 
> > This is not adequate to address IESG concerns.
> > 
> > You need to talk about what needs to be managed, and how it can be
> > managed in an interoperable manner.
> > 
> > Excerpts from the IETF Mission statement:
> > The mission of the IETF is to make the Internet work better by
> > producing high quality, relevant technical documents that
influence
> > the way people design, use, and manage the Internet... when the
IETF
> > takes ownership of a protocol or function, it accepts the
> > responsibility for all aspects of the protocol.
> > 
> > This is an excerpt from another conversation that is 
> happening in the
> > IESG, and the statement has IESG and IAB consensus:
> > "IETF [...] has negative experience with two standards in the same
> > general area.  When one vendor implements one standard and another
> > vendor implements the other standard, there is no
interoperability.
> > The result is two disjoint communities, which is considered 
> a failure
> > in the IETF."
> > 
> > Some IESG responses to your proposed text:
> > 
> > - This is worse than a punt. This is an explicit refusal to
consider
> > the issues of operation or management, plus the addition of 
> text that
> > states "we will not do this in this draft".
> > 
> > - As holder of the DISCUSS I would not clear the DISCUSS 
> based on the
> > proposed text.
> > > Defining tools for the operation and management of these hosts
is
> > not within the scope of this specification.
> > Sure - it's a framework document. Yet discussion of the 
> operations and
> > management interoperability is IMO within scope as it is part of
the
> > interoperable framework.
> > 
> > I strongly support these IESG positions.
> > 
> > So, going forward, what we need to produce, as a starter, is
> > discussion of
> > 1) what are the critical errors in FEC processing, and how should
> > operators and applications respond to these errors?
> > 2) How should critical errors get reported to operators and
network
> > management applications?
> > 3) How are the critical errors reported in a vendor-neutral
manner?
> > 4) what is the ***standard*** for configuring FEC parameters, so
we
> > have a minimum level of interoperability across vendors? If there
is
> > no need for such a standard, then it is questionable whether this
is
> > IETF work because the IETF works to develop vendor-neutral
standards
> > for interoperability across vendors.
> > 5) A standard set of functionality can be supplemented with
> > proprietary methods if desired, but there should be ONE method
that
> > all compliant implementations support.
> > 6) What statistics should be maintained by senders and recievers
of
> > FEC-protected content? Faults? performance measures? connections?
> > 7) What is the range of the statistics? What happens to the 
> statistics
> > when a device reboots? or a session restarts?
> > 8) I recommend you expand section 6 to standardize this feedback
> > information model in more detail.
> > 	- see RFC3444 about information models,
> > 	- see the BRIDGE-MIB for some guidelines about limiting the
> > information model to necessary infromation
> > 	- for those that participate in IEEE 802.1, you might want to
> > look at how they separate the information model form the data
model
> > 	- how does pre- and post-encryption affect those statistics?
> > Should the use of pre-, -post-, or both encryption be reported so
an
> > operator can tell whether FEC configuration is properly aligned
with
> > domains of trust?
> > 9) How are the statistics reported to an operator or NM
application,
> > especially NM applications from another vendor?
> > 10) How are the statistics reported between receiver and sender?
is
> > there in-line OAM functionality? What happens if there is a proxy?
> > 
> > One of things that happens, when you refuse to properly consider
> > security and/or operations and management, is that you tend to get
a
> > bigger pushback in response. I think you are seriously beyond the
> > point of being able to say "how security is handled and how 
> operations
> > and manageent are handled is up to the operator."
> > 
> > when the IETF takes ownership of a protocol or function, it
accepts
> > the responsibility for all aspects of the protocol.
> > 
> > David Harrington
> > Director, IETF Transport Area
> > [email-masked] (preferred for ietf)
> > [email-masked]
> > +1 603 828 1401 (cell)
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Ali C. Begen
> > (abegen)
> > > Sent: Thursday, December 09, 2010 12:30 PM
> > > To: [email-masked]
> > > Subject: [Fecframe] Operations and Management Considerations
> > > (text for theframework)
> > >
> > > This is the text that will be incorporated into the framework
> > > draft (following up on the earlier discussion in the list).
> > > If there are any final comments, please send them to the list.
> > >
> > > Otherwise, we are waiting for the AD to give us a green light
> > > to move ahead with a submission to address the IESG comments.
> > >
> > > Thanks,
> > > -acbegen
> > >
> > >
> > > 10.  Operations and Management Considerations
> > >
> > >    The FEC Framework is concerned about the FEC encoding and
> > decoding
> > >    operations, and the configuration information that is
essential
> > to
> > >    control the hosts running these operations.  Defining tools
for
> > the
> > >    operation and management of these hosts is not within the
scope
> > of
> > >    this specification.
> > >
> > >    Some applications using the CDPs compatible with the FEC
> > Framework
> > >    are one-way meaning that they do not have a way to gather
> > > any kind of
> > >    feedback from receivers (e.g., broadcast), while some 
> of them may
> > >    collect detailed feedback (in case it is a one-to-one
> > > application) or
> > >    occasional feedback (in case it is a multicast 
> application).  All
> > >    these applications have naturally different 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.
> > >
> > >    On the operations side, it is not advisable for the FEC
> > > Framework to
> > >    explicitly list what the hosts (sender or receiver or even
> > > a middle-
> > >    box) could do upon observing something in particular 
> or receiving
> > a
> > >    specific feedback.  The CDPs and the FEC schemes
> > > compatible with the
> > >    FEC Framework SHOULD make use of existing tools as much as
> > possible
> > >    and to the extent possible.  For example, for repair flows
> > > using RTP
> > >    transport, benefiting from all the features of RTCP 
> mechanisms is
> > >    strongly RECOMMENDED since RTCP has already solved 
> many of these
> > >    issues in an agnostic way of the data carried with RTP.
> > >
> > >    Overall, 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.
> > > _______________________________________________
> > > Fecframe mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/fecframe
> > >
>

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Jan 2011 16:06:46 -0500

Hi,

I agree that it may make more sense to focus on the interoperability
of specific fec schemes and features.

The framework ops+mgmt considerations should SAY that, and should set
the requirement that framework-compliant components MUST specify
mandatory-to-implement protocols for config and monitoring, so
independently developed implementations have at least one protocol
available for operators to deploy to provide interoperable operations
and interoperable management for each chosen fec scheme.

Of course, if each scheme chooses a different mandatory-to-implement
protocol, then an entity that supports multiple fec schemes might end
up with a panoply of mandatory-to-implement protocols for config and
monitoring, so it might make more sense to have at least one
mandatory-to-implement protocol at the framework level, to ensure a
minimum level of interoperability for config and monitoring.

The approach so far taken by this WG seems to be "let's just declare
it out of scope" - i.e., have no standard mechanisms for configuring
or monitoring FEC operations or specific FEC schemes. As far as I can
see, that means that if vendor A's server wants to use fec protection
for something it is sending to a client from vendor B, and vendor A
chooses one protocol for config, such as SDP, and vendor B chooses not
to support the same protocol, then the two endpoints cannot
communicate to agree on a configuration. That would be a pretty sad
situation for an IETF standard.

David Harrington

> From: David R Oran [mailto:[email-masked]] 
> Sent: Saturday, December 11, 2010 3:26 PM
> To: Ali C. Begen (abegen)
> Cc: David Harrington; [email-masked]
> Subject: Re: [Fecframe] Operations and Management 
> It seems to me that since this is a framework draft, what it 
> needs is a framework for how the FEC parts of a bigger system 
> affect the overall operations and management of that system. 
> While the current text may be view by the IESG as inadequate, 
> there is frankly not a whole lot other than motherhood to say 
> here. The framework is not a protocol with specific 
> mechanisms and state machines that need configuration and/or 
> fail in particular ways that need to be managed. Therefore, 
> while I think some of the cited requirements on enhancing the 
> draft make a certain amount of sense, the level of 
> specificity that is possible is quite low, so the "pain-gain" 
> ratio strikes at least this WG participant as not warranting 
> a whole lot of work.
> 
> The kind of drafts where the O&M considerations become 
> concrete are documents like 
> 
>
http://datatracker.ietf.org/doc/draft-ietf-fecframe-config-signaling/
> 
> and
> 
> http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/
> 
> I think there's more bang-for-the-buck in focusing the 
> limited energies of the FEC community there.
> 
> DaveO.
> 
> 
> On Dec 11, 2010, at 2:26 PM, Ali C. Begen (abegen) wrote:
> 
> > Hi David, All,
> > 
influence
> >> the way people design, use, and manage the Internet... 
> when the IETF
interoperability.
> >> The result is two disjoint communities, which is 
> considered a failure
> >> in the IETF."
> >> 
> >> - This is worse than a punt. This is an explicit refusal 
> to consider
> >> the issues of operation or management, plus the addition 
> of text that
is
> >> management interoperability is IMO within scope as it is 
> part of the
> >> interoperable framework.
> >> 
network
manner?
we
> >> have a minimum level of interoperability across vendors? 
> If there is
> >> no need for such a standard, then it is questionable 
> whether this is
that
of
> >> 7) What is the range of the statistics? What happens to 
> the statistics
model
> >> Should the use of pre-, -post-, or both encryption be 
> reported so an
> >> operator can tell whether FEC configuration is properly 
> aligned with
> >> domains of trust?
is
> >> security and/or operations and management, is that you 
> tend to get a
> >> point of being able to say "how security is handled and 
> how operations
accepts
essential
for
scope
aspects.
> >>>   feedback, processing it and acting on it.  The data structures
> >> for
> >>>   box) could do upon observing something in particular or 
> receiving
> >> a
> >>>   strongly RECOMMENDED since RTCP has already solved many of
these
deployment
choice,

---

From: David R Oran <[email-masked]>
Date: Mon, 17 Jan 2011 16:34:16 -0500

Thanks for getting back to me on this. I think we're converging (somewhat), or at least talking about the same things.

> and interoperable management for each chosen fec scheme.
This seems a reasonable principle to follow. The devil is in the details, especially in how the config and management for the overall system(s) interact with the FEC-specific pieces. See below for more.

> minimum level of interoperability for config and monitoring.
If FEC schemes were "top-of-the-foodchain" kinds of protocol, like TCP, or RTP, or SIP, then following this rule would in fact help a lot in ensuring system-level interoperability for the operations and management components of making the protocol work and instrumenting it. Unfortunately (or perhaps in my view fortunately), that's not the case here. FEC schemes are pretty much without exception *embedded* in a "top-of-the-food-chain" protocol like RTP, or reliable multicast file transfer. That means one REALLY wants the operations and management protocols and instrumentation framework to be dictated by the embedding and not by the FEC scheme. In fact, I would consider it undesirable if we picked and mandatory-to-implement config/management protocol (e.g. SDP) for an FEC scheme, and then embedded it in a different "top-of-the-food-chain" system that has no need of SDP for anything. This is not entirely theoretical; we already have FEC schemes in use by other SDOs that use multicast file transfer and XML to describe and manage the protocols with which which the FEC scheme is based. It makes much more sense to ensure that the necessary configuration and instrumentation information is present in those protocols, than to declare the implementation non-compliant in the IETF because the implementer didn't (uselessly) put SDP in the system.

Therefore, I still maintain that:
- There isn't a lot to say in the framework draft, and find your suggestion to limit language in that draft to saying that the operations and management of FEC is "scheme specific" and that the scheme RFCs MUST address O&M with the appropriate O&M considerations section.
- if you at all buy my logic above, then it is not appropriate to require "mandatory to implement" protocols in the scheme drafts; rather, the requirement is for enough specific information about configuration and instrumentation to give implementors guidance about what changes/enhancements may be needed to the protocols used in the "enclosing" protocol environment.

> or monitoring FEC operations or specific FEC schemes.
That's a correct assessment of the WG's general approach, but I do not view that criticism as necessarily all that serious given the nature of the work.

> As far as I can
Not as sad as having an FEC scheme used with both RTP and with Reliable file transfer being forced to add a lot of useless complexity and introduce new interoperability problems for the system they are embedded in because the two systems for good reason use different configuration and management protocols.

I'm of course encouraged by the discussion, which has shed some light on the underlying issues. I think that at least at this point we are not in agreement about the right way forward, but hopefully this has helped make some progress.

DaveO.

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Jan 2011 17:36:15 -0500

Hi Mike,

Sure, I'll take a whack!

The fecframe charter says "A primary objective of this framework is to
support FEC for real-time 
media applications using RTP over UDP, such as on demand streaming and

audio/video broadcast."

The RTP MIB (RFC2959) is an example of the AVT approach to
standardizing operations and management support. 
While RTP can support a variety of payloads, just as the FEC framework
can support multiple fec schemes, there are certain properties that
exist regardless of payload (and correspondingly, regardless of fec
scheme).
The RTP MIB document discusses operational issues and how the MIB can
be applied to detect/monitor/address those issues. 
For example, the RTP MIB allows an operator to 
1) monitor what RTP sessions exist, 
2) monitor what senders are active in the sessions,
3) monitor what receivers are active in the senders,
4) monitor statistics and operational state about the sessions, and
5) create and configure new sessions.

So the RTP MIB, and FEC-specific extensions to the RTP MIB, could be a
likely candidate for how to manage FEC sessions.
A MIB module is a data model, that provides a concrete expression of
an information model (see RFC3444).

If you'd like to write a MIB module, feel free. 
But the IESG is not demanding a MIB module. There are multiple
protocols and data modeling languages that have been standardized
since the RTP MIB was written, that might provide the necessary
functionality, including syslog/SDE, netconf/YANG, ipfix/IE, and SDP.
Other protocols might be more suitable to the environments where FEC
may be applied.

The IESG is asking for a discussion of operational and management
issues related to forward error correction, at the framework level,
and a discussion of how independent implementations will be
interoperable for operations and management:
"[a framework] document is expected to include information about
operational impact and manageability of
devices and networks that will compy to the framework, also indication
about
what kind of operations and manageability information future
specifications of
protocols that comply to the framwork would include.  This document
includes no
such information."

My recommendation is to add a section that discusses operational
impact, such as the expected increase in traffic load caused by
deploying FEC. It would probabyl be good to require each FEC scheme to
discuss the expected impact of that scheme, and the effect of certain
configuration settings.
I recommend adding another section that addresses
cross-vendor-interoperable manageability of entities complying with
the framework, including interoperable configuration mechanisms, and
interoperable mechanisms for reporting asynchronous errors, and
interoperable mechanisms for reporting operational state and
statistics. At some level, there should be mandatory-to-implement
protocols and/or data models to ensure a minimum level of
interoperability across implementations. The framework should identify
which level in the framework MUST require that interoperability.

David Harrington

> From: Luby, Michael [mailto:[email-masked]] 
> Sent: Saturday, December 11, 2010 4:40 PM
> To: David Harrington; Ali C. Begen (abegen); [email-masked]
> Hi Dave,
> Perhaps you could provide the equivalent text from the AVT 
> working group
> that addresses this issue as a starting point for what the 
> corresponding
> text could be in FECFRAME?  The reason I suggest this is that 
> the AVT is
> somewhat similar to FECFRAME, as in AVT there is the 
> standardization of
> delivering different video codec formats to receivers, and 
> FECFRAME is about
> delivering FEC data that protects those deliveries, so in this sense
> FECFRAME is an adjunct to AVT and should be able to leverage 
> the general
> framework specifications that AVT has that describes how to 
> manage video
> delivery in an interoperable way.  I'm sure there must be an 
> AVT standard
> that addresses all the issues you raise below, and it sure 
> would be use that
> as a starting point.
> Mike 
> 
> 
> On 12/10/10 5:31 AM, "David Harrington" <[email-masked]> wrote:
> 
> > Hi,
> > 
influence
IETF
interoperability.
consider
> >> Defining tools for the operation and management of these hosts is
the
network
manner?
we
is
is
standards
that
of
model
an
with
application,
is
a
accepts
essential
for
scope
aspects.
these
deployment
choice,

---

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

FWIW, none of the RTP deployments I am aware of (and I know several) support RTP MIB. So, do different RTP implementations fail to interoperate? Absolutely not.

-acbegen

> Sent: Monday, January 17, 2011 5:36 PM
> To: 'Luby, Michael'; Ali C. Begen (abegen); [email-masked]
> Subject: RE: [Fecframe] Operations and Management Considerations (text for theframework)
> 
> Hi Mike,
> 
> Sure, I'll take a whack!
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Jan 2011 14:56:00 -0800

> From: Dave Oran (oran)
> Sent: Monday, January 17, 2011 4:34 PM
> To: David Harrington
> Cc: Ali C. Begen (abegen); [email-masked]; 'Lars Eggert'
> Subject: Re: [Fecframe] Operations and Management Considerations (text for theframework)
> 
> This seems a reasonable principle to follow. The devil is in the details, especially in how the config and management for the
> overall system(s) interact with the FEC-specific pieces. See below for more.
> 
> If FEC schemes were "top-of-the-foodchain" kinds of protocol, like TCP, or RTP, or SIP, then following this rule would in fact
> help a lot in ensuring system-level interoperability for the operations and management components of making the protocol
> work and instrumenting it. Unfortunately (or perhaps in my view fortunately), that's not the case here. FEC schemes are
> pretty much without exception *embedded* in a "top-of-the-food-chain" protocol like RTP, or reliable multicast file transfer.
> That means one REALLY wants the operations and management protocols and instrumentation framework to be dictated by
> the embedding and not by the FEC scheme. In fact, I would consider it undesirable if we picked and mandatory-to-implement
> config/management protocol (e.g. SDP) for an FEC scheme, and then embedded it in a different "top-of-the-food-chain"
> system that has no need of SDP for anything. This is not entirely theoretical; we already have FEC schemes in use by other
> SDOs that use multicast file transfer and XML to describe and manage the protocols with which which the FEC scheme is
> based. It makes much more sense to ensure that the necessary configuration and instrumentation information is present in
> those protocols, than to declare the implementation non-compliant in the IETF because the implementer didn't (uselessly)
> put SDP in the system.
> 
> - There isn't a lot to say in the framework draft, and find your suggestion to limit language in that draft to saying that the
> operations and management of FEC is "scheme specific" and that the scheme RFCs MUST address O&M with the appropriate
> O&M considerations section.

This makes sense and agrees with what WG implicitly assumed so far IMO.

> - if you at all buy my logic above, then it is not appropriate to require "mandatory to implement" protocols in the scheme
> drafts; rather, the requirement is for enough specific information about configuration and instrumentation to give
> implementors guidance about what changes/enhancements may be needed to the protocols used in the "enclosing" protocol
> environment.

Indeed. One just needs to look at where FEC has been deployed so far and how it has been used in large networks to appreciate the statement above.
 
-acbegen

> Not as sad as having an FEC scheme used with both RTP and with Reliable file transfer being forced to add a lot of useless
> complexity and introduce new interoperability problems for the system they are embedded in because the two systems for
> good reason use different configuration and management protocols.
> 
> I'm of course encouraged by the discussion, which has shed some light on the underlying issues. I think that at least at this
> point we are not in agreement about the right way forward, but hopefully this has helped make some progress.
> 
> DaveO.
> 
> 
> > David Harrington

---

From: Marshall Eubanks <[email-masked]>
Date: Mon, 17 Jan 2011 22:12:34 -0500

> FWIW, none of the RTP deployments I am aware of (and I know several) support RTP MIB. So, do different RTP implementations fail to interoperate? Absolutely not.

This matches my experience. 

Regards
Marshall

---

From: "David Harrington" <[email-masked]>
Date: Mon, 17 Jan 2011 22:21:56 -0500

The question is not whether RTP fails to interoperate but whether the
management of RTP fails to interoperate.
To configure a device and monitor RTP faults and performance can an
operator use a standard protocol with a standard data model, or is the
operator required to write custom scripts for each vendor's device,
and possibly even each vendor's model?

dbh

> Sent: Monday, January 17, 2011 5:51 PM
> To: David Harrington; Luby, Michael; [email-masked]
> FWIW, none of the RTP deployments I am aware of (and I know 
> several) support RTP MIB. So, do different RTP 
> implementations fail to interoperate? Absolutely not.
> 
> -acbegen
> 
> whether this
> reported so
aligned
> tend to get

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 17 Jan 2011 19:48:36 -0800

> Sent: Monday, January 17, 2011 10:22 PM
> To: Ali C. Begen (abegen); 'Luby, Michael'; [email-masked]

RTP has a mandatory control protocol called RTCP not necessarily for management only but for several things. Fecframe does not have such a protocol and it does not need to have one. If RTP transport is used for fecframe, one will directly use whatever tools available to RTP including RTCP.

RTP also makes use of SDP heavily. But, that is not to say that to use RTP, one needs to implement SDP. Yeah, in the IETF world, we tend to focus on SDP as the session description protocol but in the outer world, different things are being used (e.g., XML based configuration files).

To me, requiring SDP or something like XML for fecframe configuration is a mistake. Similarly, requiring a MIB or something different for feedback collection is also a mistake. 

> operator use a standard protocol with a standard data model, or is the

As I said, when possible/available, standard tools can be easily used by fecframe. 

> and possibly even each vendor's model?

Not if all those vendors followed the spec that made use of the fec framework. Let me give you an example. If another organization wants to use our framework in one of their standards, they will get the framework but then they will likely to choose a transport protocol according to their requirements, a configuration/session description protocol, a signaling protocol and a feedback protocol - all according to their needs. They will also decide what needs to be collected from the endpoints as a feedback, and they might even go one step further and define the actions that need to be taken for each such feedback. They will outline and specify anything they think as necessary. They might say, no more than X% of redundancy will ever be used. Or, they may limit their spec to use certain fec schemes. 

That is perfectly fine from their perspective and mine. But if we try to do the same thing in the framework draft, we will not only confuse them but doing so will also probably discourage them from using our framework because our requirements may not be a good fit for their scenarios. 

BTW, the framework draft is not an FEC 101 guide for operators. That is, the framework draft should not be the first thing they need to read about fec. That would be a gross mistake IMO. Framework draft is rather a spec that defines some concepts so that fec schemes and CDPs can be developed on top of it and it allows others to follow the same concepts while also imposing some additional requirements. 

-acbegen