Network Working Group                                  Lars-Erik                                       L-E. Jonsson
INTERNET-DRAFT                                                  Ericsson
Expires: December 2003 2004                                      June 12, 2003 9, 2004

               Requirements on ROHC TCP/IP Header Compression

Status of this memo

   This document is an Internet-Draft

   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 is any of which I (we) become aware will be disclosed, in full conformance
   accordance with
   all RFC 3668 (BCP 79).

   By submitting this Internet-Draft, I (we) accept the provisions of
   Section 10 3 of RFC2026. 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This document is a submission of the IETF ROHC WG. Comments should be
   directed to the ROHC WG mailing list,


   This document contains requirements on the TCP/IP header compression
   scheme (profile) to be developed by the ROHC WG. The document
   discusses the scope of TCP compression, performance considerations,
   assumptions on the surrounding environment, as well as IPR concerns.
   The structure of this document is inherited from the document
   defining RTP/UDP/IP requirements [5] for ROHC.

Table of Contents

   1. Introduction.....................................................2
   2. Header Compression Requirements..................................2
      2.1. Impact on Internet Infrastructure...........................3
      2.2. Supported Headers and Kinds of TCP Streams..................3
      2.3. Performance Issues..........................................4
      2.4. Requirements Related to Link Layer Characteristics..........6
      2.5. Intellectual Property Rights (IPR)..........................7
   3. Security Consideration...........................................7
   4. IANA Considerations..............................................7
   5. Acknowledgments..................................................7
   6. Authors' Address.................................................7
   7. References.......................................................8

1. Introduction

   The goal of the ROHC WG is to develop header compression schemes that
   perform well over links with high error rates and long link roundtrip
   times. The schemes must perform well for cellular links, using
   technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes
   should also be applicable to other future link technologies with high
   loss and long roundtrip times.

   The main objective for ROHC has been robust compression of
   IP/UDP/RTP, but the WG is also chartered to develop new header
   compression solutions for IP/TCP [RFC-791, RFC-793]. [1], [2]. Since TCP traffic, in
   contrast to RTP, has usually been sent over reliable links, existing
   schemes for TCP [RFC-1144, RFC-2507] TCP, [3] and [4], have not experienced the same
   robustness problems as RTP compression. However, there are still many
   scenarios where TCP header compression will be implemented over less
   reliable links [RFC-3150, PILC-ARQ], [11], [12], making robustness an important objective
   also for the new TCP compression scheme. Other, equally important,
   objectives for ROHC TCP compression are: improved compression
   efficiency, enhanced capabilities for compression of header fields
   including TCP options, and finally incorporation of TCP compression
   into the ROHC framework [RFC-3095]. [6].

2. Header Compression Requirements

   The following requirements have, more or less arbitrarily, been
   divided into five groups. The first group deals with requirements
   concerning the impact of a header compression scheme on the rest of
   the Internet infrastructure. The second group defines what kind of
   headers must be compressed efficiently, while the third and fourth
   groups concern performance requirements and capability requirements
   which stem from the properties of the anticipated link technologies.
   Finally, the fifth section discusses Intellectual Property Rights
   related to ROHC TCP compression.

2.1. Impact on Internet Infrastructure

   1. Transparency: When a header is compressed and then decompressed,
      the resulting header must be semantically identical to the
      original header. If this cannot be achieved, the packet containing
      the erroneous header must be discarded.

      Justification: The header compression process must not produce
      headers that might cause problems for any current or future part
      of the Internet infrastructure.

      Note: The ROHC WG has not found a case where "semantically
      identical" is not the same as "bitwise identical".

   2. Ubiquity: Must not require modifications to existing IP (v4 or
      v6) or TCP implementations.

      Justification: Ease of deployment.

      Note: The ROHC WG may recommend changes that would increase the
      compression efficiency for the TCP streams emitted by
      implementations. However, ROHC cannot rely on such recommendations
      being followed.

      Note: Several TCP variants are currently in use on the Internet.
      This requirement implies that the header compression scheme must
      work efficiently and correctly for all expected TCP variants.

2.2. Supported Headers and Kinds of TCP Streams

   1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that
      all possible changes in the IP header fields must be handled by
      the compression scheme, and commonly changing fields should be
      compressed efficiently. Compression must not be disabled if IPv4
      Options or IPv6 Extensions are present. The compression scheme
      must further consider as normal operation the scenario where
      Explicit Congestion Notification (ECN) [RFC-3168] [10] is applied and support
      efficient compression also in the case when the ECN bits are used.

      Justification: IPv4 and IPv6 will both be around for the
      foreseeable future, and Options/Extensions are expected to be more
      commonly used. ECN is expected to have a breakthrough and be
      widely deployed, especially in combination with TCP.

   2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be
      supported and should be compressed efficiently. For IPv4 these
      include headers of tunneled packets. For IPv6 they include headers
      containing the Routing Header, the Binding Update Destination
      Option, and the Home Address Option.

      Justification: It is very likely that Mobile IP will be used by
      cellular devices.

   3. Generality: Must handle all headers from arbitrary TCP streams.

      Justification: There must be a generic scheme which can compress
      reasonably well for any TCP traffic pattern. This does not
      preclude optimizations for certain traffic patterns.

   4. IPSEC: The scheme should be able to compress headers containing
      IPSEC sub-headers.

      Justification: IPSEC is expected to be used to provide necessary
      end-to-end security.

      Note: It is not possible to compress the encrypted part of an ESP
      header, nor the cryptographic data in an AH header.

   5. TCP: All fields supported by [RFC-2507] [4] should be handled with efficient
      compression, and so also the cases when the SYN, FIN or TCP ECN [RFC-3168]
      [10] bits are set.

      Justification: These bits are expected to be commonly used.

   6. TCP options: The scheme must support compression of packets with
      any TCP option present, even if the option itself is not
      compressed. Further, for some commonly used options the scheme
      should provide compression mechanisms also for the options.

      Justification: Since various TCP options are commonly used,
      applicability of the compression scheme would be significantly
      reduced if packets with options could not be compressed.

      Note: Options that should be compressed are:
            - Selective Acknowledgement (SACK), [RFC-2018, RFC-2883] [8], [9]
            - Timestamp, [RFC-1323] [7]

2.3. Performance Issues

   1. Performance/Spectral Efficiency: The scheme must provide low
      relative overhead under expected operating conditions; compression
      efficiency should be better than for RFC2507 RFC 2507 [4] under equivalent
      operating conditions.

      Justification: Spectrum efficiency is a primary goal.

      Note: The relative overhead is the average header overhead
      relative to the payload. Any auxiliary (e.g., control or feedback)
      channels used by the scheme should be taken into account when
      calculating the header overhead.

   2. Losses between compressor and decompressor: The scheme should make
      sure that losses between compressor and decompressor do not result in
      losses of subsequent packets, or cause damage to the context that
      result in incorrect decompression of subsequent packet headers.

      Justification: Even though link layer retransmission in most cases
      is expected to almost eliminate losses between compressor and
      decompressor, there are still many scenarios where TCP header
      compression will be implemented over less reliable links [RFC-
       3150, PILC-ARQ]. [11],
      [12]. In such cases, loss propagation due to header compression
      could affect certain TCP mechanisms that are capable of handling
      some losses, and have a negative impact on the performance of TCP
      loss recovery.

   3. Residual errors in compressed headers: Residual errors in
      compressed headers may result in delivery of incorrectly
      decompressed headers not only for the damaged packet itself, but
      also for subsequent packets, since errors may be saved in the
      context state. For TCP, the compression scheme is not required to
      implement explicit mechanisms for residual error detection, but
      the compression scheme must not affect TCP's end-to-end mechanisms
      for error detection.

      Justification: For links carrying TCP traffic, the residual error
      rate is expected to be insignificant. However, residual errors may
      still occur, especially in the end-to-end path, and therefore it
      is crucial that TCP is not prevented from handling these.

      Note: This requirement implies that the TCP checksum must be
      carried unmodified in all compressed headers.

      Note: The error detection mechanism in TCP may be able to detect
      residual bit errors, but the mechanism is not designed for this
      purpose, and might actually provide a rather weak protection.
      Therefore, although it is not a requirement on the compression
      scheme, the decompressor should discard packets which are known to
      contain residual errors.

   4. Short-lived TCP transfers: The scheme should provide mechanisms
      for efficient compression of short-lived TCP transfers, minimizing
      the size of context initiation headers.

      Justification: Many TCP transfers are short-lived. This may lead
      to a low gain for header compression schemes that for all new
      packet streams require full headers to be sent initially and allow
      small compressed headers only after the initiation phase.

      Note: This requirement implies that mechanisms for "context
      sharing" (concurrent packet streams share context information) or
      "context re-use" (new contexts can be built on information from
      previous contexts) should be considered.

   5a. Moderate Packet Misordering: The scheme should efficiently handle
      moderate misordering (2-3 packets) in the packet stream reaching
      the compressor.

      Justification: This kind of misordering is common.

   5b. Packet Misordering: The scheme must be able to correctly handle
      and preferably compress also when there are misordered packets in
      the TCP stream reaching the compressor.

      Justification: Misordering happens regularly in the Internet.
      However, since the Internet is engineered to run TCP reasonably
      well, excessive misordering will not be common and need not be
      handled with optimum efficiency.

   6. Processing delay: The scheme should not contribute significantly
      to the system delay budget.

2.4.  Capability Requirements Related to Link Layer Characteristics

   1. Unidirectional links: Must be possible to implement (possibly with
      less efficiency) without explicit feedback messages from
      decompressor to compressor.

      Justification: There are links that do not provide a feedback
      channel or where feedback is not desirable for other reasons.

   2. Misordering between compressor and decompressor: The header
      compression scheme must be able to handle misordered packets
      between compressor and decompressor, but can assume that packet
      misordering is indicated to the decompressor by the lower layers.

      Justification: When compression is applied over tunnels,
      misordering often cannot be completely avoided. A header
      compression scheme that prohibits misordering between compressor
      and decompressor would therefore not be applicable in many
      tunneling scenarios. However, in the case of tunneling, it is
      usually possible to get misordering indications. Therefore, the
      compression scheme does not have to support detection of
      misordering, but can assume that such information is available
      from lower layers.

   3. Link delay: Must operate under all expected link delay conditions.

   4. Header compression coexistence: The scheme must fit into the ROHC
      framework together with other ROHC profiles (e.g. [RFC-3095]). [6]).

2.5. Intellectual Property Rights (IPR)

   The ROHC WG must spend effort to achieve a high degree of confidence
   that there is no IPR covering a final compression solution for TCP.

   Justification: Currently there is no TCP header compression scheme
   available that can efficiently compress the packet headers of modern
   TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill this gap by
   providing a ROHC TCP scheme that is applicable in the wide area
   Internet, not only over error-prone radio links. It must thus attempt
   to be as future-proof as possible, and only unencumbered solutions
   will be acceptable to the Internet at large.

3.  IANA Considerations

   A protocol which meets these requirements will require the IANA to
   assign various numbers. This document by itself, however, does not
   require any IANA involvement.

4. Security Considerations Consideration

   A protocol specified to meet these requirements must be able to
   compress packets containing IPSEC headers according to the IPSEC
   requirement, 2.2.4. There may be other security aspects to consider
   in such protocols.  This document by itself, however, does not add
   any security risks.

4. IANA Considerations

   A protocol that meets these requirements will require the IANA to
   assign various numbers. This document by itself, however, does not
   require any IANA involvement.

5.  Acknowledgements Acknowledgments

   This document has evolved through fruitful discussions with and input
   from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West,
   Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The
   document quality was significantly improved thanks to Peter Eriksson,
   who made a thorough linguistic review.

6. Authors' Address

   Lars-Erik Jonsson              Tel: +46 920 20 21 07
   Ericsson AB                    Fax: +46 920 20 20 99
   Box 920
   SE-971 28 Lulea
   Sweden                         EMail:

7. References


   [1]  Jon Postel, Internet Protocol, RFC 791, September 1981.


   [2]  Jon Postel, Transport Control Protocol, RFC 793, September 1981.


   [3]  Van Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial
        Links", RFC 1144, February 1990.


   [4]  Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header
        Compression", RFC 2507, February 1999.


   [5]  Mikael Degermark, "Requirements for IP/UDP/RTP header
        compression", RFC 3096, July 2001.


   [6]  Carsten Bormann, et. al., "Robust Header Compression (ROHC)",
        RFC 3095, July 2001.


   [7]  Van Jacobson, Bob Braden, Dave Borman, "TCP Extensions for High
        Performance", RFC 1323, May 1992.


   [8]  Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn Romanow, "TCP
        Selective Acknowledgement Option", RFC 2018, October 1996.


   [9]  Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew Podolsky, "An
        Extension to the Selective Acknowledgement (SACK) Option for
        TCP", RFC 2883, July 2000.


   [10] K. K. Ramakrishnan, Sally Floyd, David L. Black, "The Addition
        of Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.


   [11] Spencer Dawkins, Gabriel Montenegro, Markku Kojo, Vincent
        Magret, "End-to-end Performance Implications of Slow Links", RFC
        3150, July 2001.


   [12] Gorry Fairhurst, Lloyd Wood, "Advice to link designers on link
        Automatic Repeat reQuest (ARQ)", RFC 3366, August 2002.

7.  Author's Address

   Lars-Erik Jonsson              Tel: +46 920 20 21 07
   Ericsson AB                    Fax: +46 920 20 20 99
   Box 920
   SE-971 28 Lulea
   Sweden                         EMail:

Full Copyright

Intellectual Property Statement

   Copyright (C)

   The Internet Society (2001). All Rights Reserved.

   This document and translations IETF takes no position regarding the validity or scope of it may any
   Intellectual Property Rights or other rights that might be copied and furnished claimed to
   others, and derivative works that comment on or otherwise explain it
   or assist in its
   pertain to the implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction use of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, technology described in
   this document itself may or the extent to which any license under such rights
   might or might not be modified in available; nor does it represent that it has
   made any independent effort to identify any way, such as by removing rights. Information
   on the copyright notice or references IETF's procedures with respect to rights in IETF Documents can
   be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79).

   Copies of IPR disclosures made to the Internet Society IETF Secretariat and any
   assurances of licenses to be made available, or other
   Internet organizations, except as needed for the purpose result of
   developing Internet standards in which case the procedures an
   attempt made to obtain a general license or permission for
   copyrights defined in the Internet Standards process must be
   followed, use of
   such proprietary rights by implementers or as required users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to translate it into languages bring to its attention any
   copyrights, patents or patent applications, or other than

   The limited permissions granted above are perpetual and will not proprietary
   rights that may cover technology that may be
   revoked by required to implement
   this standard. Please address the information to the IETF at ietf-

Copyright Statement

   Copyright (C) The Internet Society or its successors or assigns. (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 is are provided on an

This Internet-Draft expires December 12, 2003. 9, 2004.