Download PPT Version

IETF#64 – 7-11 November 2005
fecframe BOF
Chair:
Mailing List:
Mark Watson
[email protected]
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

Contents

What is an “FEC over transport framework” ?
Why do we need it ?
Previous work
Proposed objectives
Way forward

If time: outline requirements




What is an “FEC over transport
framework” ?

“FEC”: Forward Error Correction



“Over Transport”


Specifically, forward erasure correction
Sending additional packets which can be used at the receiver
to reconstruct lost packets
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
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
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

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
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)

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…)
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
fecframe Objectives

(from BOF description)
Develop framework for FEC protection of arbitrary
packet flows




Protocol for FEC of streaming media



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)
Coordinate with AVT and MMUSIC
tbd: take on FEC code development from RMT
tbd: other protocols ?
Way forward

New working group ?




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
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
Outline requirements

“SHALL” requirements

Support of a wide range of FEC codes, using the
abstractions of the FEC Building Block defined in RMT




Independence from application protocol



Short and long block FEC codes
Systematic and non-systematic codes
Variable protection amounts and protection periods
Support variable packet rates and packet sizes
Support of combined protection of multiple packet flows
Support of multiple transport protocols (UDP, DCCP, others
?)
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