Presentation is loading. Please wait.

Presentation is loading. Please wait.

IETF#64 – 7-11 November 2005 fecframe BOF Chair:Mark Watson Mailing List:

Similar presentations


Presentation on theme: "IETF#64 – 7-11 November 2005 fecframe BOF Chair:Mark Watson Mailing List:"— Presentation transcript:

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

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

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

4 What is an “FEC over transport framework” ? “FEC”: Forward Error Correction “FEC”: Forward Error Correction Specifically, forward erasure correction Specifically, forward erasure correction Sending additional packets which can be used at the receiver to reconstruct lost packets Sending additional packets which can be used at the receiver to reconstruct lost packets “Over Transport” “Over Transport” Applying to arbitrary packet flows above the transport layer (UDP, DCCP, …) Applying to arbitrary packet flows above the transport layer (UDP, DCCP, …) “Framework” “Framework” Generalised description and mechanisms which can be used to quickly build protocols 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 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) High quality audio/video streaming (IPTV, Video on Demand) Over Internet/WANs Over Internet/WANs Over home networks Over home networks Over mobile wireless networks Over mobile wireless networks Other stream-based applications over the same networks Other stream-based applications over the same networks

6 Why FEC ? (1) What about retransmissions ? Multicast:/broadcast Multicast:/broadcast Retransmissions do not scale Retransmissions do not scale Unpredictable bandwidth usage Unpredictable bandwidth usage No/small backchannel No/small backchannel Unicast: Unicast: Sender retransmisson may not scale if many receivers Sender retransmisson may not scale if many receivers Retransmission may be too slow Retransmission may be too slow Unpredictable bandwidth usage Unpredictable bandwidth usage Aggregate backchannel bandwidth may be limited/nonexistent 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 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 Mobile wireless generally has high loss rates Could be addressed with vertical, market-specific solutions Could be addressed with vertical, market-specific solutions Would be better to have an IETF end-to-end solution 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 Very low end-to-end PLR is very hard to achieve on any network Packet loss in access network (xDSL, Wireless, Cable TV etc.) 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 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 FEC does not solve congestion losses Applications MUST reduce date rate in response to congestion Applications MUST reduce date rate in response to congestion FEC overhead should change with changing application data-rate 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) 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 Reliable Multicast Transport group Generic framework for FEC schemes (FEC Building Block) Generic framework for FEC schemes (FEC Building Block) Protocols for reliable object delivery, congestion control Protocols for reliable object delivery, congestion control No support for streaming media or protection of generalised IP flows No support for streaming media or protection of generalised IP flows Various FEC codes in progress: Various FEC codes in progress: Raptor code (passed WGLC) Raptor code (passed WGLC) LDGM Staircase and Triangle codes (WG item) LDGM Staircase and Triangle codes (WG item) Reed-Solomon (WG item any minute now…) Reed-Solomon (WG item any minute now…)

10 Previous work ctd. Audio Visual Transport Group Audio Visual Transport Group Simple XOR-based FEC for RTP media streams (RFC2733) Simple XOR-based FEC for RTP media streams (RFC2733) Very limited protection (24 packets at most to be protected) Very limited protection (24 packets at most to be protected) Specific to RTP Specific to RTP Inefficient support of variable length packets (padding) Inefficient support of variable length packets (padding) Update for Unequal Level Protection (in progress) Update for Unequal Level Protection (in progress) 3 rd Generation Partnership Project 3 rd Generation Partnership Project Complete protocol for FEC for media streaming over 3G broadcast/multicast system Complete protocol for FEC for media streaming over 3G broadcast/multicast system Protects multiple streams over UDP (e.g. RTP, RTCP, MIKEY) Protects multiple streams over UDP (e.g. RTP, RTCP, MIKEY) Generic – could be applied elsewhere but scope of standard is market-specific 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 Develop framework for FEC protection of arbitrary packet flows Support “pluggable” FEC codes (i.e. re-use RMT FEC Building Block) Support “pluggable” FEC codes (i.e. re-use RMT FEC Building Block) Support multiple transports (UDP, DCCP, etc.) Support multiple transports (UDP, DCCP, etc.) Support multiple applications (A/V streaming, data streaming, file delivery) Support multiple applications (A/V streaming, data streaming, file delivery) Protocol for FEC of streaming media Protocol for FEC of streaming media Coordinate with AVT and MMUSIC Coordinate with AVT and MMUSIC tbd: take on FEC code development from RMT tbd: take on FEC code development from RMT tbd: other protocols ? tbd: other protocols ?

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

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

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


Download ppt "IETF#64 – 7-11 November 2005 fecframe BOF Chair:Mark Watson Mailing List:"

Similar presentations


Ads by Google