FEC & File Multicast

Slide 1: ECC Applications and Simulation Multicast Methods Using ECC Yossi Cohen & Yitzhak Aviv

Slide 2: Motivation Why look at applications?  We have already looks at the inner working of the codes and the results of small scale simulations. Looking at the application will help us broaden our knowledge and review results of large scale simulations. Why look at Multicast file transfer?  The multicast scheme should be smart enough to compensate not just for the characteristics of a single channel as is the case in classical communication, but for characteristics of many channels that are varying over time.  Multicast file transfer application are gaining popularity. They are used in many areas from software update to peer-to-peer networking.

Slide 3: What is multicast ? When many users need the same info at the same time it is better to duplicate the packets in the last router rather then send it separately to each user. Topics need to be considered:  Group membership management  Routing management protocols  Loss notification  Loss Handling

Slide 4: Taxonomy Multicast No Feedback No ECC  Cyclic UDP ECC without feedback Feedback Hybrid FEC  Reed-Solomon on the entire file  Reed-Solomon on Blocks  tornado coding on the SRM Digital file (Digital fountain MFTP/EC SomeCast RMTP Fountain approach) Feedback without FEC  MFTP Hybrid methods FEC & Cyclic feedback UDP  MFTP/EC  SomeCast

Slide 5: File Multicast Solution Requirements Reliable – Guarantee file delivery to all the receivers. Efficient – The total number of packets that each client receives and the amount of processing needed to construct the file from these packets should be minimal. On-Demand – clients may initiate a download at their discretion. The session may be interrupted several times. Versatile – the protocol should tolerate a heterogeneous population of receivers over a variety of connection types: wireless, satellite, wire-line with different packet loss statistics.

Slide 6: Quality of the solution The solution should have a minimum average time till the file can be in use at the user computer: ttotal = trec + tdec There is usually a tradeoff between fast decoding algorithms (such as tornado coding) and the transmission overhead they cause.

Slide 7: Why use FEC in multicast? The multicast group interface solved the problem of multiple packets that hold the same information from originating from the sender. However there is still a problem of too many NACKs or ACKs originating from the receivers. This problem is known as “NACK implosion” Several methods exist to solve this problem:  Creating local point of control that would handle the NACKs.  Back off NACK timing (SRM for example).  FEC Advantages of FEC  Enable reliable multicast when there is no back channel.  No processing overhead in control points.  Very low ECC reception overhead (In tornado codes ~0.05)

Slide 8: Erasure advantage over error In this type of computer communication we don’t consider errors, a packet is either received correctly or not received – an erasure. Bad packets are removed on lower network layers by comparing them to the CRC. Next we will explain the advantages of erasures over errors. Block Code: C (n ,k ,d) Error correction capability: t = ￪d - 1 Code Rate: R = k n ￪ 2 ￫ “Singleton Bound” on minimum distance: d ≤ n-k+1 MDS (maximum distance separable): Code that achieves the Singleton Bound.

Slide 9: Reed-Solomon Code Block code => cyclic code => BCH code => reed-Solomon code. Code RS(n,k) is a MDS code: d=n-k+1 ￪d - 1 ￪n - k t RS = ￪ =￪ ￫ 2 ￫ 2 RS code is over q-ary alphabet, usually: n = 2m - 1 where m is the symbol size q = 2m Algebraic code – easy to implement. Can decode erasures.

Slide 10: Performance Computation: definitions  PCD - Pr {correct decode} PCD + PID + PDF = 1  PID - Pr {incorrect decode}  P - Pr {fail to decode} PNCD = 1 - PCD DF NCD - Pr {not correct decode}  P  P - Pr {symbol error} e For errors only situation: ￦ i n n -i i n Pe = ￥ ￗe ￗ( 1 - e ) ￗ i =t +1 ￨ i n For error and erasure situation: RS(n,k) can correct ‘r’ errors and ‘s’ erasures if: 2 ￗr + s < d

Slide 11: Model Conversion 1-p-lamda '0' '0' definitions p lamda E Decoder  δ = Pr {detection} p lamda  Φ = Pr {false alarm} '1' 1-p-lamda '1' Model I  ε = Pr {symbol error before decoding} '0' 1-epsilon '0' epsilon  λ = Pr {erasure} Decoder epsilon '1' '1' 1-epsilon p= ε(1- δ) Erasure =Pr{ error}*Pr{ no-erasure |error} flagger (lamda,phi) λ= εδ+(1-ε) Φ Model II =Pr{error} * Pr {erasure|error} + Pr{ no-error} * Pr{erasure|no-error}

Slide 12: Performance Computation d - 2 r -1 ￦ t n ( e , d , f ) = Pcd ( p, l ) = ￥￥ ￗp r l s ￗ( 1 - p - l ) II I n-r - s Pcd r =0 s =0 ￨ r ,s ￦ n n! = PNCD = 1 - PCD ￨ r ,s r ! s !( n - r - s ) ! p=ε(1- δ) λ= εδ+(1-ε) Φ

Slide 13: Burst and Random errors situation n Pnc = ￥ ( m ) Pm Pnc m =0 P(m) = Pr {burst of m errors}. PNC (m) = Pr{ not-correct given m errors}. The m-errors effectively reduce the code’s minimum distance by 2m, hence: t2 m d - 2 m - 2 r -1 ￦ n Pcd ( m ) = ￥ ￗp l ￗ( 1 - p - l ) n-r -s r =0 ￥ s =0 ￨r ,s r s ￪d - 2 m - 1 t2 m = ￪ ￫ 2

Slide 14: Burst and Random errors situation –cont’ With perfect detection (δ=1) d reduced just by m, hence: tm d - m - 2 r -1 ￦ n Pcd ( m ) = ￥ ￗp r l s ￗ( 1 - p - l ) n-r - s r =0 ￥ s =0 ￨r , s ￪d - m - 1 tm = ￪ 2 ￫ see how We will now We will now see how multicast communication protocols use this advantage. Probability of not correct decoding for error only (blue) and erasure (red) decoding.

Slide 15: Digital Fountain approach Bipartite Bipartite Standard loss-resilient Tornado coding are based on XOR. graph graph code They are a class of LDPC codes introduced in the last lecture. Why Tornado?  Very fast decoding.  Sometimes one received packet can = message cause the decoding of a packet that was needed to decode another = redundancy packet…this creates a whirlwind of decoded packets. Hence the name. LDPC RS Tornado The method :  The file is divided to K packets. Unlike Operation XOR Field Reed-Solomon that can reconstruct the + - file from any K packets, Tornado codes Complexity Very low High needs an epsilon more (about 0.05). + -  After approximately K + packets a Decoding Very fast Relatively receiver would be able to reconstruct time slow + the file. - Length (k/n) K(1+eps) K - +

Slide 16: ECC methods Reed-Solomon on the entire file  Trec is minimal since any k packets from a file of size k are enough to reconstruct the file. However for large Wasted files tdec would be the largest packets Reed-Solomon on Blocks.  In order to decrease tdec the files is divided to blocks and RS-Coding are applied on each block separately. tornado coding on the file (Digital Epsilon packets fountain approach)  tornado coding is done on the entire file Trec is slightly larger than that of RS however tdec is much smaller.

Slide 17: Simulation and results Simulation were done using Speedup factor for Tornado Z backbone multicast traces 250 250KB that were used with 200 500KB proprietary software. 150 1MB 2MB Size RS Coding the entire file. 100 4MB  Advantage – any K packets 50 8MB can be used to reconstruct a 0 16MB file with K packets size. 0.01 0.05 0.1 0.2 0.5  Disadvantage – very long Erasure probabilities decoding time. Reed – Solomon on blocks Comparison chart  Advantage –smaller decoding By forcing the same time then previous option reception time (receiving  disadvantage – needs more and decoding) then k packets to reconstruct a file with this size.

Slide 18: Article analysis  Major hurdle for RS - Decoding time. However, decoding time is considered cheaper than bandwidth (up to a limit). Since computing power is constantly rising (Moor’s law) the differences between tornado and RS would get smaller and smaller. If the tests were made today the results would have been less conclusive.

Slide 19: Future trends More articles for cellular devices multicast where computing power is more scarce and channels are more prone to errors. Creating the basis for layered multicast analysis In this method the sender transmit the information in different layers each with its own multicast address. Each receivers choose the number of layers it will receive according to its bandwidth. This way enables some measure of congestion control like in TCP. This trend is followed by protocols like RMDP and Fine grained layered multicast (by the same authors).

Slide 20: MFTP - Description Multicast File Transfer Protocol. Using hierarchical NACKs to ask for packets that were not received. After finishing the first transmission round the server resends packets that were not received again in rounds till all receivers received the file. MFTP/EC – uses Reed-Muller codes to send the packets that were not received. As you would expect MFTP/EC was proven to be a lot better then MFTP.s.

Slide 21: Simulation and results MFTP and MFTP/EC were simulated using both the NS-2 network simulator & MBone traces. Results were roughly the same. The NS-2 enables simulations of complex network protocols. Including multicast and wireless. NS-2 enables programming of new protocols and behaviors. For example user roaming and C++ power decrease and error increase due to range from bts in wireless simulation. otcl

Slide 22: Simulation and results With the years a multitude of tools were added to the NS simulator, which include (among others): NAM – the network animator, which draws the networks and the passing packets. Tiers, Inet, gt-ITM – for network topology generation. Scenario Generator – for scenario generation. Event ns-2 Scheduler Component Network tclcl otcl tcl8.0

Slide 23: Criticism If the idea of sending FEC is so good then why isn’t it used from the start :  Sending the packets as FEC from the start and save the NACK and overhead The results were compared to regular MFTP so of course there would be an improvement.

Slide 24: References [1] Feasibility Study of Erasure Correction for Multicast File Distribution using (1998) Christoph Hänle [2] RMDP: an FEC-based Reliable Multicast protocol for wireless environmen (1998) Luigi Rizzo Lorenzo Vicisano [3] A Digital Fountain Approach to Reliable Distribution of Bulk Data / John W. Byers, Michael Luby, Michael Mitzenmacher, Ashutosh Rege Proceedings of ACM Sigcomm '98, Vancouver, Canada, September 1998. [4] SomeCast A Paradigm for Real-Time Adaptive Reliable Multicast / Jaehee Yoon, Azer Bestavros, Ibrahim Matta, IEEE Real-Time Technology and Applications Symposium (RTAS) 2000, Washington D.C., Jun. 2000. [5] A Literature Review of Recent Developments in Reliable Multicast Error H . Elf, Stefan; Parnes, Peter 2001