Network Working Group Lars-Erik Jonsson INTERNET-DRAFT Ericsson Expires: November 2002 May 28, 2002 Requirements on ROHC TCP/IP Header Compression 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@ietf.org. Abstract 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 for ROHC. Jonsson [Page 1] INTERNET-DRAFT Requirements on ROHC TCP/IP May, 2002 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, 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]. 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". Jonsson [Page 2] INTERNET-DRAFT Requirements on ROHC TCP/IP May, 2002 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] 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. Jonsson [Page 3] INTERNET-DRAFT Requirements on ROHC TCP/IP May, 2002 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] should be handled with efficient compression, and so also the cases when the SYN, FIN or TCP ECN [RFC-3168] 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] - Timestamp, [RFC-1323] 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 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]. 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. Jonsson [Page 4] INTERNET-DRAFT Requirements on ROHC TCP/IP May, 2002 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 Jonsson [Page 5] INTERNET-DRAFT Requirements on ROHC TCP/IP May, 2002 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]). 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. Jonsson [Page 6] INTERNET-DRAFT Requirements on ROHC TCP/IP May, 2002 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 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. 5. Acknowledgements 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. 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 on ROHC TCP/IP May, 2002 [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), March 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: lars-erik.jonsson@ericsson.com Jonsson [Page 8] INTERNET-DRAFT Requirements on ROHC TCP/IP May, 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). 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 languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. This Internet-Draft expires November 28, 2002. Jonsson [Page 9]