130 likes | 604 Views
Simple LDPC-Staircase FEC Scheme for FECFRAME draft-roca-fecframe-ldpc-01. IETF 79 – Beijing, November 2010 V. Roca – M. Cunche (INRIA) J. Lacan (ISAE). Goals. specifies how to use LDPC-staircase codes in FECFRAME complements our RFC 5170 (RMT WG)
E N D
Simple LDPC-Staircase FEC Scheme for FECFRAME draft-roca-fecframe-ldpc-01 IETF 79– Beijing, November 2010 V. Roca – M. Cunche (INRIA) J. Lacan (ISAE)
Goals • specifies how to use LDPC-staircase codes in FECFRAME • complements our RFC 5170 (RMT WG) • provides a single scheme: LDPC-Staircase for arbitrary packet flows • DOES NOT consider RTP framing of FEC repair packets • left to future works if the need arises…
Modifications since -00 version • initial -00 version in July 2009 • get stuck by Qualcomm's patent on FECFRAME • same situation as that of Reed-Solomon • forced to wait until the situation is clarified • 00 versus 01 modifications: • take draft-roca-fecframe-simple-rs-01 and replace reference to "Reed-Solomon" by "LDPC-Staircase" • RS and LDPC I-D are now almost the same • only minor modifications to address LDPC specificities (e.g. FSSI) • same philosophy : K.I.S.S. • restrict to the case where G==1 in RFC 5170 • see: http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html
Why yet another FEC scheme? • well suited to certain FECFRAME applications • with high bitrate flows • when a large number of flows must be globally protected • when low complexity software decoding is a MUST • complements (but does not replace) Reed-Solomon and 2D parity schemes • An example of use: K. Matsuzono, J. Detchart, M. Cunche, V. Roca, H. Asaeda "Performance Analysis of a High-Performance Real-Time Application with Several AL-FEC Schemes" IEEE Local Computer Networks (LCN'10), October 2010
DVTS/FECFRAME results (from LCN'10) • DVTS: a high-performance/high-throughput real-time/interactive video application over IP • Digital Video Transport System (DVTS) • support DV/HDV formats • CBR flows: 30 Mbps (DV format) • widespread use (symposium, e-learning, telemedicine) • see: http://www.sfc.wide.ad.jp/DVTS/ • http://www.internet2.edu/communities/dvts/ sender DVTS fecframe lib. DVTS fecframe lib. IP networks (congestion, fading, etc)
Experimental Setup • 3 performance metrics: • recovery capabilities • frame delay above FECFRAME • CPU load
Experimental Setup packet loss proba. (0% ~51%) SENDER: Pentium4 / 2.4 GHz 512 MB RAM / 32-bit Linux RECEIVER: Core2 / 1.66GHz 512 MB RAM / 32-bit Linux
Results: recovery capabilities • 2D codes ☹ • unrecovered data loss continuously happens • RS, LDPC codes☺ • no data loss until 30% packet loss probability RS codes LDPC codes (k=170) LDPC codes (k=500, 1000) 2D codes
Results: frame delay after FECFRAME proc. • 2D codes: usually lower than 50msec ☺ • RS: ☹ • over 100msec around 12% loss rate • over 500msec around 30% loss rate • LDPC codes☺ • When k=170, 50msec until 24% loss rate, 89msec above ☺ • When k= 500,1000, greater especially in high loss rates ☹ RS codes LDPC codes (k=500, 1000)
Results: CPU load • sender: • receiver: RS codes LDPC codes (k=500, 1000) 2D codes LDPC codes (k=170)
Results • in summary: • for this target environment, LDPC-staircase codes (k=170) were the best choice • see paper for additional details… • additionally… • if several DVTS flows were to be carried between the same locations, globally FECFRAME protected, LDPC-staircase codes (with higher k) would be even more beneficial
More fundamentally, LDPC-staircase codes • …have excellent recovery capabilities • e.g. k=256 symbols, N1=7: average overhead=0.68% (i.e. 1.74 symbols in addition to k) • …while keeping very high decoding speeds • e.g. k=256, N1=7: 1.39-2.46 Gbps(Xeon 5120/1.86GHz, 64-bit Linux) • 12.6 to 28.2 times faster than RS over GF(28) RS over GF(24) LDPC (N1=7) RS over GF(24) RS over GF(28) RS over GF(28) LDPC (N1=5 & 7) Erasure recovery tests Decoding speed tests
To conclude • LDPC-staircase codes • simple, easy to understand and implement • close to ideal recovery performances • high performance codec developed in an open source project • an interesting alternative to proprietary codes • considered in standards • current I-D is considered as finished • ready for WGLC if accepted as WG Item