Resilient Packet Header Compression through Coding Vijay Suryavanshi, Aria Nosratinia and Ramakrishna Vedantham Multimedia Communications Laboratory, The University of Texas at Dallas Richardson, TX 75083-0688, USA E-mail: {vas021000, ramky, aria}@utdallas.edu Abstract— Header compression saves bandwidth, but it also introduces error propagation whenever packets are lost. In this work we propose to use error correcting codes on the compressed packet headers. The result is an overall system that maintains most of the bandwidth savings of header compression and yet is robust with respect to errors. The key to achieving this tradeoff is appropriate distribution of parity symbols across the packets. The proposed system performs better than ordinary header compression as well as the TWICE algorithm. In most cases the effects of the error propagation can be almost removed, such that the end-to-end packet loss rate is similar to a system with no header compression, while the bitrate savings are largely maintained. I. I NTRODUCTION Header compression techniques are necessary to reduce the packet overhead, especially when packet size is comparable to the header size. Error propagation in compressed headers is a major nuisance. The loss of a single packet (with compressed header) forces us to discard subsequent packets until the next uncompressed header is received, as shown in Figure 2. We propose to apply forward error correction (FEC) on compressed headers. Our scheme reduces error propagation on links with no feedback. We use Reed-Solomon codes for FEC. They are efficient block codes that provide maximum loss protection for a given redundancy. FEC encoding is not sufficient by itself to protect com- pressed packet headers. We need a packetization scheme that ensures the reception of enough coded symbols. Our scheme reduces the number of discarded packets by (1) protecting the compressed headers with powerful FEC and (2) uniform distribution of parity symbols among the compressed headers. Since we apply FEC on compressed headers only (not pay- load), we only add moderate complexity and little redundancy. The bitrate savings obtained by our method can be used to improve the end-to-end quality of the application. The organization of this paper is as follows. In the rest of this section, we explain the basics of header compression and summarize existing methods to stop error propagation. FEC encoding and distribution among packet headers is discussed in Section II. In Section III, we describe the channel models used in our simulations. Finally in Section IV, we present packet level simulation results and application of our scheme to video streaming. DECOMPRESSOR Channel Header CONTEXT CONTEXT Header COMPRESSOR Fig. 1. Header Compression: Current headers are differentially coded from the previous header stored in the CONTEXT. After compressing each header, the CONTEXT is updated with the most recent header. A. Header Compression Basics Header compression schemes exploit the inter-packet cor- relation among the header fields. At the start of a session the transmitter sends a packet with uncompressed header followed by packets with compressed headers. As shown in Figure 1, a basic header compression configuration involves a com- pressor/decompressor at the transmitter/receiver and context buffers on both sides. One of the first header compression scheme was the Van Jacobson algorithm [1]. Although orig- inally proposed for TCP/IP streams, this algorithm could be applied to RTP/UDP/IP 1 packets as well. RTP/UDP/IP packets are more compressible than TCP/IP packets because header fields in these packets differ by a predictable amount and these differences remain constant over a sequence of compressed packets [2] [3]. Even though very high compression is achieved, the packet discard rate is high due to error propagation. Figure 2 shows the effect of a single packet loss. As shown in Figure 2 even if one compressed packet header is lost, subsequent packets are discarded. On duplex links where feedback is possible, the decompressor can notify the transmitter that a packet has been corrupted and requests retransmission. In case of simplex links the decompressor by no means can notify the transmitter about a packet loss and has to rely on periodic updates in the form of uncompressed header packets. As shown in Figure 2 when a uncompressed header type packet arrives at the decompressor, further decompression of compressed header type packets is error free. In header compression schemes involving TCP/IP header compression [RFC 1144], the decompressor relies on TCP retransmissions when it receives a corrupt packet. In case of 1 RTP- Real-Time Transport Protocol, UDP- User Datagram Protocol Globecom 2004 1635 0-7803-8794-5/04/$20.00 © 2004 IEEE IEEE Communications Society Authorized licensed use limited to: Nokia. Downloaded on May 9, 2009 at 05:12 from IEEE Xplore. Restrictions apply.