IETF#64 – 7-11 November 2005 fecframe BOF

1. IETF#64 – 7-11 November 2005fecframe BOF Chair: Mark Watson Mailing List: fecframe@ietf.org

2. Agenda • 1. Introduction, note taker, blue sheets • 2. Agenda bashing • 3. Discussion of objectives, scope • - Background, rationale, proposed work • - Goals and Milestones • - Relationship with RMT/transfer of work • 4. Agreement on way forward • 5. AOB

3. Contents • What is an “FEC over transport framework” ? • Why do we need it ? • Previous work • Proposed objectives • Way forward • If time: outline requirements

4. What is an “FEC over transport framework” ? • “FEC”: Forward Error Correction • Specifically, forward erasure correction • Sending additional packets which can be used at the receiver to reconstruct lost packets • “Over Transport” • Applying to arbitrary packet flows above the transport layer (UDP, DCCP, …) • “Framework” • Generalised description and mechanisms which can be used to quickly build protocols • Not a complete protocol, but most of the stuff you need to build one

5. Target applications • High quality audio/video streaming (IPTV, Video on Demand) • Over Internet/WANs • Over home networks • Over mobile wireless networks • Other stream-based applications over the same networks

6. Why FEC ? (1)What about retransmissions ? • Multicast:/broadcast • Retransmissions do not scale • Unpredictable bandwidth usage • No/small backchannel • Unicast: • Sender retransmisson may not scale if many receivers • Retransmission may be too slow • Unpredictable bandwidth usage • Aggregate backchannel bandwidth may be limited/nonexistent

7. Why FEC ? (2)Are packet loss rates that bad ? • ITU-T Y.1541 original IP QoS targets 10-3 IP Packet Loss Rate – much too high for high quality SD/HD video streaming • Mobile wireless generally has high loss rates • Could be addressed with vertical, market-specific solutions • Would be better to have an IETF end-to-end solution • Very low end-to-end PLR is very hard to achieve on any network • Packet loss in access network (xDSL, Wireless, Cable TV etc.) • Core networks generally reliable but very hard (=expensive) to engineer entire end-to-end path for extremely low loss rates – especially for multicast/broadcast

8. A note on congestion • FEC does not solve congestion losses • Applications MUST reduce date rate in response to congestion • FEC overhead should change with changing application data-rate • FEC relationship to congestion control is not qualitatively different from application layer redundancy (e.g. in video coding)

9. Previous work • Reliable Multicast Transport group • Generic framework for FEC schemes (FEC Building Block) • Protocols for reliable object delivery, congestion control • No support for streaming media or protection of generalised IP flows • Various FEC codes in progress: • Raptor code (passed WGLC) • LDGM Staircase and Triangle codes (WG item) • Reed-Solomon (WG item any minute now…)

10. Previous work ctd. • Audio Visual Transport Group • Simple XOR-based FEC for RTP media streams (RFC2733) • Very limited protection (24 packets at most to be protected) • Specific to RTP • Inefficient support of variable length packets (padding) • Update for Unequal Level Protection (in progress) • 3rd Generation Partnership Project • Complete protocol for FEC for media streaming over 3G broadcast/multicast system • Protects multiple streams over UDP (e.g. RTP, RTCP, MIKEY) • Generic – could be applied elsewhere but scope of standard is market-specific

11. fecframe Objectives (from BOF description) • Develop framework for FEC protection of arbitrary packet flows • Support “pluggable” FEC codes (i.e. re-use RMT FEC Building Block) • Support multiple transports (UDP, DCCP, etc.) • Support multiple applications (A/V streaming, data streaming, file delivery) • Protocol for FEC of streaming media • Coordinate with AVT and MMUSIC • tbd: take on FEC code development from RMT • tbd: other protocols ?

12. Way forward • New working group ? • Work is not appropriate for AVT (not just RTP) or RMT (not just multicastand bulk object delivery) • TSVWG is overloaded and task is probably too big • Resources are available for a focussed, short-lived WG • Initial Deliverables: • Requirements (Informational) • Scope work quickly at outset – publish at end of process • FEC Framework (Standards Track) • FEC protocol for streaming media (Standards Track) • Joint/coordinated with AVT and MMUSIC

13. Outline requirements • “SHALL” requirements • Support of a wide range of FEC codes, using the abstractions of the FEC Building Block defined in RMT • Short and long block FEC codes • Systematic and non-systematic codes • Variable protection amounts and protection periods • Independence from application protocol • Support variable packet rates and packet sizes • Support of combined protection of multiple packet flows • Support of multiple transport protocols (UDP, DCCP, others ?)

14. Outline requirements ctd. • “SHALL” requirements ctd. • Support definition of backwards-compatible protocols • i.e. include case where source packets are not modified in any way • “SHOULD” requirements • Include 3GPP protocol as a sub-case