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

Goals Goals specifies how to use LDPC-staircase codes in FECFRAME mcomplements our RFC 5170 (RMT WG) mprovides a single scheme: LDPC-Staircase for arbitrary packet flows DOES NOT consider RTP framing of FEC repair packets mleft to future works if the need arises… 2

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

Why yet another FEC scheme? well suited to certain FECFRAME applications mwith high bitrate flows mwhen a large number of flows must be globally protected mwhen 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 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

DVTS/FECFRAME results (from LCN'10) DVTS: a high-performance/high-throughput real- time/interactive video application over IP mDigital Video Transport System (DVTS) msupport DV/HDV formats mCBR flows: 30 Mbps (DV format) mwidespread use (symposium, e-learning, telemedicine) see: sender DVTS fecframe lib. DVTS fecframe lib. IP networks (congestion, fading, etc) 5

Experimental Setup 3 performance metrics: mrecovery capabilities mframe delay above FECFRAME mCPU load FEC CodesSymbol Length (Bytes) Code RateSource Block Length (k) N1 2D Codes13752/316none RSE Codes13752/3170none LDPC Codes13752/3(1)170 (2)500 (3)

Experimental Setup SENDER: Pentium4 / 2.4 GHz 512 MB RAM / 32-bit Linux SENDER: Pentium4 / 2.4 GHz 512 MB RAM / 32-bit Linux RECEIVER: Core2 / 1.66GHz 512 MB RAM / 32-bit Linux RECEIVER: Core2 / 1.66GHz 512 MB RAM / 32-bit Linux packet loss proba. (0% ~ 51%) 7

2D codes 2D codes ☹ munrecovered data loss continuously happens RS, LDPC codes ☺ mno data loss until 30% packet loss probability RS codes LDPC codes (k=170) LDPC codes (k=500, 1000) Results: recovery capabilities 8

2D codes: usually lower than 50msec ☺ RS: ☹ mover 100msec around 12% loss rate mover 500msec around 30% loss rate LDPC codes ☺ mWhen k=170, 50msec until 24% loss rate, 89msec above ☺ mWhen k= 500,1000, greater especially in high loss rates ☹ RS codes LDPC codes (k=500, 1000) Results: frame delay after FECFRAME proc. 9

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

Results in summary: mfor this target environment, LDPC-staircase codes (k=170) were the best choice msee paper for additional details… additionally… mif 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 11

More fundamentally, LDPC-staircase codes …have excellent recovery capabilities me.g. k=256 symbols, N1=7: average overhead=0.68% (i.e symbols in addition to k) …while keeping very high decoding speeds me.g. k=256, N1=7: Gbps (Xeon 5120/1.86GHz, 64-bit Linux) m12.6 to 28.2 times faster than RS over GF(2 8 ) RS over GF(2 8 ) RS over GF(2 4 ) LDPC (N1=5 & 7) RS over GF(2 4 ) RS over GF(2 8 ) LDPC (N1=7) Erasure recovery testsDecoding speed tests 12

To conclude LDPC-staircase codes msimple, easy to understand and implement mclose to ideal recovery performances mhigh performance codec developed in an open source project man interesting alternative to proprietary codes mconsidered in standards current I-D is considered as finished mready for WGLC if accepted as WG Item 13