[Fecframe] Proposed changes to the framework draft - part 1 (ops/managament)

["Ali C. Begen (abegen)" <[e-mail]>]

Hi everyone,

As you know the framework draft is in the IESG review process. As we discussed in the last meeting, for two of these issues (the others were already addressed) we would like to consult with the WG. This email is about the DISCUSS relating to the ops/management issues. There will be a separate thread for the security issues.

Please see the comments from the IESG and then the proposed changes in the framework draft below. We need your input so that we can provide a revision soon.

Comment from Adrian F.:

It would be helpful, I think, if a framework/architecture like this 
included a discussion of how the systems and networks described are
operated and managed. You might look at RFC 5706 for guidance.

Discuss from Dan R.:

I would like to raise the issue raised by Adrian to a DISCUSS - such a document
is expected to include information about operational impact and manageability of
devices and networks that will comply to the framework, also indication about
what kind of operations and manageability information future specifications of
protocols that comply to the framework would include. This document includes no
such information. I would like to discuss this in the call, maybe these issues
are covered in other fecframe documents, or future work planned by the WG.

--

Some background:

Essentially, the IESG wants to make sure that the WG has discussed these issues adequately and wants to see a text for some guidelines. As a matter of fact, in the early days, the design team has discussed these issues in detail (both in the IETF meetings as well as offsite meetings). The general consensus was that the FEC schemes differed widely about their capabilities, application and deployment scenarios such that coming up with a single tool that worked for all of them was almost impossible. Certain apps are one-way meaning that they don't have any kind of feedback back from receivers (e.g., broadcast), while some of them may collect detailed feedback (maybe it is a one-to-one app) or occasional transport-layer feedback (such as multicast). These applications have different management aspects. If any, they also have different requirements or features for collecting feedback, processing it and acting on it. Their data structures also vary for carrying the feedback.

On the operations side, it is not advisable for the framework draft to explicitly list what the applications (sender or receiver or a middle-box) could do upon observing something in particular or receiving a specific feedback. At best, the framework can 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 encouraged since RTCP has already solved many of these issues in an agnostic way of the data carried with RTP.

Overall, the framework as it stands now makes use of existing specifications as much as possible and does not dictate the use of any particular technology for transporting FEC data, managing the endpoints, signaling the configuration information, or encoding the configuration information. We had this flexibility since the beginning to cover all the wide range of all possible scenarios where this framework (and the resulting CDPs and schemes) could be used.

Proposed changes to the framework:

I think the IESG is right for expecting to see some text about this. My proposal is to have a summary at the end of the document mostly mentioning the things I provided above (of course after incorporating any feedback from you).

If anybody has another proposal or objects to this, please speak up. If you are OK with this, your email would also help to show the WG consensus to the IESG.

Thanks,
-acbegen