1 / 13

Simple LDPC-Staircase FEC Scheme for FECFRAME draft-roca-fecframe-ldpc-01

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)

wynter-malone
Download Presentation

Simple LDPC-Staircase FEC Scheme for FECFRAME draft-roca-fecframe-ldpc-01

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. 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)

  2. 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…

  3. 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

  4. 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

  5. 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)

  6. Experimental Setup • 3 performance metrics: • recovery capabilities • frame delay above FECFRAME • CPU load

  7. 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

  8. 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

  9. 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)

  10. Results: CPU load • sender: • receiver: RS codes LDPC codes (k=500, 1000) 2D codes LDPC codes (k=170)

  11. 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

  12. 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

  13. 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

More Related