1 / 14

IETF#64 – 7-11 November 2005 fecframe BOF

IETF#64 – 7-11 November 2005 fecframe BOF. Chair: Mark Watson Mailing List: fecframe@ietf.org. Agenda. 1. Introduction, note taker, blue sheets 2. Agenda bashing 3. Discussion of objectives, scope - Background, rationale, proposed work - Goals and Milestones

boerger
Télécharger la présentation

IETF#64 – 7-11 November 2005 fecframe BOF

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related