IETF 71, FECFrame WG Agenda
Philadelphia
3/10/8

Agenda

Introduction, Agenda Bashing - 5min 		Chairs
FECFrame Proto Team update - 10 mins	Chairs
FECFrame Config Signaling - 15mins		Rajiv Asati
	draft-asati-fecframe-config-signaling
SDP Elements - 15 mins				Ali Begen
	draft-begen-fecframe-sdp-elements
FEC Grouping issues in SDP - 15mins		Ali Begen
	draft-begen-mmusic-fec-grouping-issues
COP3 2D - 15 mins					Ali Begen
	draft-begen-fecframe-1d2d-parity-scheme
DVB AL-FEC scheme / Framework - 15mins	Mark Watson


Agenda Bashing

Rajiv - config signalling proposal: sap exists for multicasting, no common protocol for unicast

Dave - recursive rathole using sap for signaling fec
Dave - SDP inside SAP could be bigger than MTU
Jean-Francois - concern using UDP if NAT is in between
Marshall - signaling and data would have same NAT problems
Dave - nobody NATs mcast
Marshall - yes they do
Dave - do you ever signal fec independently of everything else
Marshal -- one of use cases: one box sends stream, another box sends fec
Dave  - what ties them together, SDP?
Dave - receiver state sync problem is a challenge
Dave - independent FEC signaling could conflict with application signaling, maybe better approach is to define guidelines for signaling within application
Mark - fecframe charter says application protocol should decide configuration, fecframe wg provides tools for doing that, whether or not they choose to use them
Dave - agree, but then starting seeing things about session timeout intervals
Marshall - don't forget we have a Jabber session
Greg - take it to the list in terms of adoption
Colin - SAP is problematic b/c of long interpacket arrival time
Rajiv - adaptive interval calculation based on number of speakers, draft proposes fixed time interval

Ali Begen - SDP elements:

Dave - number of cases: 1) other FECFrame framework already exists, e.g., RTP) also with SIP, if no application layer to fit feedback, is it good to invent one here, or tell application to have reporting frameworks
Mark - agree, application-level decision, not sure how we could do anything generic, whether RTP or not
Ali - Some suggestions, some stuff planning to add to framework
Rajiv - we all agree we need feedback/reporting, but generic independent mechanism...or let applications dictate if they want it and if so, can they do it on their own
Dave - agree, we should distinguish what sorts of things apps should be interested in if applying fec....what sort of metrics to pay attention to, but not how to encode or signal it
Mark - I was gonna say that
Rajiv - Ditto
Jean Francois - maybe useful if repair window expressed in rtp timestamp units
Mark - no sense using rtp units, should be generic, timing relationship should be independent of protocol
Jean Francois - likely to target RTP?
Mark  - repair flow may not be same protocol, can protect multiple source flows that have different rtp timestamp frequencies
Rajiv - source may not even be rtp
Ali - Need SDP element for receivers to report feedback?  In common case, sender will need feedback
? - if not defining generic metric, no point in defining in framework

Ali - FEC Grouping Issues in SDP

Want flexibility for source/repair flow grouping: additive repair flows for higher recovery chances, prioritization

<lots of talking away from mic>
Jean-Francois - if nobody objects, updating RFC
? -?
? -?
</lots of talking away from mic>

Approaches: (1) New Grouping Attribute (2) New Grouping Semantics, both are backward-compatible but new grouping attribute is safer
Greg - does that mean they can be additive and prioritized
Ali - yes, not sure how to do without prioritization without additive
Mark - have one solution if 3388 updated, another for if 3388 not
Rajiv - backward compatibility is big concern, I'm in favor of proposing our own document
Mark - whatever happens, use 3388 syntax where it works, only use new syntax for advanced/unsupported cases
Ali - that's why we're coming up with new group, just discard if you don't understand
Rajiv - For simple 1:1 Source:Repair, just use what's already there, agree
Ali - Might need to update both 4756 and 3388
Rajiv - our draft should be inclusive
Ali - should be 2 separate drafts
Ravji - ok
some german guy - 3388 should be updated, why need gengroup if 3388 is updated?
sgg - need one new document that relies on updated 3388, defines grouping semantics
Jim - I'm new, don't listen to me, situation seems like a housecleaning issue
Ali - if you don't understand new semantics, you'll just ignore, so no bw compat problem
Jim - then let's do that

Ali - Fully-specified FEC Scheme for 1D and 2D, RTP payload for the corresponding FEC, not bw compat with 5109 (or SMPTE 2022-1)

Mark - Why not SMPTE 2022-1?
Ali - not using same fields, based on 2733, 2733 obsoleted with 5109, not compat with 5109
Mark - what, specifically, isn't compatible?
Ali - short answer - not using same fields in header, even if same fields, not for same purpose, take full discussion offline

Mark - point of framework is to define as much as possible that's common, if we keep defining exceptions, we undermine the framework
Rajiv - part missing from framework draft -- we need to consider that application layer can directly hand packets to fec framework, also communication between transport protocol and fec framework
Magnus - if generic mechanism, needs to be low as possible in the stack
Magnus - why are we defining an RTP payload for an FEC scheme
Rajiv - RTP means RTCP which gives us benefits
Mark - this is too specific, need to keep generic, FEC Scheme is the place to put things that don't belong in the generic framework

<fuzzy>
Magnus - not following why we're using RTP specifically
Dave - intent is to map source and repair flows independently, if you RTP encap source data, should RTP encap FEC
Magnus - Would like to see actual benefits of doing that
Ali -
Mark  - don't understand multiple receiver joining multiple flows relationship to RTP
Ali - I want RTCP support for my repair flows, so why not use RTP-encap repair data?
</fuzzy>

Mark - 2 topics: Merits of using RTP at all; Changing architecture.  What I said before about putting stuff in FEC scheme
Magnus - if repair data and source at different layers, need to
Rajiv - depends on FEC FW instance or FEC scheme - app provides data to FEC, FEC provides repair to app
Dave - obsessing too much about diagrams if everything is on the same system; could we have generic RTP payload for fec framework that works across fec scheme, Mark's comment is that it doesn't make a lot of sense, I agree; don't want specifics depending on encap and fec schemes
Magnus - should separate source data from ...?
Dave - use case for RTP-encap fec data for non-RTP-encap source data?  Can't think of one
Rajiv - should we consider 2 framework specs: 1 for UDP/IP and 1 for RTP/UDP/IP?
Mark - we decided against RTP-specific implementation, need something generic
? - don't want to overgeneralize mechanisms
Magnus - Need clear motivation for why RTP is better than anything else if going forward with this approach
? - ?

Mark - what is the difference between type of prot and type of fec data?

Ali - type of prot is for sender, type of fec is for receiver
Mark - seems redundant
Mark - why not just separate fec schemes for row and column?
Dave - want to promote separation and clear intent within SDP rather than hiding in the details of the schemes
Greg - 2 schemes can be grouped as additive (row & column)
Bill - Definitely need to define sending arrangements
Greg - take it to the list
Magnus - is this in the charter of this wg?
? - this violates our charter
Mark - We always said we could propose fec schemes that had a narrower approach, even if the framework is more generic

Mark - DVB AL-FEC Overview