FECFrame WG

Meeting Minutes

IETF 79

Thurs, November 10, 2010

1740-1940

Jade 1

The interim chair goes over the agenda and draft status. Thomas S. is the new editor for the Raptor drafts. Questions about Raptor drafts (should they be informational as opposed to standards track?). Magnus says there is benefit in publishing them in standards track (as RMT did).

The AD wants to confirm that the next two drafts (that Vincent is to present) are in the charter or not. They are not in the charter specifically but they are within the scope of FEC schemes.

Vincent starts with the first slide deck. Goes over the issues (related to IPR) that were addressed in the latest version. Says the draft is pretty mature to be adopted. The chair will ask the list.

The second slide deck. This is the RTP payload format for the RS codes. It will be finished by the next meeting, and accompanies the RS draft. AVT will have to review this and the chair will ask the WG to adopt it or not.

The AD - on the mic - says that if these FEC schemes will not be implemented by multiple vendors, they could actually go thru the AD-sponsored path.

The third deck. Motivation for this work is the low-decoding complexity for high-bitrate apps. It has different use cases compared to other existing FEC schemes. Discussing a very recent paper that explains the code and its performance. The AD asks whether there is any IPR on this. Vincent says "today, there is not on this draft but there are some IPR disclosures on a related RFC," which is 5170.

Ali starts discussing the IESG comments for the framework draft (Ali is the new editor).

* Concerning Management and Operations:

AD: IESG want to make sure that you properly thought about these issues, so try to put some simple text and guidelines. What should an operator like to know? What should a FECFRAME implementation provide?

* Concerning Congestion Control:

AD: If you don't know the history of the WG, it's hard to figure out why there is this rule of no more than twice the bandwidth.

Colin: There is a frequent misunderstanding about congestion control and FEC.

* Concerning Security:

Vincent: I'm the one who performed the SecDir review for this document. I think it's extremely important to have a detailed "security considerations" section since this is a framework document that is referenced by all  other FECFRAME documents. Among the things I think are required is a "mandatory to implement but not necessarily to use" security mechanism. It seems that requiring IPsec/ESP be mandatory is

fine. 

AD: I agree.

David (AD hat off): if we anticipate that FECFRAME will be used for something else than real-time flows, for instance for MIKEY or other applications, then it's better to mention it. MIKEY was just an example.

Magnus: You can use it as well for DNS. It needs to be better clarified.

David: You can have a discussion on how to apply it to a specific use-case in the Operations and Management section.

Concerning some fields starting from 0:

Colin: Clarify the assumptions about wrapping. There's also an issue about possible rekeying before the end of a block. You can have a look at the RTP security considerations.

Discussion started on how to handle future FEC Schemes if the FECFRAME is closed. Proposal is to have schemes with RTP framing of repair packets be managed by the AVT WG, and other schemes by the TSV WG.