[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4163

Network Working Group                        Lars-Erik Jonsson, Ericsson
INTERNET-DRAFT                                                    Sweden
Expires: May 2002                                      November 21, 2001








            Requirements for ROHC IP/TCP Header Compression
               <draft-ietf-rohc-tcp-requirements-02.txt>


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 a submission of the IETF ROHC WG. Comments should be
   directed to the ROHC WG mailing list, rohc@cdt.luth.se.

Abstract

   This document contains requirements for the IP/TCP header compression
   scheme (profile) to be developed by the ROHC WG. The structure of
   this document is inherited from the document defining IP/UDP/RTP
   requirements for ROHC.










Jonsson                                                         [Page 1]

INTERNET-DRAFT        Requirements for IP/TCP ROHC     November 21, 2001


0.  Document history

   February 23, 2001 - draft-ietf-rohc-tcp-requirements-00.txt

     Initial version to initiate discussion of TCP aspects in ROHC.

   June 20, 2001 - draft-ietf-rohc-tcp-requirements-01.txt

     ECN requirements, note to "Short lived TCP transfers", and a
     section discussing the IPR issue have been added.

   November 21, 2001 - draft-ietf-rohc-tcp-requirements-02.txt

     The error propagation requirement has been split in two parts and
     updated. Further have references to PILC documents and a note for
     "Ubiquity" about TCP versions been added.

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]. Since TCP
   traffic, in contrast to RTP, has usually been sent over reliable
   links, existing schemes for TCP [RFC-1144, RFC-2507] 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], making
   robustness an important objective also for the new TCP compression
   scheme. Other, as 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].

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 that must be compressed efficiently while the third and forth
   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.




Jonsson                                                         [Page 2]

INTERNET-DRAFT        Requirements for IP/TCP ROHC     November 21, 2001


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 versions are currently in use on the Internet.
      This requirement implies that the header compression scheme must
      work efficiently and correct for all expected TCP versions.

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. The compression scheme must consider as
      normal operation the scenario where Early Congestion Notification
      [RFC-3168] is used and support efficient compression also in the
      case when the ECN bits are used.

      Justification: IPv4 and IPv6 will both be around during the
      foreseeable future. ECN is expected to get 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 these 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.





Jonsson                                                         [Page 3]

INTERNET-DRAFT        Requirements for IP/TCP ROHC     November 21, 2001


   3. Generality: Must compress 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.

      Note: This applies to the TCP stream before as well as after it
      has passed through an internet.

   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 of course 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] must be handled with
      efficient compression, and so also the cases when the SYN, FIN or
      ECN 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:
              - Window scale, [RFC-1323]
              - Selective Acknowledgement (SACK), [RFC-2018, RFC-2883]
              - Timestamp, [RFC-1323]


















Jonsson                                                         [Page 4]

INTERNET-DRAFT        Requirements for IP/TCP ROHC     November 21, 2001


2.3.  Performance issues

   1. Performance/Spectral Efficiency: Must provide low relative
      overhead under expected operating conditions; compression
      efficiency should be better than for RFC2507 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. Loss propagation: Loss propagation due to header compression
      should be avoided. Loss propagation is defined as the loss of
      headers subsequent to headers lost by the link, even if those
      subsequent headers are not lost by the link.

      Justification: Even though link layer retransmission in most
      cases is expected to make loss propagation an irrelevant issue,
      there are still many scenarios where TCP header compression will
      be implemented over less reliable links [RFC-3150, PILC-ARQ]. In
      such cases, loss propagation due to header compression could
      affect certain TCP mechanisms that are capable of handling some
      losses, and thereby cause significant performance degradation.

   3. Damage propagation and handling of residual errors: Damage
      propagation is defined as the damage of headers subsequent to
      headers damaged by the link, even if those subsequent headers are
      not damaged by the link. For TCP, the compression scheme is not
      required to explicitly implement mechanisms for damage
      propagation avoidance, but the compression scheme must not affect
      TCP's end-to-end mechanisms for handling of residual errors.

      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.

   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 means
      that the gain of header compression could be low since normally
      header compression sends full headers initially and small
      compressed headers first after the initiation phase.

      Note: This requirement implies that mechanisms for "context
      sharing" or "context re-use" should be considered.




Jonsson                                                         [Page 5]

INTERNET-DRAFT        Requirements for IP/TCP ROHC     November 21, 2001



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

      Justification: This kind of reordering is common.

   5b. Packet Reordering: The scheme should be able to compress when
      there are reordered packets in the TCP stream reaching the
      compressor.

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

   6. Processing delay: The scheme must not contribute significantly to
      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 feedback is not desirable for other reasons.

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

   3. Header compression coexistence: The scheme must fit into the ROHC
      framework together with other ROHC profiles

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 can be 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, in
      particular, only unencumbered solutions will be acceptable to the
      Internet at large.








Jonsson                                                         [Page 6]

INTERNET-DRAFT        Requirements for IP/TCP ROHC     November 21, 2001


3.  Open questions - For further discussion

   Q: Should we require the scheme to be capable of handling some
      reordering between compressor and decompressor?

   Q: Should we have a separate requirement for reordering of acks?

4.  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.

5.  Security Considerations

   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.

6.  References

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

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

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

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

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

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

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

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

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





Jonsson                                                         [Page 7]

INTERNET-DRAFT        Requirements for IP/TCP ROHC     November 21, 2001


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

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

   [PILC-ARQ]  Gorry Fairhurst, Lloyd Wood, "Advice to link designers
               on link Automatic Repeat reQuest (ARQ)", Internet Draft
               (work in progress), August 2001.
               <draft-ietf-pilc-link-arq-issues-03.txt>

7.  Author's address

   Lars-Erik Jonsson              Tel: +46 920 20 21 07
   Ericsson Erisoft AB            Fax: +46 920 20 20 99
   Box 920                        Mobile: +46 70 513 56 21
   SE-971 28 Lulea
   Sweden                         EMail: lars-erik.jonsson@ericsson.com





This Internet-Draft expires May 21, 2002.





























Jonsson                                                         [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/