Subject: [Fecframe] Operations and Management Considerations (text for the framework)

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 09:30:10 -0800

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.

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 9 Dec 2010 09:41:23 -0800

David,

Can you please review and reply to the proposed changes to the
Framework draft? Once you approve it can move back to the IESG for
their approval.

Thanks!,
Greg

---------- Forwarded message ----------
From: Ali C. Begen (abegen) <[email-masked]>
Date: Thu, Dec 9, 2010 at 9:30 AM
Subject: [Fecframe] Operations and Management Considerations (text for
the framework)
To: [email-masked]

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

_______________________________________________
Fecframe mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/fecframe

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 9 Dec 2010 10:43:43 -0800

Is there any discussion I the framework draft (perhaps it would be in this
section 10) that covers operations and management when you have a mixed
population of receivers, some that do support FEC and some that do not?  In
such a mixed population there might be certain recommendations for how to
operate and configure things so that receivers that don't support FEC are
not disrupted but those that do can benefit from receiving FEC to enhance
the quality of their service.

On 12/9/10 9:30 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 10:55:52 -0800

It is not in this section but there is some text about this earlier in the draft (section 5.3).

-acbegen

> -----Original Message-----
> From: Luby, Michael [mailto:[email-masked]]
> Sent: Thursday, December 09, 2010 1:44 PM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: Re: [Fecframe] Operations and Management Considerations (text for the framework)
>

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 9 Dec 2010 12:24:14 -0800

Since this affects operations and management, should this issue be at least
mentioned in the operations and management section (with perhaps a pointer
to section 5.3 if that section describes the issues and solutions well
enough?)

On 12/9/10 10:55 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

>>> (following

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 13:05:59 -0800

> Sent: Thursday, December 09, 2010 3:24 PM

Done. Thanks.

-acbegen

---

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Dec 2010 08:31:14 -0500

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)

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Sat, 11 Dec 2010 11:26:06 -0800

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

> From: David Harrington [mailto:[email-masked]]
> Sent: Friday, December 10, 2010 8:31 AM
> Subject: RE: [Fecframe] Operations and Management Considerations (text for theframework)
> 
> Hi,
>

---

From: David R Oran <[email-masked]>
Date: Sat, 11 Dec 2010 15:26:00 -0500

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.

---

From: "Luby, Michael" <[email-masked]>
Date: Sat, 11 Dec 2010 13:39:30 -0800

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