FECFrame WG meeting minutes

IETF 72, Dublin Ireland

Agenda was accepted with no changes.

Marsahll Eubanks: Discussion of RFC2733.

SMPTE depends on RFC2733, which was obsoleted by RFC5109. Because SMPTE needs this, we are planning to un-obsolete RFC2733. SMPTE has a new group on HD, which will adopt RFC5109.

Magnus W. - question are we going to write heavy warnings about use of RFC2733.

Colin P. - need an applicability statement. Happy to help write the text. Will try to write and last call it by Friday.

Ali B. - for the record, should we recommend using 2733 for any further RFCs going forward.

Marshall - need to figure out if it goes in AVT or FECFRAME. We can get together and discuss. Need to figure out how to fix the limitations of 5109 as well.

Colin P - problem is we screwed up on 2733 and you could have packets that fail the validity check, so we should write this in the applicability statement.

Magnus - has implications for how you implement RTP.

Colin - thinks the way SMPTE uses 2733, it doesn't trip on the bugs.

Ali Begen - Presented 1-D Interleaved Parity FEC Scheme, which was also presented in AVT. See meeting materials for draft and slides.

Marshall - not familiar with SMPTE liaison...who has it? Does AVT?

Magnus - may not have formal liaison, but can send a message

Oran - can send an informal letter - doesn't need to be a formal liaison.

Manus - what's the intent? Just do an IETF version of what's in SMPTE?

Ali - no motivation from SMPTE, motivation is to have IETF RFC for the DVB AL-FEC approach. This draft does the base layer of DVB AL-FEC.

Magnus - how applicable is this for fec framework? Hinges on how you handle the RTP header - more generally how you incorporate RTP into the RTP framework.

Ali - maybe we shold do the next presentation first?

Ali Begen - Presented DVB AL-FEC draft (see meeting materials)

Magnus - where he got hung up is what if the WG finds things they don't like, what do we do?

Ali - we tried to fix all the problems other than those tied up in the 2733/5903 issue

Stefan Wengler - usual way forward is individual submission to informational - should this go through the WG. The reason is you otherwise need to have WG consensus.

Marshall - would Magnus agree to sponsor?

Magnus - has a personal problem - doesn't like all the RTP-specific things in here.

Marshall - should discus the whole issue of whether this gets done by AVT or FECFRAME

Magnus - can we actually do this?

Marshall - we can document what they did wrong and a few other things.

Ali - clarification - DVB just took SMPTE - now we can fix the RTP-related issues. Are willing to go along and make changes to follow our lead in next release.

Magnus- how much can we change this if we find an error.

Ali - still being backward compatible with DVB, other than fixing RTP violations.

Ali - there's been some discussion of whether we have a common RTP payload format for all fecframe schemes, or have separate RTP payload formats for different fecframe schemes.

Magnus - depends on how one sees the the relation with the fec framework. What is the fec id? What is part of the transport?

Marshall - should we make this a WG item? Not yet.

Conclusion: keep talking among the ADs (Cullen, Magnus), WG chairs (of AVT and fecframe), Ali. Try to settle this here in Dublin?

Magnus - we have a problem that there isn't enough traffic on the mailing list.

Ali - can take it to AVT?

Magnus - question here is issue on slicing and dicing the architecture of how fecframe relates to RTP.

Marshall - is part of the problem that once we finished the fec framework, we'd move on. Are we getting ahead of ourselves?

Greg- we put hold of framework precisely to get the chance to do this kind of work.

Bill Ver Steeg - we're actually not ahead of ourselves, not behind ourselves, since there is stuff in the field and more every day.

Marshall - personal feeling that this is specialized enough that it should be done here in fecframe

Magnus - sure, as long as you're using RTP in a sensible way, and how it fits together in the whole framework. We need to have that before we lock it down.

Marshall - when we finalized 2733, one person said it was deployed. If we'd had fecframe, we cold have caught the problem.

Ali - with respect to RFC3388 (grouping) we had a problem and now we have 3388bis that fixes this issue. Then we'll update 4756 to get the fec grouping to align.

Stefan - Need to have SDP equivalence for DVB XML signaling

Rajiv Asati - presented The fec signaling draft updates.

Marshall - on page 8, what's reserved bit?

Rajiv - just part of SAP

Marshall - do we need to say somehting about unicast

Oran - interesting unicast signaling protocols exist, and already use SDP.

Marshall - let's see if we can get a WG last call in August

Rajiv - will block on framework architecture doc anyway.

Ali B - stays a WG draft ntil the framework is done anyway.

Conclusion: last call is gated on framwork. Will do informal last call on the lst to see if this is ready.

Ulas Kizat presented Protecting Multiple Source flows (see meeting materials for draft and slides)

Oran - need to fix DNS names to follow IETF example dns rules.

Marshall - who would like to accept document as WG document

Ali - just for the record, as we were drafting, it may have seemed obvious but when you go to put bits on the wire it's not obvious. this can help

Ulas - other methods did not work out

Ali - lots of corner cases, nice example of showing the importance of framework draft

Rajiv - inclues the example of including source fec payload id, might be good to have an example where you don't need it.

Ulas - that's the obivous case, we wanted to cover the non-obivous cases where you need it.

Rajiv - stat with example that covers th madatory stuff, then add the optional things

Conclusion: take to the list and ask if it should be adopted.

Adjourned at 2:35.