Robust Header Compression Hung V. Tran Internet Draft Erika Schnurr Document: Martin Gallant May 3rd 2000 Expires: November, 2000 Nortel Networks Robust Header Compression using Update Packets Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This contribution describes a new header compression scheme whereby small update packets are sent from the compressor to the decompressor. This scheme maintains the same compressed header size even when the BER (Bit Error Rate) increases. Simulations show that this scheme will approach the ideal header compression scheme. The main advantage of our scheme is that it is logically simple. The compressor has total control of when the small update packets are to be sent. Tran, Schnurr, Gallant Expires November, 2000 1 Header Compression using Update Packets May 3rd, 2000 Table of Contents 1. Abstract 2. Conventions used in this document 3. Introduction 4. Background Discussion 5. Concept of header compression using update packets 6. Proposed Algorithm 7. Suggested formats for Update Packets and Compressed Header Data Packets 8. Examples 9. Performance evaluation of the proposed solution 10. Security considerations 11. References 12. Author's addresses 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction One problem with real-time IP data (such as IP telephony) over cellular links is the associated large header overhead. RTP will most likely carry speech data for IP telephony, as well as other types of real-time IP data. A packet will have, besides link layer framing, an UDP header of 8 bytes, an RTP header of 12 bytes, and an IP header of 20 bytes in IPv4 or 40 bytes in IPv6, which make a total of 40 bytes for IPv4 and 60 bytes for IPv6, while the payload could be from 15 to 20 bytes. Thus, it became necessary to either compress the packet headers (or to `strip' them, as in the case of IP Telephony), to economize bandwidth consumption. This represents a unique challenge to wireless IP, due to its lossy link and bandwidth constraints. Robust header compression is thus an important consideration for real-time applications over lossy links with bandwidth constraints. Exploring this topic led to the development of a new Robust header compression mechanism, as introduced in this paper. The core idea is the use of small update packets, which reduces the amount of discarded packets at the decompressor. Tran, Schnurr, Gallant Expires November, 2000 2 Header Compression using Update Packets May 3rd, 2000 4. Background Discussion The importance of header compression was recognized in RFC 1144 ([7]) for TCP/IP. Not all fields in the TCP/IP header would change unpredictably from header to header. Two consecutive headers have fields that can be updated based on the differences between the data in the header fields. The idea is to send only the differences between two consecutive headers. This is a well-known technique in image processing, where when two pictures are almost identical, then only the differences are recorded and processed. This concept was extended to RFC 2508 ([5]) for the IP/UDP/RTP case. Unfortunately, this scheme breaks down for lossy links as a received erroneous header affects the subsequent headers which information is based on the previously erroneous header. This problem is well-recognized in the industry. This paper presents a header compression mechanism that is more robust against packet loss and hence performs better over unreliable channels. 5. Concept of header compression using update packets: This section describes the concept of header compression using update packets and how this concept leads to better performance, when used over unreliable links. The main idea behind this proposal is to use update packets to periodically update the decompressor with the referenced values of the changing header fields. At the beginning of a given call/session, the compressor sends initialization parameters to the decompressor. These contain all necessary field values pertaining to the session, i.e., field values from the first full (i.e., uncompressed) headers, flow ID (similar to the session context identifier or CID in RFC 2508), update packet options (described below) to be used, etc. As the full header is relatively large (which becomes proportionally larger with high performance error correction coding discussed below) and contains fields that the compressed headers do not need to know to take delta against, the proposed scheme does not use full headers to periodically update these values. Instead, small update packets are used, thus minimizing impact on the effective airlink throughput. The update packets are necessarily small to maintain high throughput and to use high performance error correction coding (such as Turbo code) to approach the theoretical Shannon limit ([11]). The compressor decides when and what update packets are sent. These update packets do not contain any payload, to avoid unnecessary complications. Tran, Schnurr, Gallant Expires November, 2000 3 Header Compression using Update Packets May 3rd, 2000 Throughout the call/session, the compressor sends payload packets with compressed headers to the decompressor. The compressed headers only carry changes (or deltas) in field values first as compared against those sent at initialization, and later to those compressor versions sent in the latest update packets. The compressed headers also carry full values of changing fields that could not be taken deltas against. These headers are therefore quite independent of one another, avoiding the complications resulted from taking deltas against the previous immediately sent packet as in RFC 2508. The decompressor reconstructs the full header for each payload packet initially using the initialization values received from the compressor at the beginning of the session, and later using the changing field values from the update packets, with the field values further incremented (as appropriate) using the field value differences extracted from the compressed headers (see Figure 1). Note that, unlike the scheme in RFC 2508, errors received in one compressed header only affects reconstruction of the corresponding (but not subsequent) full header at the decompressor. The compressor has the total control over when to send the update packets. So if the update packets are sent prior to actual use by the data packets, there should be enough time to send a corrected one in case there is unrecoverable error. This option combined with high performance error correction increases the robustness of the scheme. Tran, Schnurr, Gallant Expires November, 2000 4 Header Compression using Update Packets May 3rd, 2000 In Figure 1 below, after the initial values were set up from the first full headers, Update Packets are periodically sent to update the changing values of the fields, which the compressed headers containing the deltas will reference against. Instead of taking deltas against the immediately previous compressed header, we take deltas against these small packets. +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ | Initial Values | | HC1 | | HC2 | ... | HCn | ... --> +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets | | HC1 | | HC2 | ... | HCn | ... --> +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets | | HC1 | | HC2 | ... | HCn | +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- HCi: The ith Header compressed data packet (with payload), i=1,2, ..., n Figure 1 In Figure 1 above, packets are sent with time axis positively oriented from left to right. The dashed lines show which Compressed Header Data packets (HCs) are taken deltas against which Update packets. Tran, Schnurr, Gallant Expires November, 2000 5 Header Compression using Update Packets May 3rd, 2000 6. Proposed Algorithm: a. At the beginning of Call/Session Setup, the compressor sends all necessary fields values such as IPv4's Version number, Time to Live value, etc. to the decompressor site. We note that the majority of these fields are static. Parameters such as temporary session flow ID, Update packet options (described below) to be used, etc., will also be sent to the decompressor. Please refer to the first part of the Figure 1 above for illustrative purpose. The format for the packet carrying the initialization data is currently left as implementation dependent. b. The implementation must determine which field values should be sent whole and which others should be sent as deltas (RFC2508 can help here) in the compressed headers. These fields might be application dependent. For example, for voice or video, the packet length might not change much, so the compressor only needs to send the differences (deltas) for this value; while for Internet data, packet lengths might fluctuate considerably, so it may be better to send this value whole for this application. c. One byte of data may be designated for a Flow ID (similar to the session context identifier or CID in RFC 2508). For example, one option is to use 1 bit to indicate whether the packet is an update packet or a payload packet with compressed IP/UDP/RTP header, 6 bits for the session flow ID and the last bit for update packet version. Please refer to the section "Suggested formats for Update Packets and Compressed Header Data Packets" below, Figures 2 and 3, for more information. Coordination between an Update Packet and Compressed Header Data Packets, using version number, is described in the "Examples" section described by Figures 8 and 9 below. d. Instead of taking deltas (i.e. computing the field value differences) against the immediately previous compressed header, the decompressor takes deltas against periodically received small update packets which update the stored values for a given session flow ID. This is depicted in Figure 1 above. As an example, if the sequence number RTP field is 2 bytes and we are using 1 byte for differential Sequence Number (which could indicate a Sequence Number difference of up to 255), then a small `update packet' containing the current value (2 bytes) and some identification number can be sent, say for every 200 compressed header packets sent. Similarly, for the time-stamp case of RTP, a small packet with 4 bytes and some identification number could be sent separately after some time has elapsed. Tran, Schnurr, Gallant Expires November, 2000 6 Header Compression using Update Packets May 3rd, 2000 It is also possible to send combinations of these delta fields together in a small updating packet, and this option is implementation dependent. Please refer to the section "Suggested formats for Update Packets and Compressed Header Data Packets" below, Figures 2 to 7, for various options in formating the update packet and the IP/UDP/RTP header compressed payload packet. It is recommended that the update packets should use a high-performance coding algorithm, such as Turbo code, for error correction, to approach the Shannon limit, even in the face of lossy links, so that it can be virtually error-free. The update packets shoud also have version numbers. The number of versions to be supported is implementation dependent. In this draft, we allow for two versions, 0 and 1 to be used cyclically. Please refer to section 7, "Suggested formats for Update Packets and Compressed Header Data Packets" for some explicitly suggested formats. We note that when the compressed header data packets are referencing update packets of a given version, the compressor could start sending update packets of the future version(s). As an example, suppose that the compressed header data packets are currently referencing to a Version 0 update packet which contains the Sequence Number, say 5000. If the compressor decides that the next referenced sequence number should be 5200, then, at any time before the Sequence Number reaches 5200 (assuming that, in the compressed header, the delta field value for the Sequence Number ranges between 0 and 199, referencing to Version 0), the compressor could send update packets of version 1, containing value of 5200. We note that as update packets of different versions are basically independent of each other. This way, update packets of future version(s) could be sent ahead of time (i.e., before the compressed header data packets need to reference them, with two advantages: o There will be no delay for the compressed header data packets to wait for the needed update packets. o Error correction capability for update packets will improve. If x is the probability that an update packet of version y is in error, then by sending 2 update packets of version y at different times (avoiding burst errors), the update packets being statistically independent, the probability that both update packets are in error would be x-squared. For 3 update packets to be in error, the probability would reduce to x-cubed. Combined with the high performance error-correction coding approaching the Shannon limit, it is very likely (approaching probability 1) that the decompressor will receive error-free update packets in time for the compressed header data packets to reference against. This situation is described in the "Examples" section below, with Figure 10. Tran, Schnurr, Gallant Expires November, 2000 7 Header Compression using Update Packets May 3rd, 2000 Since the update packets are very small, they could use high-performance code and duplicate sendings with little impact on the total throughput. We also note the following: 1. Depending on the situation, a buffer might be established to fix intermediate compressed headers. For example, if packets 1 and 3 have good compressed headers, but packet 2 has errors in its compressed header. Assume that the payload for packet 2 is good, and that it is possible to infer, by interpolation, the sequence number, timestamp (for example, if the packet time interval could be inferred from the packet length value), etc., for packet 2, then packet 2 will not have to be dropped, and thus this option might increase the system's throughput. 2. If the payload has unrecoverable errors, the whole packet has to be dropped anyway. So in the case of a good, large payload where only the compressed header has unrecoverable errors (i.e., errors that could not be corrected by the aforesaid interpolation), the packet could then be kept in buffer and the compressor can be notified to send just the compressed header part to substitute for the erroneous compressed header. These small correcting packets will have little impact on the overall throughput in the case of large payload, but will reduce delay and increase throughput since the compressor does not have to resend the entire data packet (compressed header PLUS payload). We notice that this option is possible as neighboring compressed headers are essentially independent of one another, thus we could individually send just the compressed header. Items 1 and 2 above could be used to increase throughput, but should be avoided if excessive delays result from using them, and if delay is important to the application. 3. An erroneous compressed header packet could also simply be dropped, without affecting its neighbors, as is currently done in IP. 4. Simulations showed that the combination of using a high-performance code and sending multiple copies ensures that the decompressor receives virtually error-free update packets. But theoretically, in the rare occasions that even with such high-performance error-correction coding and preemptive, duplicate sending of the update packets, the update packet may still contain unrecoverable errors, Tran, Schnurr, Gallant Expires November, 2000 8 Header Compression using Update Packets May 3rd, 2000 o In the bidirectional case, the decompressor can request the compressor to resend the update packet. Meanwhile, the header compressed data packets could be buffered, with the full headers later regenerated by referencing the error-free update packet finally received, if this does not incur unacceptable delays. When this option cannot be used, as the last resort, the data packets could simply be dropped. But this should be very rare. o In the unidirectional case, the compressor could send a few more duplicates of the update packet (of the same current version), thus increasing the probability for the decompressor to receive an error-free update packet in time for the header compressed data packet to reference against. Tran, Schnurr, Gallant Expires November, 2000 9 Header Compression using Update Packets May 3rd, 2000 7. Suggested formats for Update Packets and Compressed Header Data Packets Following are some suggestions for Packet formats. a. If the applications allow the use of one Update Packet for all required changing fields of the compressed header, a possible format could be set up as follows: . Update Packet format: +---+---+---+---+---+---+---+---+ | 1 | Flow Id | V | +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields + Coding : : : +---+---+---+---+---+---+---+---+ V: Version number, 0 or 1 Figure 2 . Compressed Header Packet format: +---+---+---+---+---+---+---+---+ | 0 | Flow Id | V | +---+---+---+---+---+---+---+---+ : : + Delta Values of Changing + : Fields + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields that cannot be taken : : delta against + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Payload + : : +---+---+---+---+---+---+---+---+ V: Version number, 0 or 1 Figure 3 In Figures 2 and 3 above, the first bit of the first byte is to identify the packets. Here we put 1 for Update Packets, 0 for Compressed Header Packets. The version number is used to identify the correspondence between the Compressed Header Data Packets and the Update Packets. The Flow Id is similar to the session context identifier or CID in RFC 2508. Tran, Schnurr, Gallant Expires November, 2000 10 Header Compression using Update Packets May 3rd, 2000 b. If the applications need different types of Update Packets for various changing fields of the compressed header, different bits in the compressed header could be used to indicate different Update Packet types. This case should be identified at initialization time(set-up time), and it could be implementation dependent. An example of using up to 8 different update packets types is described as follows: . Update Packet format: +---+---+---+---+---+---+---+---+ | 1 | Flow Id | +---+---+---+---+---+---+---+---+ | Type Num | V | +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields + Coding : : : +---+---+---+---+---+---+---+---+ Type Num: Type number, here we have 7 bits, so the number could be from 0 to 127 V : Version number, 0 or 1 Figure 4 . Compressed Header Packet format: +---+---+---+---+---+---+---+---+ | 0 | Flow Id | +---+---+---+---+---+---+---+---+ | P1| P2| P3| P4| P5| P6| P7| P8| +---+---+---+---+---+---+---+---+ : : + Delta Values of Changing + : Fields + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields that cannot be taken : : delta against + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Payload + : : +---+---+---+---+---+---+---+---+ Pi: Version number for Update Packet type i, value 0 or 1 Figure 5 Tran, Schnurr, Gallant Expires November, 2000 11 Header Compression using Update Packets May 3rd, 2000 We note that if we have only two Update Packet types, we could use the last 2 bits of the first byte in the compressed header to indicate the two Update Packet types as shown below. In this case, the Flow Id is only of 5 bits in length. . Update Packet format: +---+---+---+---+---+---+---+---+ | 1 | Flow Id | TN| V | +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields + Coding : : : +---+---+---+---+---+---+---+---+ TN: Type number , 0 or 1 V : Version number, 0 or 1 Figure 6 . Compressed Header Packet format: +---+---+---+---+---+---+---+---+ | 0 | Flow Id | P1| P2| +---+---+---+---+---+---+---+---+ : : + Delta Values of Changing + : Fields + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields that cannot be taken : : delta against + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Payload + : : +---+---+---+---+---+---+---+---+ Pi: Version number for Update Packet type i, value 0 or 1 Figure 7 Tran, Schnurr, Gallant Expires November, 2000 12 Header Compression using Update Packets May 3rd, 2000 8. Examples In Figures 8, 9 and 10, packets are sent with time axis positively oriented from left to right. The dashed lines show which Compressed Header Data Packets (HCs) are taken deltas against which Update packets. 1. A stream of Update Packets and Compressed Header Data Packets (HC packets in Figure 8 below) could be coordinated as follows, where the second number is the version number. +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ | Update Packets,0| |HC1,0| |HC2,0| ... |HCn,0| --> +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets,1| |HC1,1| |HC2,1| ... |HCm,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- Update Packets,j: Update Packets of version j HCi,j : The ith Compressed Header data packet of version j Figure 8 Tran, Schnurr, Gallant Expires November, 2000 13 Header Compression using Update Packets May 3rd, 2000 2. A stream in which an Update Packet was sent "early" is given in Figure 9 below +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ | Update Packets,0| |HC1,0| |HC2,0| ... |HCi,0| | Update Packets,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | ------- | | | | | | | | --------------------- | | | | | | ----------------------------------------- | | | | |--------------------- --------------------- | | |---------- | | ---------------- | | | | | ------- | | | | | +-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> |HC(i+1),0| ... |HCn,0| |HC1,1| |HC2,1| ... |HCm,1| +-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ Update Packets,j: Update Packets of version j HCi,j : The ith Compressed Header data packet of version j Figure 9 In Figure 9 above, Update Packet version 1 was sent "early", between the Compressed Header Data Packets i and i+1 of version 0, before all Compressed Header Data Packets of version 0 were sent. The decompressor can store the Updated Packet version 1 until the first Compressed Header Data Packet of version 1 starts to arrive. 3. A stream in which two Version 1 Update Packets are sent at different times is given in Figure 10 below. The decompressor chooses a correctly received update packet out of these two for the Compressed Header Data Packets of version 1 to use. In Figure 10, we assume that the first Update Packet version 1 had errors (although unlikely due to the high performance error-correction coding used), but the second Update Packet version 1 is good. Tran, Schnurr, Gallant Expires November, 2000 14 Header Compression using Update Packets May 3rd, 2000 +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ | Update Packets,0| |HC1,0| |HC2,0| ... |HCi,0| | Update Packets,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | --------- | | | | | ----------------------- | | | ----------------------------------------- | |----------------------- |---------- | | | | | +-+-+-+-+-+ +-+-+-+ --> |HC(i+1),0| ... |HCn,0| --> +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets,1| |HC1,1| |HC2,1| ... |HCm,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- Update Packets,j: Update Packets of version j HCi,j : The ith Compressed Header data packet of version j Figure 10 In Figure 10 above, Update Packet version 1 was sent "early", between the Compressed Header Data Packets i and i+1 of version 0, before all Compressed Header Data Packets of version 0 were sent. A second Update Packet version 1 is then sent at later time. Certain time interval between these two Update Packets would perhaps lessen the probability of being in the same burst errors. The decompressor can store a correct Updated Packet version 1 until the first Compressed Header Data Packet of version 1 starts to arrive. Tran, Schnurr, Gallant Expires November, 2000 15 Header Compression using Update Packets May 3rd, 2000 9. Performance evaluation of the proposed solution In [6], it was described that a voice packet has an average of 20ms in length, with round-trip delays 80-195 ms. Thus, a packet being lost due to errors on the lossy links would cause at least 4 more packets after it to be lost also, according to the Casner-Van Jacobson's scheme (RFC 2508). Using the above information, and noting that a changing Sequence field of one byte in length in the compressed header can carry a delta of up to 255 sequences, the compressor would have more than sufficient time to send an update packet for every 128 (half of 256) header compressed data packets it sends to the decompressor, that later compressed headers would be taking deltas against. We also assume that the changing Time-stamp field is 2 bytes in length in unit of tenth of a milli-second, which can carry a delta of up to 6.55 seconds. So half of this value (for plenty of time for the compressor to send an update packet) is about 3.2 seconds, and assuming 50 packets per second, the total number is about 150 packets. We take the minimum between 128 packets of the Sequence field, and 150 packets of the timestamp field, which is 128. Thus the compressor could send an update packet containing these two header fields for every 128 header compressed data packets it sends to the decompressor. This is in accord with step d in the Proposed Algorithm discussed previously. We compared our scheme against Casner-Van Jacobson's RFC 2508 (CRTP) and the ideal Header Compression (the case in which we assume that errors affect only the compressed header and the payload). Simulations were run over a 100-seconds time interval at each BER value. The average packet length is taken arbitrarily to be 40 bytes. We simulated both cases of random single bit errors as well as when errors occur in bursts. We noticed that our scheme compares well against the ideal Header Compression case, and it usually out-performs the original Casner-Van Jacobson CRTP scheme, especially when the links are lossy (high BER). We assumed a compressed header of 5 bytes in both cases. Tran, Schnurr, Gallant Expires November, 2000 14 Header Compression using Update Packets May 3rd, 2000 Our scheme satisfies most of ROHC requirements as stated in [8]: a. Impact on Internet infrastructure: 1. Transparency: When a header is compressed and then decompressed, the resulting header is semantically identical to the original header. This was verified in simple simulations. 2. Ubiquity: Does not require modifications to existing IP (v4 or v6), UDP, or RTP implementations. b. Supports headers and kinds of RTP streams 1. IPv4 and IPv6: Supports both IPv4 and IPv6. 2. Mobile IP: We did not verify by simulations that the kinds of headers used by Mobile IP{v4,v6} were compressed efficiently. This item is for further study. c. Efficiency 1. Performance/Spectral Efficiency: Provides low relative overhead due to the use of small update packets; compression efficiency is better than for RFC2508 under equivalent error conditions, as demonstrated by simulation results. 2. Error propagation: Error propagation due to header compression is kept at an absolute minimum. The Compressed Header data packets are independent of each other, so errors from one Compressed Header data packet does not affect the neighboring data packets. 3. Cellular handover: Not yet verified under simulations, but we do not expect our header compression scheme to cause packet loss after handover. This item is for further study. 4. Link delay: We did not verify that our header compression scheme operates under all expected link delay conditions. This item is for further study. 5. Processing delay: Our scheme does not contribute significantly to system delay budget. Erroneous Compressed Header data packets could be simply dropped, as is currently done in IP, without incurring additional buffering or queueing delay. Tran, Schnurr, Gallant Expires November, 2000 17 Header Compression using Update Packets May 3rd, 2000 6. Multiple links: We did not verify that our header compression scheme performs well when there are two or more cellular links in the end-to-end path. This item is for further study. 7. Packet Misordering: Our scheme tolerates misordering in the packet stream reaching the decompressor, as the Compressed Header data packets are independent of each other, so misordering of one Compressed Header data packet does not affect the neighboring data packets. 8. Unidirectional links/multicast: We did not verify that our header compression scheme operates well over links where there is no feedback channel or where there are several receivers. This item is for further study. 9. Configurable header size fluctuation: Our scheme's header sizes are following those of RFC 2508. 10. Security Considerations Security issues are not considered in this contribution. Tran, Schnurr, Gallant Expires November, 2000 18 Header Compression using Update Packets May 3rd, 2000 11. References 1. The Internet Standards Process -- Revision 3, Bradner, S., BCP 9, RFC 2026, October 1996. 2. Key words for use in RFCs to Indicate Requirement Levels, Bradner, S., BCP 14, RFC 2119, March 1997. 3. Robust Checksum-based header Compression (ROCCO), Internet draft, Johnson, Degermark, Hannu, Svanbro, Oct 1999. 4. IP Header Compression, Degermark, Nordgren, Pink, RFC 2507, Jan 1999. 5. Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, Casner, Van Jacobson, RFC 2508, Feb 1999. 6. Requirements for IP/UDP/RTP Header Compression, Nokia, ETSI SMG2 Working Session on EDGE #12, Amsterdam, The Netherlands, 13-16 December 1999. 7. Compressing TCP/IP Headers for Low-Speed Serial Links, Van Jacobson, RFC 1144, Feb 1990. 8. Requirements for IP/UDP/RTP header compression, Internet draft, , Mikael Degermark, March 29, 2000. 9. Near Shannon limit error-correcting coding and decoding: Turbo-codes, Berrou, C., Glavieux, A., Thitimajshima, P., ICC '93 Geneva. Technical Program, Conference Record, IEEE International Conference on Communications, 1993, Volume: 2 , 1993 , Page(s): 1064 -1070. 10. Near optimum error correcting coding and decoding: turbo-codes, Berrou, C., Glavieux, A., IEEE Transactions on Communications, Volume: 44 10 , Oct. 1996 , Page(s): 1261 -1271 11. Information Theory and Reliable Communication, Robert G. Gallager, John Wiley & Sons, 1968 Tran, Schnurr, Gallant Expires November, 2000 19 Header Compression using Update Packets May 3rd, 2000 12. Author's Addresses Hung V. Tran Nortel Networks Richardson, Texas, USA Tel. (972) 685-4080 Fax. (972) 6840619 Mail hvtran@nortelnetworks.com Erika Schnurr Nortel Networks Richardson, Texas, USA Tel. (972) 684-8654 Fax. (972) 6840619 Mail ecarlson@nortelnetworks.com Martin Gallant Nortel Networks Richardson, Texas, USA Tel. (972) 684-5532 Fax. (972) 6840619 Mail martyg@nortelnetworks.com Tran, Schnurr, Gallant Expires November, 2000 20 Header Compression using Update Packets May 3rd, 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Tran, Schnurr, Gallant Expires November, 2000 21 Robust Header Compression Hung V. Tran Internet Draft Erika Schnurr Document: Martin Gallant May 3rd 2000 Expires: November, 2000 Nortel Networks Robust Header Compression using Update Packets Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. 1. Abstract This contribution describes a new header compression scheme whereby small update packets are sent from the compressor to the decompressor. This scheme maintains the same compressed header size even when the BER (Bit Error Rate) increases. Simulations show that this scheme will approach the ideal header compression scheme. The main advantage of our scheme is that it is logically simple. The compressor has total control of when the small update packets are to be sent. Tran, Schnurr, Gallant Expires November, 2000 1 Header Compression using Update Packets May 3rd, 2000 Table of Contents 1. Abstract 2. Conventions used in this document 3. Introduction 4. Background Discussion 5. Concept of header compression using update packets 6. Proposed Algorithm 7. Suggested formats for Update Packets and Compressed Header Data Packets 8. Examples 9. Performance evaluation of the proposed solution 10. Security considerations 11. References 12. Author's addresses 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. Introduction One problem with real-time IP data (such as IP telephony) over cellular links is the associated large header overhead. RTP will most likely carry speech data for IP telephony, as well as other types of real-time IP data. A packet will have, besides link layer framing, an UDP header of 8 bytes, an RTP header of 12 bytes, and an IP header of 20 bytes in IPv4 or 40 bytes in IPv6, which make a total of 40 bytes for IPv4 and 60 bytes for IPv6, while the payload could be from 15 to 20 bytes. Thus, it became necessary to either compress the packet headers (or to `strip' them, as in the case of IP Telephony), to economize bandwidth consumption. This represents a unique challenge to wireless IP, due to its lossy link and bandwidth constraints. Robust header compression is thus an important consideration for real-time applications over lossy links with bandwidth constraints. Exploring this topic led to the development of a new Robust header compression mechanism, as introduced in this paper. The core idea is the use of small update packets, which reduces the amount of discarded packets at the decompressor. Tran, Schnurr, Gallant Expires November, 2000 2 Header Compression using Update Packets May 3rd, 2000 4. Background Discussion The importance of header compression was recognized in RFC 1144 ([7]) for TCP/IP. Not all fields in the TCP/IP header would change unpredictably from header to header. Two consecutive headers have fields that can be updated based on the differences between the data in the header fields. The idea is to send only the differences between two consecutive headers. This is a well-known technique in image processing, where when two pictures are almost identical, then only the differences are recorded and processed. This concept was extended to RFC 2508 ([5]) for the IP/UDP/RTP case. Unfortunately, this scheme breaks down for lossy links as a received erroneous header affects the subsequent headers which information is based on the previously erroneous header. This problem is well-recognized in the industry. This paper presents a header compression mechanism that is more robust against packet loss and hence performs better over unreliable channels. 5. Concept of header compression using update packets: This section describes the concept of header compression using update packets and how this concept leads to better performance, when used over unreliable links. The main idea behind this proposal is to use update packets to periodically update the decompressor with the referenced values of the changing header fields. At the beginning of a given call/session, the compressor sends initialization parameters to the decompressor. These contain all necessary field values pertaining to the session, i.e., field values from the first full (i.e., uncompressed) headers, flow ID (similar to the session context identifier or CID in RFC 2508), update packet options (described below) to be used, etc. As the full header is relatively large (which becomes proportionally larger with high performance error correction coding discussed below) and contains fields that the compressed headers do not need to know to take delta against, the proposed scheme does not use full headers to periodically update these values. Instead, small update packets are used, thus minimizing impact on the effective airlink throughput. The update packets are necessarily small to maintain high throughput and to use high performance error correction coding (such as Turbo code) to approach the theoretical Shannon limit ([11]). The compressor decides when and what update packets are sent. These update packets do not contain any payload, to avoid unnecessary complications. Tran, Schnurr, Gallant Expires November, 2000 3 Header Compression using Update Packets May 3rd, 2000 Throughout the call/session, the compressor sends payload packets with compressed headers to the decompressor. The compressed headers only carry changes (or deltas) in field values first as compared against those sent at initialization, and later to those compressor versions sent in the latest update packets. The compressed headers also carry full values of changing fields that could not be taken deltas against. These headers are therefore quite independent of one another, avoiding the complications resulted from taking deltas against the previous immediately sent packet as in RFC 2508. The decompressor reconstructs the full header for each payload packet initially using the initialization values received from the compressor at the beginning of the session, and later using the changing field values from the update packets, with the field values further incremented (as appropriate) using the field value differences extracted from the compressed headers (see Figure 1). Note that, unlike the scheme in RFC 2508, errors received in one compressed header only affects reconstruction of the corresponding (but not subsequent) full header at the decompressor. The compressor has the total control over when to send the update packets. So if the update packets are sent prior to actual use by the data packets, there should be enough time to send a corrected one in case there is unrecoverable error. This option combined with high performance error correction increases the robustness of the scheme. Tran, Schnurr, Gallant Expires November, 2000 4 Header Compression using Update Packets May 3rd, 2000 In Figure 1 below, after the initial values were set up from the first full headers, Update Packets are periodically sent to update the changing values of the fields, which the compressed headers containing the deltas will reference against. Instead of taking deltas against the immediately previous compressed header, we take deltas against these small packets. +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ | Initial Values | | HC1 | | HC2 | ... | HCn | ... --> +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets | | HC1 | | HC2 | ... | HCn | ... --> +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets | | HC1 | | HC2 | ... | HCn | +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- HCi: The ith Header compressed data packet (with payload), i=1,2, ..., n Figure 1 In Figure 1 above, packets are sent with time axis positively oriented from left to right. The dashed lines show which Compressed Header Data packets (HCs) are taken deltas against which Update packets. Tran, Schnurr, Gallant Expires November, 2000 5 Header Compression using Update Packets May 3rd, 2000 6. Proposed Algorithm: a. At the beginning of Call/Session Setup, the compressor sends all necessary fields values such as IPv4's Version number, Time to Live value, etc. to the decompressor site. We note that the majority of these fields are static. Parameters such as temporary session flow ID, Update packet options (described below) to be used, etc., will also be sent to the decompressor. Please refer to the first part of the Figure 1 above for illustrative purpose. The format for the packet carrying the initialization data is currently left as implementation dependent. b. The implementation must determine which field values should be sent whole and which others should be sent as deltas (RFC2508 can help here) in the compressed headers. These fields might be application dependent. For example, for voice or video, the packet length might not change much, so the compressor only needs to send the differences (deltas) for this value; while for Internet data, packet lengths might fluctuate considerably, so it may be better to send this value whole for this application. c. One byte of data may be designated for a Flow ID (similar to the session context identifier or CID in RFC 2508). For example, one option is to use 1 bit to indicate whether the packet is an update packet or a payload packet with compressed IP/UDP/RTP header, 6 bits for the session flow ID and the last bit for update packet version. Please refer to the section "Suggested formats for Update Packets and Compressed Header Data Packets" below, Figures 2 and 3, for more information. Coordination between an Update Packet and Compressed Header Data Packets, using version number, is described in the "Examples" section described by Figures 8 and 9 below. d. Instead of taking deltas (i.e. computing the field value differences) against the immediately previous compressed header, the decompressor takes deltas against periodically received small update packets which update the stored values for a given session flow ID. This is depicted in Figure 1 above. As an example, if the sequence number RTP field is 2 bytes and we are using 1 byte for differential Sequence Number (which could indicate a Sequence Number difference of up to 255), then a small `update packet' containing the current value (2 bytes) and some identification number can be sent, say for every 200 compressed header packets sent. Similarly, for the time-stamp case of RTP, a small packet with 4 bytes and some identification number could be sent separately after some time has elapsed. Tran, Schnurr, Gallant Expires November, 2000 6 Header Compression using Update Packets May 3rd, 2000 It is also possible to send combinations of these delta fields together in a small updating packet, and this option is implementation dependent. Please refer to the section "Suggested formats for Update Packets and Compressed Header Data Packets" below, Figures 2 to 7, for various options in formating the update packet and the IP/UDP/RTP header compressed payload packet. It is recommended that the update packets should use a high-performance coding algorithm, such as Turbo code, for error correction, to approach the Shannon limit, even in the face of lossy links, so that it can be virtually error-free. The update packets shoud also have version numbers. The number of versions to be supported is implementation dependent. In this draft, we allow for two versions, 0 and 1 to be used cyclically. Please refer to section 7, "Suggested formats for Update Packets and Compressed Header Data Packets" for some explicitly suggested formats. We note that when the compressed header data packets are referencing update packets of a given version, the compressor could start sending update packets of the future version(s). As an example, suppose that the compressed header data packets are currently referencing to a Version 0 update packet which contains the Sequence Number, say 5000. If the compressor decides that the next referenced sequence number should be 5200, then, at any time before the Sequence Number reaches 5200 (assuming that, in the compressed header, the delta field value for the Sequence Number ranges between 0 and 199, referencing to Version 0), the compressor could send update packets of version 1, containing value of 5200. We note that as update packets of different versions are basically independent of each other. This way, update packets of future version(s) could be sent ahead of time (i.e., before the compressed header data packets need to reference them, with two advantages: o There will be no delay for the compressed header data packets to wait for the needed update packets. o Error correction capability for update packets will improve. If x is the probability that an update packet of version y is in error, then by sending 2 update packets of version y at different times (avoiding burst errors), the update packets being statistically independent, the probability that both update packets are in error would be x-squared. For 3 update packets to be in error, the probability would reduce to x-cubed. Combined with the high performance error-correction coding approaching the Shannon limit, it is very likely (approaching probability 1) that the decompressor will receive error-free update packets in time for the compressed header data packets to reference against. This situation is described in the "Examples" section below, with Figure 10. Tran, Schnurr, Gallant Expires November, 2000 7 Header Compression using Update Packets May 3rd, 2000 Since the update packets are very small, they could use high-performance code and duplicate sendings with little impact on the total throughput. We also note the following: 1. Depending on the situation, a buffer might be established to fix intermediate compressed headers. For example, if packets 1 and 3 have good compressed headers, but packet 2 has errors in its compressed header. Assume that the payload for packet 2 is good, and that it is possible to infer, by interpolation, the sequence number, timestamp (for example, if the packet time interval could be inferred from the packet length value), etc., for packet 2, then packet 2 will not have to be dropped, and thus this option might increase the system's throughput. 2. If the payload has unrecoverable errors, the whole packet has to be dropped anyway. So in the case of a good, large payload where only the compressed header has unrecoverable errors (i.e., errors that could not be corrected by the aforesaid interpolation), the packet could then be kept in buffer and the compressor can be notified to send just the compressed header part to substitute for the erroneous compressed header. These small correcting packets will have little impact on the overall throughput in the case of large payload, but will reduce delay and increase throughput since the compressor does not have to resend the entire data packet (compressed header PLUS payload). We notice that this option is possible as neighboring compressed headers are essentially independent of one another, thus we could individually send just the compressed header. Items 1 and 2 above could be used to increase throughput, but should be avoided if excessive delays result from using them, and if delay is important to the application. 3. An erroneous compressed header packet could also simply be dropped, without affecting its neighbors, as is currently done in IP. 4. Simulations showed that the combination of using a high-performance code and sending multiple copies ensures that the decompressor receives virtually error-free update packets. But theoretically, in the rare occasions that even with such high-performance error-correction coding and preemptive, duplicate sending of the update packets, the update packet may still contain unrecoverable errors, Tran, Schnurr, Gallant Expires November, 2000 8 Header Compression using Update Packets May 3rd, 2000 o In the bidirectional case, the decompressor can request the compressor to resend the update packet. Meanwhile, the header compressed data packets could be buffered, with the full headers later regenerated by referencing the error-free update packet finally received, if this does not incur unacceptable delays. When this option cannot be used, as the last resort, the data packets could simply be dropped. But this should be very rare. o In the unidirectional case, the compressor could send a few more duplicates of the update packet (of the same current version), thus increasing the probability for the decompressor to receive an error-free update packet in time for the header compressed data packet to reference against. Tran, Schnurr, Gallant Expires November, 2000 9 Header Compression using Update Packets May 3rd, 2000 7. Suggested formats for Update Packets and Compressed Header Data Packets Following are some suggestions for Packet formats. a. If the applications allow the use of one Update Packet for all required changing fields of the compressed header, a possible format could be set up as follows: . Update Packet format: +---+---+---+---+---+---+---+---+ | 1 | Flow Id | V | +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields + Coding : : : +---+---+---+---+---+---+---+---+ V: Version number, 0 or 1 Figure 2 . Compressed Header Packet format: +---+---+---+---+---+---+---+---+ | 0 | Flow Id | V | +---+---+---+---+---+---+---+---+ : : + Delta Values of Changing + : Fields + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields that cannot be taken : : delta against + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Payload + : : +---+---+---+---+---+---+---+---+ V: Version number, 0 or 1 Figure 3 In Figures 2 and 3 above, the first bit of the first byte is to identify the packets. Here we put 1 for Update Packets, 0 for Compressed Header Packets. The version number is used to identify the correspondence between the Compressed Header Data Packets and the Update Packets. The Flow Id is similar to the session context identifier or CID in RFC 2508. Tran, Schnurr, Gallant Expires November, 2000 10 Header Compression using Update Packets May 3rd, 2000 b. If the applications need different types of Update Packets for various changing fields of the compressed header, different bits in the compressed header could be used to indicate different Update Packet types. This case should be identified at initialization time(set-up time), and it could be implementation dependent. An example of using up to 8 different update packets types is described as follows: . Update Packet format: +---+---+---+---+---+---+---+---+ | 1 | Flow Id | +---+---+---+---+---+---+---+---+ | Type Num | V | +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields + Coding : : : +---+---+---+---+---+---+---+---+ Type Num: Type number, here we have 7 bits, so the number could be from 0 to 127 V : Version number, 0 or 1 Figure 4 . Compressed Header Packet format: +---+---+---+---+---+---+---+---+ | 0 | Flow Id | +---+---+---+---+---+---+---+---+ | P1| P2| P3| P4| P5| P6| P7| P8| +---+---+---+---+---+---+---+---+ : : + Delta Values of Changing + : Fields + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields that cannot be taken : : delta against + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Payload + : : +---+---+---+---+---+---+---+---+ Pi: Version number for Update Packet type i, value 0 or 1 Figure 5 Tran, Schnurr, Gallant Expires November, 2000 11 Header Compression using Update Packets May 3rd, 2000 We note that if we have only two Update Packet types, we could use the last 2 bits of the first byte in the compressed header to indicate the two Update Packet types as shown below. In this case, the Flow Id is only of 5 bits in length. . Update Packet format: +---+---+---+---+---+---+---+---+ | 1 | Flow Id | TN| V | +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields + Coding : : : +---+---+---+---+---+---+---+---+ TN: Type number , 0 or 1 V : Version number, 0 or 1 Figure 6 . Compressed Header Packet format: +---+---+---+---+---+---+---+---+ | 0 | Flow Id | P1| P2| +---+---+---+---+---+---+---+---+ : : + Delta Values of Changing + : Fields + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Full Values of Changing + : Fields that cannot be taken : : delta against + Check sum/CRC : : : +---+---+---+---+---+---+---+---+ : : + Payload + : : +---+---+---+---+---+---+---+---+ Pi: Version number for Update Packet type i, value 0 or 1 Figure 7 Tran, Schnurr, Gallant Expires November, 2000 12 Header Compression using Update Packets May 3rd, 2000 8. Examples In Figures 8, 9 and 10, packets are sent with time axis positively oriented from left to right. The dashed lines show which Compressed Header Data Packets (HCs) are taken deltas against which Update packets. 1. A stream of Update Packets and Compressed Header Data Packets (HC packets in Figure 8 below) could be coordinated as follows, where the second number is the version number. +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ | Update Packets,0| |HC1,0| |HC2,0| ... |HCn,0| --> +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets,1| |HC1,1| |HC2,1| ... |HCm,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- Update Packets,j: Update Packets of version j HCi,j : The ith Compressed Header data packet of version j Figure 8 Tran, Schnurr, Gallant Expires November, 2000 13 Header Compression using Update Packets May 3rd, 2000 2. A stream in which an Update Packet was sent "early" is given in Figure 9 below +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ | Update Packets,0| |HC1,0| |HC2,0| ... |HCi,0| | Update Packets,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | ------- | | | | | | | | --------------------- | | | | | | ----------------------------------------- | | | | |--------------------- --------------------- | | |---------- | | ---------------- | | | | | ------- | | | | | +-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> |HC(i+1),0| ... |HCn,0| |HC1,1| |HC2,1| ... |HCm,1| +-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ Update Packets,j: Update Packets of version j HCi,j : The ith Compressed Header data packet of version j Figure 9 In Figure 9 above, Update Packet version 1 was sent "early", between the Compressed Header Data Packets i and i+1 of version 0, before all Compressed Header Data Packets of version 0 were sent. The decompressor can store the Updated Packet version 1 until the first Compressed Header Data Packet of version 1 starts to arrive. 3. A stream in which two Version 1 Update Packets are sent at different times is given in Figure 10 below. The decompressor chooses a correctly received update packet out of these two for the Compressed Header Data Packets of version 1 to use. In Figure 10, we assume that the first Update Packet version 1 had errors (although unlikely due to the high performance error-correction coding used), but the second Update Packet version 1 is good. Tran, Schnurr, Gallant Expires November, 2000 14 Header Compression using Update Packets May 3rd, 2000 +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ | Update Packets,0| |HC1,0| |HC2,0| ... |HCi,0| | Update Packets,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ ^ ^ ^ ^ ^ ^ ^ ^ | | | | | | | | | | | | --------- | | | | | ----------------------- | | | ----------------------------------------- | |----------------------- |---------- | | | | | +-+-+-+-+-+ +-+-+-+ --> |HC(i+1),0| ... |HCn,0| --> +-+-+-+-+-+ +-+-+-+ +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ --> | Update Packets,1| |HC1,1| |HC2,1| ... |HCm,1| +-+-+-+-+-+-+-+-+-+ +-+-+-+ +-+-+-+ +-+-+-+ ^ ^ ^ ^ ^ ^ | | | | | | | | ------------- | | | ----------------------------- | ------------------------------------------------- Update Packets,j: Update Packets of version j HCi,j : The ith Compressed Header data packet of version j Figure 10 In Figure 10 above, Update Packet version 1 was sent "early", between the Compressed Header Data Packets i and i+1 of version 0, before all Compressed Header Data Packets of version 0 were sent. A second Update Packet version 1 is then sent at later time. Certain time interval between these two Update Packets would perhaps lessen the probability of being in the same burst errors. The decompressor can store a correct Updated Packet version 1 until the first Compressed Header Data Packet of version 1 starts to arrive. Tran, Schnurr, Gallant Expires November, 2000 15 Header Compression using Update Packets May 3rd, 2000 9. Performance evaluation of the proposed solution In [6], it was described that a voice packet has an average of 20ms in length, with round-trip delays 80-195 ms. Thus, a packet being lost due to errors on the lossy links would cause at least 4 more packets after it to be lost also, according to the Casner-Van Jacobson's scheme (RFC 2508). Using the above information, and noting that a changing Sequence field of one byte in length in the compressed header can carry a delta of up to 255 sequences, the compressor would have more than sufficient time to send an update packet for every 128 (half of 256) header compressed data packets it sends to the decompressor, that later compressed headers would be taking deltas against. We also assume that the changing Time-stamp field is 2 bytes in length in unit of tenth of a milli-second, which can carry a delta of up to 6.55 seconds. So half of this value (for plenty of time for the compressor to send an update packet) is about 3.2 seconds, and assuming 50 packets per second, the total number is about 150 packets. We take the minimum between 128 packets of the Sequence field, and 150 packets of the timestamp field, which is 128. Thus the compressor could send an update packet containing these two header fields for every 128 header compressed data packets it sends to the decompressor. This is in accord with step d in the Proposed Algorithm discussed previously. We compared our scheme against Casner-Van Jacobson's RFC 2508 (CRTP) and the ideal Header Compression (the case in which we assume that errors affect only the compressed header and the payload). Simulations were run over a 100-seconds time interval at each BER value. The average packet length is taken arbitrarily to be 40 bytes. We simulated both cases of random single bit errors as well as when errors occur in bursts. We noticed that our scheme compares well against the ideal Header Compression case, and it usually out-performs the original Casner-Van Jacobson CRTP scheme, especially when the links are lossy (high BER). We assumed a compressed header of 5 bytes in both cases. Tran, Schnurr, Gallant Expires November, 2000 14 Header Compression using Update Packets May 3rd, 2000 Our scheme satisfies most of ROHC requirements as stated in [8]: a. Impact on Internet infrastructure: 1. Transparency: When a header is compressed and then decompressed, the resulting header is semantically identical to the original header. This was verified in simple simulations. 2. Ubiquity: Does not require modifications to existing IP (v4 or v6), UDP, or RTP implementations. b. Supports headers and kinds of RTP streams 1. IPv4 and IPv6: Supports both IPv4 and IPv6. 2. Mobile IP: We did not verify by simulations that the kinds of headers used by Mobile IP{v4,v6} were compressed efficiently. This item is for further study. c. Efficiency 1. Performance/Spectral Efficiency: Provides low relative overhead due to the use of small update packets; compression efficiency is better than for RFC2508 under equivalent error conditions, as demonstrated by simulation results. 2. Error propagation: Error propagation due to header compression is kept at an absolute minimum. The Compressed Header data packets are independent of each other, so errors from one Compressed Header data packet does not affect the neighboring data packets. 3. Cellular handover: Not yet verified under simulations, but we do not expect our header compression scheme to cause packet loss after handover. This item is for further study. 4. Link delay: We did not verify that our header compression scheme operates under all expected link delay conditions. This item is for further study. 5. Processing delay: Our scheme does not contribute significantly to system delay budget. Erroneous Compressed Header data packets could be simply dropped, as is currently done in IP, without incurring additional buffering or queueing delay. Tran, Schnurr, Gallant Expires November, 2000 17 Header Compression using Update Packets May 3rd, 2000 6. Multiple links: We did not verify that our header compression scheme performs well when there are two or more cellular links in the end-to-end path. This item is for further study. 7. Packet Misordering: Our scheme tolerates misordering in the packet stream reaching the decompressor, as the Compressed Header data packets are independent of each other, so misordering of one Compressed Header data packet does not affect the neighboring data packets. 8. Unidirectional links/multicast: We did not verify that our header compression scheme operates well over links where there is no feedback channel or where there are several receivers. This item is for further study. 9. Configurable header size fluctuation: Our scheme's header sizes are following those of RFC 2508. 10. Security Considerations Security issues are not considered in this contribution. Tran, Schnurr, Gallant Expires November, 2000 18 Header Compression using Update Packets May 3rd, 2000 11. References 1. The Internet Standards Process -- Revision 3, Bradner, S., BCP 9, RFC 2026, October 1996. 2. Key words for use in RFCs to Indicate Requirement Levels, Bradner, S., BCP 14, RFC 2119, March 1997. 3. Robust Checksum-based header Compression (ROCCO), Internet draft, Johnson, Degermark, Hannu, Svanbro, Oct 1999. 4. IP Header Compression, Degermark, Nordgren, Pink, RFC 2507, Jan 1999. 5. Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, Casner, Van Jacobson, RFC 2508, Feb 1999. 6. Requirements for IP/UDP/RTP Header Compression, Nokia, ETSI SMG2 Working Session on EDGE #12, Amsterdam, The Netherlands, 13-16 December 1999. 7. Compressing TCP/IP Headers for Low-Speed Serial Links, Van Jacobson, RFC 1144, Feb 1990. 8. Requirements for IP/UDP/RTP header compression, Internet draft, , Mikael Degermark, March 29, 2000. 9. Near Shannon limit error-correcting coding and decoding: Turbo-codes, Berrou, C., Glavieux, A., Thitimajshima, P., ICC '93 Geneva. Technical Program, Conference Record, IEEE International Conference on Communications, 1993, Volume: 2 , 1993 , Page(s): 1064 -1070. 10. Near optimum error correcting coding and decoding: turbo-codes, Berrou, C., Glavieux, A., IEEE Transactions on Communications, Volume: 44 10 , Oct. 1996 , Page(s): 1261 -1271 11. Information Theory and Reliable Communication, Robert G. Gallager, John Wiley & Sons, 1968 Tran, Schnurr, Gallant Expires November, 2000 19 Header Compression using Update Packets May 3rd, 2000 12. Author's Addresses Hung V. Tran Nortel Networks Richardson, Texas, USA Tel. (972) 685-4080 Fax. (972) 6840619 Mail hvtran@nortelnetworks.com Erika Schnurr Nortel Networks Richardson, Texas, USA Tel. (972) 684-8654 Fax. (972) 6840619 Mail ecarlson@nortelnetworks.com Martin Gallant Nortel Networks Richardson, Texas, USA Tel. (972) 684-5532 Fax. (972) 6840619 Mail martyg@nortelnetworks.com Tran, Schnurr, Gallant Expires November, 2000 20 Header Compression using Update Packets May 3rd, 2000 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Tran, Schnurr, Gallant Expires November, 2000 21