FEC Framework Working Group P. Roux Internet Draft C. Janneteau Intended status: Informational M. Kellil Expires: August 12, 2010 CEA LIST February 8, 2010 Benefits of re-packetization for FEC based protection of multimedia streams Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 12, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Roux et al. Expires August 12, 2010 [Page 1] Internet-Draft Benefits of re-packetization February 2010 Abstract This document addresses the subject of FEC-based protection of multimedia streams. It is proposed to apply re-packetization on the application source stream data units in order to get a constant data unit size within each block. A reverse packetization operation should also be applied in the receiver in order to provide the application consumer with original application data units. By avoiding any padding in the process of repair packet production, this proposal brings a significant performance enhancement which is evaluated by simulation. The proposed re-packetization operations can be used without requiring change to the FEC framework. Table of Contents 1. Introduction.................................................2 2. Combining re-packetization with the FEC framework............3 3. Security Considerations......................................6 4. IANA Considerations..........................................6 5. Conclusions..................................................6 6. References...................................................6 6.1. Normative References....................................6 6.2. Informative References..................................6 7. Acknowledgments..............................................6 Appendix A. Simulation results..................................7 1. Introduction The FEC Framework document [1] describes a framework for using FEC codes, in order to provide to applications protection against packet losses. The target applications of this framework also include multimedia applications with real-time constraints. The application data units which are provided to the FEC framework are sent to the receivers through UDP packets called source packets. They are either sent unmodified (e.g. in case of RTP payload), or sent after appending of a "source FEC payload ID" in the UDP payload. In addition to such source packets, repair packets built from source packets can be sent to the receivers as well. Real time applications involve data units of variable size. Therefore, the process of building repair packets typically involves padding to accommodate different lengths of the data units. However, it is possible to re-packetize data units in the sender before submitting them to the FEC framework, by concatenating all Roux et al. Expires August 12, 2010 [Page 2] Internet-Draft Benefits of re-packetization February 2010 data units for one FEC block, and then building a new set of data units of equal size. A protocol header must be appended in the new data units in order to let receivers perform a roll back of this operation at the other end, and to provide the application consumer with original data units. Section 2 in this document details the possible combination of the FEC framework together with re-packetization. The proposed re-packetization provides significant performance improvements which are evaluated in the appendix by means of simulation. Comments are solicited and should be addressed to the working group's mailing list at fecframe@ietf.org and/or the authors. 2. Combining re-packetization with the FEC framework Repair packets are built in the sender once a block of application data units is received from the application. If re-packetization has not been applied, data units in this block are cut into smaller symbols of equal size. Symbols that were at the end of the packet are typically padded in order to reach the pre- assigned size for a symbol. The FEC encoder builds then a set of repair symbols out of the set of source symbols. Finally repair symbols are grouped into repair packets and sent to the receivers. Padding presents the disadvantage of increasing the bit-rate of the repair flow. Different strategies can be used for alleviating the negative effect. We may first consider different extreme strategies: (a) Have small repair symbols and put only one repair symbol per repair packet. (b) Set symbol size equal to the largest application data unit, and put only one repair symbol per repair packet. (c) Have small repair symbols but put many repair symbols per repair packet. Each extreme strategy has its pitfall: Roux et al. Expires August 12, 2010 [Page 3] Internet-Draft Benefits of re-packetization February 2010 (a) will generate high bit-rates with IP+UDP headers attached to each packet. The FEC bandwidth resource will get very large without having benefits in terms of FEC efficiency. (b) will generate a lot of padding in order to align all repair packets to the size of the largest application data unit. Again FEC bandwidth resource will get very large without efficiency benefits. (c) will have poor performances because the loss of a single repair packet will translate into a large number of repair symbol being lost. In practice, the best strategy is somewhere between the extreme ones. But the optimum compromise is still behind what can be achieved if re-packetization is applied. In this latter case, it is assumed that the FEC encoder maps one equalized data unit to one and only one symbol. The appendix attached to this document provides simulation results showing that re-packetization can bring significant performance enhancement. Figure 1 illustrates the architecture combining both re-packetization and the FEC framework. +-------------------------------------------------------------------+ | | | +------+ +-------+ +-----+ +-----+ +-------+ +-------+ | | |Appli.| |re-Pack| |FEC |-> ->|FEC | |Packet | |Appli. | | | |produ-|->|etiza |->|frame| source |frame|->|resto |->|consu- | | | |cer | |tion | |work | packets|work | |ral | |mer | | | +------+ +-------+ | | | | +-------+ +-------+ | | |(Tx) |-> ->|(Rx) | | | | | repair | | | | +-----+ packets+-----+ | | | | Sender Receiver | | | +-------------------------------------------------------------------+ Figure 1: Combining re-packetization with the FEC framework. The re-packetization module is supposed to receive application data units for one block, and then to build a new set of data units of equal sizes. Roux et al. Expires August 12, 2010 [Page 4] Internet-Draft Benefits of re-packetization February 2010 Typically, a block of application data units is made of all data units produced by the application during a specific period of time. Therefore the number of data units per block is typically variable. In case of re-packetization, the number of equalized data units can be set equal to the number of original application data units received for this block. A specific header should be added to the equalized data units in order to allow restoral in the receiver. This header is defined as follows (see figure 2). +-------------------------------+ First byte: |Block index | +-------------------------------+ Second byte: |Data unit index | +-------------------------------+ Third byte: | Size of original application | + data unit that corresponds to + Fourth byte: | the above data unit index | +-------------------------------+ Figure 2: proposed header for re-packetization purpose. It assumes that we have no more than 256 data units per block and that the number of equalized data units is equal to (or possibly larger than) the number of original data units. Note that even though the purpose of the re-packetization is to provide data units of equal size, we may still have a 1-byte difference in the set of equalized packets, because the overall number of bytes for one block may not be a multiple of the number of equalized data units to be produced. Then packets with an index lower or equal to the remainder may have one more byte than the other packets. It has to be noted that the proposed re-packetization and restoral operations have the following drawback. If the FEC decoder is not able to recover one packet in the block, then all subsequent packets in the block will probably get lost at the application consumer because original data units cannot be restored. This negative effect is taken into account in the simulations presented in the appendix. Despite this negative effect, the performance advantage of re- packetization is still significant. Roux et al. Expires August 12, 2010 [Page 5] Internet-Draft Benefits of re-packetization February 2010 3. Security Considerations There are no new security issues introduced by the techniques considered in this document. 4. IANA Considerations There are no requirements for IANA in this document. 5. Conclusions This document and the attached appendix show that it is beneficial to equalize the size of application data units which are provided to the FEC framework in the sender for a given block. This operation involves an additional header to be appended to the equalized data units in order to let receivers restore original data units before forwarding them to the consuming application. 6. References 6.1. Normative References 6.2. Informative References [1] M. Watson, "Forward Error Correction (FEC) Framework", draft- ietf-fecframe-framework-05.txt, work in progress, July 9, 2009. 7. Acknowledgments The work presented in this document has been supported by the European FP7 ICT project C-CAST which aims at evolving mobile multimedia multicasting to exploit the increasing integration of mobile devices with our everyday physical world and environment. The authors would like to thank their colleague Alexandru Petrescu (CEA LIST) for his support in the edition of this document. Roux et al. Expires August 12, 2010 [Page 6] Internet-Draft Benefits of re-packetization February 2010 Appendix A. Simulation results. The purpose of this appendix is to evaluate the benefits of re- packetization in terms of performance. It involves two approaches, namely: - approach 1, with the FEC framework being used without re- packetization, and - approach 2, with FEC framework and repacketization being used jointly. For this purpose, we are going to make common assumptions, and we are going to provide simulation results comparing both approaches under such common assumptions. Assumption 1: source stream. ------------- Use the same real media stream for both approaches. A "real" RTP video stream containing H264 AVC encoded RTP packets, has been recorded for simulation purpose. The average bit-rate of this RTP stream, that does not include the headers of protocols below RTP, is equal to 119.9 kbit/s. Packet sizes (with respect to UDP payload and including RTP header) and packet arrival times were recorded and made available for the simulator. Though the video session had limited duration (around 1 minute) simulated durations could be made arbitrarily long by repeating the same video stream as many times as needed. Assumption 2: block periodicity. ------------- Block periodicity is set equal to 500 ms. It is not mandatory to have a fixed block periodicity. Other criteria can be used for building blocks. Roux et al. Expires August 12, 2010 [Page 7] Internet-Draft Benefits of re-packetization February 2010 However we would like to limit the latency increase brought by the FEC. Fixing a block periodicity equal to 500 ms allows to set a limit to the latency increase. According to this assumption, a block of source packets is made of all RTP packets produced by the sending application during a given 500 ms interval. Assumption 3: bit-rates. ------------- The average bit-rates encompassing both source packets and repair packets must be equal for both approaches. Average bit-rates are considered at IP level and include all overheads brought by IP, UDP, RTP, equalization header (approach 2), repair FEC payload ID (approach 1). No header compression algorithm is considered. Furthermore, because the application data units consist of RTP packets, source packets are sent unmodified in case of approach 1, without the addition of a "source FEC payload ID". The following table provides average bitrates at IP level. +-----------------------------------------------------------+ | Approach 1 Approach 2 | | | |Source bit-rate (kbit/s) 125.63 126.54 | |Total bit-rate (kbit/s) 253.09 (target) 253.09 | +-----------------------------------------------------------+ Because of the additional overhead for re-packetization purpose, the source bit-rate is slightly greater with approach 2 as compared to approach 1. In case of approach 2, the FEC bit-rate is designed in this simulation to be equal to the source bit-rate, so that the total bit- rate provided in the above table is equal to twice the source bit- rate. The same total bit-rate is set as a design target in the case of approach 1. Roux et al. Expires August 12, 2010 [Page 8] Internet-Draft Benefits of re-packetization February 2010 Assumption 4: FEC design. ------------- Maximum Distance Separable (MDS) codes are used. With such codes, if we have k source symbols and n-k repair symbols, it is sufficient to receive k symbols of whichever kind, in order to restore the original k source symbols. The simulation treats the set of source RTP packets received in a 500 ms interval as a FEC block. Let us call N the number of such packets for a given FEC block. Then for this block we have the following number of source symbols and repair symbols: +---------------------------------------------------------------+ | Approach 1 Approach 2 | | | |Number of source packets N N | |Number of source symbols Nss N | |Number of repair symbols Floor(alpha*Nss) N | +---------------------------------------------------------------+ The case of approach 2 is the simplest: each equalized source packet is treated as a source symbol, and for each source symbol, there is a repair symbol of the same size. For approach 1, we have first to assume a given symbol size and a given number of repair symbols per repair packet. Then we have to run the usual process in order to build source symbols out of source packets, where each source packet is first prepended with a 2-byte indication of the source packet size, then cut into several symbols of same size, with the last being padded in order to reach this size. A repair packet is built from the given number of repair symbols per repair packet and includes IP and UDP protocol overheads. It also includes a repair FEC payload ID including information needed for the FEC decoding process and counting 6 bytes. The number of source symbols in the block is called Nss. Then the number of repair symbols is set equal to the integer part of Nss multiplied by a fixed value called 'alpha'. For each possible configuration, a simulation has been done in order to find the value of 'alpha' that satisfies the assumption 3 about bit-rates. We obtain the values reported in figure 3: Roux et al. Expires August 12, 2010 [Page 9] Internet-Draft Benefits of re-packetization February 2010 +--------------------------------------------------------------+ | Symbol | Number of repair symbols per repair packet | | size: | | | | 1 2 5 10 20 | | | | | 16 | 0.336 0.508 0.734 0.862 0.944 | | 32 | 0.502 0.675 0.851 0.932 0.979 | | 64 | 0.661 0.798 0.912 0.958 0.982 | | 128 | 0.766 0.854 0.919 0.941 XXXXX | | 256 | 0.789 0.834 0.867 XXXXX XXXXX | | 512 | 0.723 0.750 XXXXX XXXXX XXXXX | | 1024 | 0.539 XXXXX XXXXX XXXXX XXXXX | +--------------------------------------------------------------+ Figure 3: Alpha values Note that "XXXXX" means "not addressed" in this figure. Assumption 5: Packet losses. ------------- Packet loss occurs randomly according to a given average Packet Loss Ratio (PLR). The same PLR applies both on source packets and on repair packets. Simulations are carried out with 2 different PLR values: 0.1 and 0.2. The simulation outcome is made of the residual PLR. It should be noted that in case of approach 2, the original packet restore operation in the receiver has an amplifying behavior on residual packet losses, in the sense that when a packet can't be restored in the middle of a block, all remaining packets in the block are going to get lost too, because the original source packet restoration is corrupted for all remaining packets, even though those packets may have been received correctly or may have been correctly reconstructed by the FEC decoder. Results ------- For approach 1 and channel PLR=0.1, we obtain the following residual PLRs. Roux et al. Expires August 12, 2010 [Page 10] Internet-Draft Benefits of re-packetization February 2010 +------------------------------------------------------------------+ | Symbol | Number of repair symbol per repair packet | | size: | | | | 1 2 5 10 20 | | | | | 16 | 7.89x10-3 4.85x10-4 4.93x10-6 5.39x10-7 9.87x10-7 | | 32 | 5.26x10-4 1.75x10-5 4.88x10-7 8.86x10-7 1.12x10-5 | | 64 | 2.12x10-5 1.22x10-6 9.09x10-7 1.07x10-5 1.38x10-4 | | 128 | 1.61x10-6 6.91x10-7 1.08x10-5 1.28x10-4 XXXXXXXXX | | 256 | 2.72x10-6 8.53x10-6 1.49x10-4 XXXXXXXXX XXXXXXXXX | | 512 | 1.33x10-5 4.69x10-5 XXXXXXXXX XXXXXXXXX XXXXXXXXX | | 1024 | 3.86x10-4 XXXXXXXXX XXXXXXXXX XXXXXXXXX XXXXXXXXX | +------------------------------------------------------------------+ Figure 4: Residual PLR for approach 1 with channel PLR=0.1. For the same PLR equal to 0.1 but with approach 2, we obtain a residual PLR equal to 5.32x10-8, to be compared with the best PLR in figure 4 (4.88x10-7). For approach 1 and channel PLR=0.2, we obtain the following residual PLRs. +------------------------------------------------------------------+ | Symbol | Number of repaired symbol per repaired packet | | size: | | | | 1 2 5 10 20 | | | | | 16 | 8.85x10-2 2.24x10-2 1.59x10-3 3.86x10-4 3.7x10-4 | | 32 | 2.37x10-2 3.32x10-3 4.24x10-4 3.89x10-4 1.04x10-3 | | 64 | 3.86x10-3 7.13x10-4 4.30x10-4 1.06x10-3 3.32x10-3 | | 128 | 1.03x10-3 5.13x10-4 1.19x10-3 3.47x10-3 XXXXXXXXX | | 256 | 1.08x10-3 1.34x10-3 4.19x10-3 XXXXXXXXX XXXXXXXXX | | 512 | 2.87x10-3 4.12x10-3 XXXXXXXXX XXXXXXXXX XXXXXXXXX | | 1024 | 1.87x10-2 XXXXXXXXX XXXXXXXXX XXXXXXXXX XXXXXXXXX | +------------------------------------------------------------------+ Figure 5: Residual PLR for approach 1 with channel PRL=0.2 For the same PLR equal to 0.2 but with approach 2, we obtain a residual equal to 1.5x10-4, to be compared with the best PLR in figure 5 (3.7x10-4). Roux et al. Expires August 12, 2010 [Page 11] Internet-Draft Benefits of re-packetization February 2010 Authors' Addresses Pierre Roux CEA, LIST, Communicating Systems Laboratory, Point Courrier 94, Gif-sur-Yvette, F-91191 France Email: pierre.roux@cea.fr Christophe Janneteau CEA, LIST, Communicating Systems Laboratory, Point Courrier 94, Gif-sur-Yvette, F-91191 France Email: christophe.janneteau@cea.fr Kellil Mounir CEA, LIST, Communicating Systems Laboratory, Point Courrier 94, Gif-sur-Yvette, F-91191 France Email : kellil.mounir@cea.fr Roux et al. Expires August 12, 2010 [Page 12]