One document matched: draft-kapoor-rohc-rtp-new-requirements-00.txt
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
<draft-kapoor-rohc-rtp-new-requirements-00.txt>
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]
| PAFTECH AB 2003-2026 | 2026-04-23 01:34:27 |