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

14
IETF#64 – 7-11 November IETF#64 – 7-11 November 2005 2005 fecframe BOF fecframe BOF Chair: Mark Watson Mailing List: [email protected]

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

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

IETF#64 – 7-11 November IETF#64 – 7-11 November 20052005

fecframe BOFfecframe BOF

Chair: Mark WatsonMailing List: [email protected]

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

AgendaAgenda 1. Introduction, note taker, blue sheets1. Introduction, note taker, blue sheets 2. Agenda bashing2. Agenda bashing 3. Discussion of objectives, scope3. Discussion of objectives, scope - - Background, rationale, proposed Background, rationale, proposed

workwork - Goals and Milestones - Goals and Milestones - Relationship with RMT/transfer of - Relationship with RMT/transfer of

workwork 4. Agreement on way forward4. Agreement on way forward 5. AOB5. AOB

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

ContentsContents

What is an “FEC over transport What is an “FEC over transport framework” ?framework” ?

Why do we need it ?Why do we need it ? Previous workPrevious work Proposed objectivesProposed objectives Way forwardWay forward

If time: outline requirementsIf time: outline requirements

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

What is an “FEC over What is an “FEC over transport framework” ?transport framework” ?

““FEC”: Forward Error CorrectionFEC”: Forward Error Correction Specifically, forward Specifically, forward erasureerasure correction correction Sending additional packets which can be used Sending additional packets which can be used

at the receiver to reconstruct lost packetsat the receiver to reconstruct lost packets ““Over Transport”Over Transport”

Applying to arbitrary packet flows above the Applying to arbitrary packet flows above the transport layer (UDP, DCCP, …)transport layer (UDP, DCCP, …)

““Framework”Framework” Generalised description and mechanisms Generalised description and mechanisms

which can be used to quickly build protocolswhich can be used to quickly build protocols Not a complete protocol, but most of the stuff Not a complete protocol, but most of the stuff

you need to build oneyou need to build one

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

Target applicationsTarget applications

High quality audio/video High quality audio/video streaming (IPTV, Video on streaming (IPTV, Video on Demand)Demand) Over Internet/WANsOver Internet/WANs Over home networksOver home networks Over mobile wireless networksOver mobile wireless networks

Other stream-based applications Other stream-based applications over the same networksover the same networks

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

Why FEC ? (1)Why FEC ? (1)What about retransmissions ?What about retransmissions ?

Multicast:/broadcast Multicast:/broadcast Retransmissions do not scaleRetransmissions do not scale Unpredictable bandwidth usageUnpredictable bandwidth usage No/small backchannelNo/small backchannel

Unicast:Unicast: Sender retransmisson may not scale if Sender retransmisson may not scale if

many receiversmany receivers Retransmission may be too slowRetransmission may be too slow Unpredictable bandwidth usageUnpredictable bandwidth usage Aggregate backchannel bandwidth may Aggregate backchannel bandwidth may

be limited/nonexistentbe limited/nonexistent

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

Why FEC ? (2)Why FEC ? (2)Are packet loss rates that Are packet loss rates that

bad ?bad ? ITU-T Y.1541 original IP QoS targets 10ITU-T Y.1541 original IP QoS targets 10-3-3 IP IP

Packet Loss Rate – much too high for high Packet Loss Rate – much too high for high quality SD/HD video streamingquality SD/HD video streaming

Mobile wireless generally has high loss ratesMobile wireless generally has high loss rates Could be addressed with vertical, market-specific Could be addressed with vertical, market-specific

solutionssolutions Would be better to have an IETF end-to-end solutionWould be better to have an IETF end-to-end solution

Very low end-to-end PLR is very hard to achieve Very low end-to-end PLR is very hard to achieve on any networkon any network Packet loss in access network (xDSL, Wireless, Cable Packet loss in access network (xDSL, Wireless, Cable

TV etc.)TV etc.) Core networks generally reliable but very hard Core networks generally reliable but very hard

(=expensive) to engineer entire end-to-end path for (=expensive) to engineer entire end-to-end path for extremely low loss rates – especially for extremely low loss rates – especially for multicast/broadcastmulticast/broadcast

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

A note on congestionA note on congestion

FEC does FEC does notnot solve congestion losses solve congestion losses Applications MUST reduce date rate in Applications MUST reduce date rate in

response to congestion response to congestion FEC overhead should change with FEC overhead should change with

changing application data-ratechanging application data-rate FEC relationship to congestion control is FEC relationship to congestion control is

not qualitatively different from not qualitatively different from application layer redundancy (e.g. in application layer redundancy (e.g. in video coding)video coding)

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

Previous workPrevious work

Reliable Multicast Transport groupReliable Multicast Transport group Generic framework for FEC schemes (FEC Generic framework for FEC schemes (FEC

Building Block)Building Block) Protocols for reliable object delivery, Protocols for reliable object delivery,

congestion controlcongestion control No support for streaming media or protection of No support for streaming media or protection of

generalised IP flowsgeneralised 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…)

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

Previous work ctd.Previous work ctd.

Audio Visual Transport GroupAudio Visual Transport Group Simple XOR-based FEC for RTP media streams Simple XOR-based FEC for RTP media streams

(RFC2733)(RFC2733) Very limited protection (24 packets at most to be Very limited protection (24 packets at most to be

protected)protected) Specific to RTPSpecific 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) 33rdrd Generation Partnership Project Generation Partnership Project

Complete protocol for FEC for media streaming Complete protocol for FEC for media streaming over 3G broadcast/multicast systemover 3G broadcast/multicast system

Protects multiple streams over UDP (e.g. RTP, Protects multiple streams over UDP (e.g. RTP, RTCP, MIKEY)RTCP, MIKEY)

Generic – could be applied elsewhere but scope of Generic – could be applied elsewhere but scope of standard is market-specificstandard is market-specific

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

fecframe Objectivesfecframe Objectives

(from BOF description)(from BOF description) Develop framework for FEC protection of Develop framework for FEC protection of

arbitrary packet flowsarbitrary packet flows Support “pluggable” FEC codes (i.e. re-use RMT Support “pluggable” FEC codes (i.e. re-use RMT

FEC Building Block)FEC Building Block) Support multiple transports (UDP, DCCP, etc.)Support multiple transports (UDP, DCCP, etc.) Support multiple applications (A/V streaming, data Support multiple applications (A/V streaming, data

streaming, file delivery)streaming, file delivery) Protocol for FEC of streaming mediaProtocol for FEC of streaming media

Coordinate with AVT and MMUSICCoordinate with AVT and MMUSIC tbd: take on FEC code development from RMTtbd: take on FEC code development from RMT tbd: other protocols ?tbd: other protocols ?

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

Way forwardWay forward New working group ?New working group ?

Work is not appropriate for AVT (not just RTP) or Work is not appropriate for AVT (not just RTP) or RMT (not just multicastRMT (not just multicast and bulk object delivery)and bulk object delivery)

TSVWG is overloaded and task is probably too bigTSVWG is overloaded and task is probably too big Resources are available for a focussed, short-lived Resources are available for a focussed, short-lived

WGWG Initial Deliverables:Initial Deliverables:

Requirements (Informational)Requirements (Informational) Scope work quickly at outset – publish at end of processScope work quickly at outset – publish at end of process

FEC Framework (Standards Track)FEC Framework (Standards Track) FEC protocol for streaming media (Standards FEC protocol for streaming media (Standards

Track)Track) Joint/coordinated with AVT and MMUSICJoint/coordinated with AVT and MMUSIC

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

Outline requirementsOutline requirements

““SHALL” requirementsSHALL” requirements Support of a wide range of FEC codes, using the Support of a wide range of FEC codes, using the

abstractions of the FEC Building Block defined in abstractions of the FEC Building Block defined in RMTRMT

Short and long block FEC codesShort and long block FEC codes Systematic and non-systematic codesSystematic and non-systematic codes Variable protection amounts and protection periodsVariable protection amounts and protection periods

Independence from application protocolIndependence from application protocol Support variable packet rates and packet sizesSupport variable packet rates and packet sizes

Support of combined protection of multiple packet Support of combined protection of multiple packet flowsflows

Support of multiple transport protocols (UDP, Support of multiple transport protocols (UDP, DCCP, others ?)DCCP, others ?)

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

Outline requirements Outline requirements ctd.ctd.

““SHALL” requirements ctd.SHALL” requirements ctd. Support definition of backwards-Support definition of backwards-

compatible protocolscompatible protocols i.e. include case where source packets are i.e. include case where source packets are

not modified in any waynot modified in any way

““SHOULD” requirementsSHOULD” requirements Include 3GPP protocol as a sub-caseInclude 3GPP protocol as a sub-case