INTERNET-DRAFT Rohit Kapoor, Qualcomm Expires: September 2005 Haipeng Jin, Qualcomm Magnus Kretz, Qualcomm March 15, 2004 RObust Header Compression (ROHC): Support for Reordering and Constant IP-ID Status of this memo By submitting this Internet-Draft, I (we) certify that any applicable patent or other IPR claims of which I am (we are) aware have been disclosed, and any of which I (we) become aware will be disclosed, in accordance with RFC 3668 (BCP 79). By submitting this Internet-Draft, I (we) accept the provisions of Section 3 of RFC 3667 (BCP 78). 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Kapoor, et al. [Page 1] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 Abstract RObust Header Compression (ROHC), RFC 3095, defines a framework for header compression, along with a number of compression protocols (profiles). This document seeks to add support for two issues to basic RoHC profiles, (a) the ability to handle reordering and (b) avoid extra header overhead when IP-ID is a constant value. The first issue can be supported by making the value of p (which is part of the RoHC interpretation interval) configurable. The second issue is already supported in the IP Profile of RoHC (RFC 3843). The discussion of this IP-ID issue in the current document merely replicates the discussion in RFC 3843 regarding constant IP-ID. Table of Contents 1. Introduction.....................................................2 2. Reordering Support...............................................3 2.1 Requirements on the p value .................................5 3. Support for Constant IP-ID ......................................6 4. Security Considerations..........................................7 5. References.......................................................8 5.1 Normative References.........................................8 5.1 Informative References.......................................8 6. Authors' Addresses...............................................8 1. Introduction Robust Header Compression (RoHC [1]) defines an efficient framework for header compression. Using RoHC, RTP/UDP/IP headers can be compressed down to 1 byte for a number of cases. While such good compression efficiency makes RoHC a desirable compression scheme for use over cellular links, the inability of basic RoHC profiles (3095) to handle reordering can reduce usefulness of RoHC in some cases. At the same time, it should be noted that the inability of the basic profiles of ROHC is not an inherent limitation of RoHC algorithms, but rather an artifact of parameter settings in RFC 3095. Kapoor, et al. [Page 2] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 The ôRoHC over Channels that can Reorder Packetsö draft [2] in fact, clarifies this exact point as in the excerpt below: ôSince the publication of RFC 3095 in 2001, the question about ROHC operation over channels that do not guarantee in-order delivery has surfaced several times; arguments that ROHC cannot perform adequately over such channels have even been heard. Specifically, this has been raised as a weakness when compared to other header compression alternatives, as RFC 3095 explicitly states its inability to operate if in-order delivery is not guaranteed. For those familiar with the details of ROHC and of other header compression schemes, it is clear that this is a misconception; but it can also be easily understood that the wording used in RFC 3095 can lead to such interpretation.ö Cases are known in today's networks where the physical/link layers can produce packets out-of-order. An example is the H-ARQ (Hybrid ARQ) mechanism, defined in the IS-856 and IS-2000 standards, which can cause out-of-order delivery of packets if the link layer does not put packets back in order. Out-of-order delivery of packets is thus, a practical reality for some networks of today. Another issue that can adversely affect RoHC header compression performance is the presence of IP-ID. 3095 profiles compress IP-ID using offset IP-ID encoding based on the UDP or RTP sequence number. Cases have been found where operating systems set IP-ID to 0. When the IP-ID is constant (i.e., 0), it cannot be compressed using offset IP-ID encoding and 2 bytes are needed to communicate it. This causes an unnecessary reduction in compression performance of RoHC. The IP profile of RoHC (RFC 3843 [3]) avoids such overhead with the addition of a flag within the dynamic part of the chain used to initialize the IPv4 header. When this flag is set, the IP-ID does not need to be sent. It would be desirable to also add such functionality to other RoHC profiles. This document describes the reordering and constant IP-ID issues and argues for a solution to be present in RoHC for these issues. 2. Reordering Support The LSB encoding method defined in RFC 3095 ([1], section 5.7) specifies the interpretation interval offset, called p, as follows: For profiles 0x0001, 0x0003 and 0x0007: p = 1, when bits (SN) <= 4; p = 2 ^ (bits (SN)-5) - 1 otherwise. Kapoor, et al. [Page 3] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 This results in the following table for the interpretation interval (from [2]: +-----------+--------------+--------------+ | bits (SN) | Offset p | (2^k-1) - p | | k | (reordering) | (losses) | +-----------+--------------+--------------+ | 4 | 1 | 14 | | 5 | 0 | 31 | | 6 | 1 | 62 | | 7 | 3 | 124 | | 8 | 7 | 248 | | 9 | 15 | 496 | +-----------+--------------+--------------+ For the above profiles, the offset p value determines the ability of RoHC to handle out-of-order (or sequentially late) packets. While larger values of k (>=7) can handle such out-of-order delivery, smaller k values (such as k = 4) which result in the best header compression performance do not have such reordering support. Also, as shown in the table above, there is an inherent trade-off between the ability of RoHC to handle reordering and consecutive dropped packets. Thus, a higher value of p can handle more out-of-order delivery at the cost of being able to handle a smaller number of consecutive dropped packets. As an example, for k = 4: If p = 3 (reordering), (2 ^ k-1) û p = 12 (consecutive drops) If p = 5 (reordering), (2 ^ k-1) û p = 10 (consecutive drops) For other profiles (0x0002, 0x0004 and 0x0008) p = - 1, independently of bits (SN). A value of p = -1 means that the interpretation interval offset can only take positive values, and that no sequentially late packet can be decompressed. While it is true that the original RoHC profiles (as defined in 3095) do not have support for reordering at small k values, this is not a limitation of the algorithms, but merely an artifact of the way the p value has been defined for these profiles. This draft seeks to address this limitation by allowing the p value to be configurable. Another reason for making the p value configurable is that link Kapoor, et al. [Page 4] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 characteristics differ. Some links produce out-of-order delivery, while others always deliver packets in order. Moreover, some links can drop consecutive packets, whereas in other links, such bursty errors are rare or do not occur. In other words, the p value that works best for one type of link may not be optimal for another. Thus, RoHC implementations can choose the best value of p to use depending upon link characteristics. 2.1 Requirements on the p value The encoding of the p value should be done with the following considerations: i. The p value should be configurable, i.e., it should be possible for the compressor to communicate this value to the decompressor. ii. The interpretation interval should be able to handle (a) both positive and negative changes and (b) only positive changes. iii. The p value should be adjustable for different values of k. iv. It should be possible to configure the p value per RoHC context. Based on the above four considerations, the following is an example of a solution which satisfies these considerations. In this example, 5 bits are used to communicate the p value as shown and defined below. 1 2 3 4 5 +----+----+----+----+----+ <--p Value for k=4--> Bits 2-5 carry the value of p to be used when k = 4. These values can either be positive: 0 (0000) to 14 (1110) or -1 (represented by bit pattern 1111). Bit 1 determines how the p value is defined when k > 4. ò If bit 1 is set to 1, then the same p value (as for k = 4) also applies to other k values. Kapoor, et al. [Page 5] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 ò If bit 1 is set to 0, the p value is scaled up (for positive p) based on the size of the interpretation interval defined by k = n relative to k = 4. Thus, p(n) = p(4) * (2 ^ n)/(2 ^ 4) where p(n) is the value of p when k = n and p(4) is the value of p when k = 4 (i.e., the value carried in bits 2-5). This scaling is not applied when bits 2-5 are 1111 (i.e., p = -1). In this case, p = -1 is used for all values of k regardless of the value of bit 1. In order to satisfy consideration (iv) above, the p value can be communicated as part of the IR header. This allows configuration of the p value per context. 3. Support for Constant IP-ID (this section is similar to Section 3.3 of RFC 3843 [2]) Most IPv4 stacks assign an IP-ID according to the value of a counter, increasing by one for each outgoing packet. ROHC IP-ID algorithms (Section 4.5.5 of RFC 3095) compress the IP-ID field using offset IP-ID encoding based on the RTP or UDP SN. For stacks generating IP-ID values using a pseudo-random number generator, the field is not compressed and is sent as-is in its entirety as additional octets after the compressed header. Cases have also been found where an IPv4 stack uses a constant value for the IP-ID field. Such IP-ID behavior can be seen as a violation of RFC 791, which says: "the sender must choose the Identifier to be unique for this source, destination pair and protocol for the time the datagram (or any fragment of it) could be alive in the internet." Nevertheless, existing operating systems (such as Linux 2.4.x) are known to set the IP-ID to 0 for UDP packet when the DF (do not fragment) bit in the IP header is set. When the IP-ID field is constant, it cannot be compressed using offset IP-ID encoding and 2 bytes are needed to communicate it. This is an unnecessary overhead and RoHC profiles should be able to handle such OS behavior without the extra 2-byte overhead. Kapoor, et al. [Page 6] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 As an example, this overhead can be avoided with the addition of a flag within the dynamic part of the chain used to initialize the IPv4 header, as follows: Dynamic part: +---+---+---+---+---+---+---+---+ | Type of Service | +---+---+---+---+---+---+---+---+ | Time to Live | +---+---+---+---+---+---+---+---+ / Identification / 2 octets +---+---+---+---+---+---+---+---+ | DF|RND|NBO|SID| 0 | +---+---+---+---+---+---+---+---+ / Generic extension header list / variable length +---+---+---+---+---+---+---+---+ SID: Static IP Identifier. For IR and IR-DYN packets, the logic is the same as for ROHC basic profiles (as described in RFC 3095) with the addition that field (SID) must be kept in the context. For compressed headers other than IR and IR-DYN: If value (RND) = 0 and context (SID) = 0, hdr (IP-ID) is compressed using Offset IP-ID encoding (see [RFC-3095 section 4.5.5]) using p = 0 and default-slope (IP-ID offset) = 0. If value (RND) = 1 and context (SID) = 0, IP-ID is the uncompressed hdr (IP-ID). IP-ID is then passed as additional octets at the end of the compressed header, after any extensions. If context (SID) = 1, hdr (IP-ID) is constant and compressed away; hdr (IP-ID) is the value of context (IP-ID). When using this combination, the UO-1 packet can be used even when the version of IP being used is IPv4 and IP-ID is constant. This has the advantage that an extra bit is available for compressing RTP timestamp compared to using the UO-1-TS packet. Kapoor, et al. [Page 7] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 4. Security Considerations There are no security considerations in this problem statemement per se. However, whatever mechanism is designed or chosen to address the problems should avoid the introduction of new security concerns for ROHC. 5. References 5.1 Normative References [1] C. Bormann, et. al, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001. [2] L-E. Jonsson, G. Pelletier, K. Sandlund: "RObust Header Compression (ROHC): ROHC over Channels that can Reorder Packets", November 12, 2004. [3] L-E. Jonsson and G. Pelletier, "RObust Header Compression (ROHC): A compression profile for IP", RFC 3843, June 2004. 5.2 Informative References Kapoor, et al. [Page 8] INTERNET-DRAFT Reordering and Constant IP-ID March 15, 2005 6. Authors' Addresses Rohit Kapoor Qualcomm 5775, Morehouse Dr San Diego, CA, USA. EMail: rkapoor@qualcomm.com Haipeng Jin Qualcomm 5775, Morehouse Dr San Diego, CA, USA. EMail: hjin@qualcomm.com Magnus Kretz Qualcomm 5775, Morehouse Dr San Diego, CA, USA. EMail: mkretz@qualcomm.com Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Kapoor, et al. [Page 9]