Minneapolis fecframe session 1 notes

Chairs – Marshall Eubanks, Greg Shepherd

Note taker – Bill VerSteeg

Agenda bashing -

Magnus Westerlund– mmusic needs to be on the conflict list

Chairs – thought we had done this, will go back to powers that be and coordinate with A-Ds

Draft-ietf-fecframe-framework – Mark Watson

Mark walked through changes from framework-02 to framework-03

FEC schemes specify RTP transport flows

Feedback via RTP/RTCP

Magnus – how do we handle feedback for non RTP flows?

Marshall- no desire to reinvent RTCP

Magnus- Also need to consider aggregate flows

Mark – walking through presentation - added optional RTP demux for FEC and source, followed by RTP processing of source

Marshall – what is status of framework? Once we address Magnus’ concerns, is this ready for last call? No objections noted

1-D and 2-D Parity FEC – Ali Begen

Ali walked through introduction to 1D and 2D FEC, including brief overview of XOR based FEC

No backward compatibility, but full RTP compliance

Magnus – is RTCP CNAME adequate for associating flows? Maybe require same SSRC for both flows

Marshall- What would we be multiplexing on?

Magnus – port or address , depending if the flows are on the same or different RTP sessions. Need to be careful of SSRC collisions

Marshall – need to describe desired SSRC behavior in the FEC documents rather than refer it to AVT

Bill VerSteeg – suggest refer CNAME correlation to AVT rather than fixing it in fecframe

Ali and Magnus – discussion of mappings done in retransmission flows and how it compares to the CNAME problem under discussion for FECFRAME –

Bill – we should try to converge unicast and multicast repair flows, as well as FEC and explicit packets. A common CNAME convention between the models is desirable

Ali – continuing with header discussions, IANA registrations, SDP, and SMPTE liaison from presentation

Marshall – VSF work should be a normative reference to the IETF work –

Ali – not using the SMPTE 2022-1 spec, not backwards compatible, so a normative reference is not advisable

DVB AL-FEC – Ali Begen

Ali walked through the 1-D baseline parity code and Raptor enhancement layer

Baseline mandatory, enhancement optional

Old spec was UDP for Raptor, RTP for parity – new spec is RTP for all

Outline of differences between RFC 3550 and SMPTE 2022-1

Outline of resolution plan for aligning IETF and DVB

Outline of IANA registration issues

Marshall – request update on DVB liason

Ali – New RTP profile by DVB may fix SSRC, CSRC and “96” issues – timestamp issue remains, though – fielded systems present problems to changing the DVB spec

Magnus and Ali – discussing merits of converging DVB and IETF vs letting DVB move independently – suggest completing IETF effort and recommend to DVB to reference the new draft

FEC Grouping Semantics in SDP – Ali Begen

Ali walked through presentation - Similar to mmusic presentation

Describe the relationships between the various flows, and the required SDP to describe those relationships.

Describe the new semantics for additive and priority relationships

Describe problems for equal-priority and equal additive properties

Marshall – compare to BGP solution for priority

Ali, Greg – motivation for priority dynamically specified rather than a-priori assignment

Dave Oran – what is motivation for including flow priority in SDP?

Marshall, Ali, Marshall – discussion of additive FEC that requires ordering of FECs vs associative ordering – no non-systematic codes, so each FEC could be useful in the absence of other flows – flow ordering is for efficiency

Mark Watson – Can always use a lower priority FEC even though a higher priority flow is lost – priority was designed to allow massive use of smaller number of flows

Dave – network resources should not be primary driver for this design

Marshall/Dave/Ali – maybe we should call this preference rather than priority- but SHOULD/MUST gets wrapped up in “priority/preference” discussion

Mark/Ali/Marshall/Greg – is the discussion around FEC priority an SDP issue or a framework issue?

Rajiv Asati – “preference” is better than “priority” – equal priority should be deterministic, perhaps via instance ID

Ali – need to have this functionality

Config Signaling – Rajiv Asati

Draft 00 to draft 01 – minor textual updates regarding usage

Suggestion for last call after framework document goes to last call

FECFRAME – Raptor – Mark Watson

Mark walks through overview document

3 FEC schemes for Raptor

3GPP protect multiple source flows, using packet tagging to identify source packets

DVB optimized Raptor for arbitrary flows – restricted set of block sizes

DVB single sequenced flow

Alignment with recent DVB changes

Defines RTP header fields as per DVB

Proposed for adoption as working group item

Ali – are we supposed to define the RTP format parameters in the SDP?

Mark – 2 options – RTP payload format specific SDP or generic format

Magnus – is torn between define payload specific format and generic format – perhaps a generic framework that allows for specific portions?

Mark – isolate FEC SDP parsing from general flow SDP parsing

Magnus – differentiate general parsing from FEC parsing – take this issue to a cross discussion between AVT and FECFRAME

OPEN DISCUSSION

Greg – want to discuss feedback using RTCP

Magnus – should use RTCP for feedback – need to consider cases that do not use RTP

Marshall- need to consider FLASH and Windows Media, which do not use RTP