idnits 2.17.1 draft-ietf-rohc-tcp-requirements-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([5]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 14, 2004) is 7136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. '2') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1323 (ref. '7') (Obsoleted by RFC 7323) Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L-E. Jonsson 2 INTERNET-DRAFT Ericsson 3 Expires: March 2005 September 14, 2004 5 Requirements on ROHC TCP/IP Header Compression 6 8 Status of this memo 10 By submitting this Internet-Draft, I (we) certify that any applicable 11 patent or other IPR claims of which I am (we are) aware have been 12 disclosed, and any of which I (we) become aware will be disclosed, in 13 accordance with RFC 3668 (BCP 79). 15 By submitting this Internet-Draft, I (we) accept the provisions of 16 Section 3 of RFC 3667 (BCP 78). 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a submission of the IETF ROHC WG. Comments should be 34 directed to the ROHC WG mailing list, rohc@ietf.org. 36 Abstract 38 This document contains requirements on the TCP/IP header compression 39 scheme (profile) to be developed by the ROHC WG. The document 40 discusses the scope of TCP compression, performance considerations, 41 assumptions on the surrounding environment, as well as IPR concerns. 42 The structure of this document is inherited from the document 43 defining RTP/UDP/IP requirements [5] for ROHC. 45 Table of Contents 47 1. Introduction.....................................................2 48 2. Header Compression Requirements..................................2 49 2.1. Impact on Internet Infrastructure...........................3 50 2.2. Supported Headers and Kinds of TCP Streams..................3 51 2.3. Performance Issues..........................................4 52 2.4. Requirements Related to Link Layer Characteristics..........6 53 2.5. Intellectual Property Rights (IPR)..........................7 54 3. Security Consideration...........................................7 55 4. IANA Considerations..............................................7 56 5. Acknowledgments..................................................7 57 6. Authors' Address.................................................7 58 7. Informative References...........................................8 60 1. Introduction 62 The goal of the ROHC WG is to develop header compression schemes that 63 perform well over links with high error rates and long link roundtrip 64 times. The schemes must perform well for cellular links, using 65 technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes 66 should also be applicable to other link technologies with high loss 67 and long roundtrip times. 69 The main objective for ROHC has been robust compression of 70 IP/UDP/RTP, but the WG is also chartered to develop new header 71 compression solutions for IP/TCP [1], [2]. Since TCP traffic, in 72 contrast to RTP, has usually been sent over reliable links, existing 73 schemes for TCP, [3] and [4], have not experienced the same 74 robustness problems as RTP compression. However, there are still many 75 scenarios where TCP header compression will be implemented over less 76 reliable links [11], [12], making robustness an important objective 77 also for the new TCP compression scheme. Other, equally important, 78 objectives for ROHC TCP compression are: improved compression 79 efficiency, enhanced capabilities for compression of header fields 80 including TCP options, and finally incorporation of TCP compression 81 into the ROHC framework [6]. 83 2. Header Compression Requirements 85 The following requirements have, more or less arbitrarily, been 86 divided into five groups. The first group deals with requirements 87 concerning the impact of a header compression scheme on the rest of 88 the Internet infrastructure. The second group defines what kind of 89 headers must be compressed efficiently, while the third and fourth 90 groups concern performance requirements and capability requirements 91 that stem from the properties of link technologies where ROHC TCP is 92 expected to be used. Finally, the fifth section discusses 93 Intellectual Property Rights related to ROHC TCP compression. 95 2.1. Impact on Internet Infrastructure 97 1. Transparency: When a header is compressed and then decompressed, 98 the resulting header must be semantically identical to the 99 original header. If this cannot be achieved, the packet containing 100 the erroneous header must be discarded. 102 Justification: The header compression process must not produce 103 headers that might cause problems for any current or future part 104 of the Internet infrastructure. 106 Note: The ROHC WG has not found a case where "semantically 107 identical" is not the same as "bitwise identical". 109 2. Ubiquity: Must not require modifications to existing IP (v4 or 110 v6) or TCP implementations. 112 Justification: Ease of deployment. 114 Note: The ROHC WG may recommend changes that would increase the 115 compression efficiency for the TCP streams emitted by 116 implementations. However, ROHC cannot rely on such recommendations 117 being followed. 119 Note: Several TCP variants are currently in use on the Internet. 120 This requirement implies that the header compression scheme must 121 work efficiently and correctly for all expected TCP variants. 123 2.2. Supported Headers and Kinds of TCP Streams 125 1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that 126 all expected changes in the IP header fields must be handled by 127 the compression scheme, and commonly changing fields should be 128 compressed efficiently. Compression must still be possible when 129 IPv6 Extensions are present in the header. When designing the 130 compression scheme, the usage of Explicit Congestion Notification 131 (ECN) [10] should be considered as a common behavior. Therefore, 132 the scheme must compress efficiently also in the case when the ECN 133 bits are used. 135 Justification: IPv4 and IPv6 will both be around for the 136 foreseeable future, and Options/Extensions are expected to be more 137 commonly used. ECN is expected to have a breakthrough and be 138 widely deployed, especially in combination with TCP. 140 2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be 141 supported and should be compressed efficiently. For IPv4 these 142 include headers of tunneled packets. For IPv6 they include headers 143 containing the Routing Header, and the Home Address Option. 145 Justification: It is very likely that Mobile IP will be used by 146 cellular devices. 148 3. Generality: Must handle all headers from arbitrary TCP streams. 150 Justification: There must be a generic scheme which can compress 151 reasonably well for any TCP traffic pattern. This does not 152 preclude optimizations for certain traffic patterns. 154 4. IPSEC: The scheme should be able to compress headers containing 155 IPSEC sub-headers where the NULL encryption algorithm is used. 157 Justification: IPSEC is expected to be used to provide necessary 158 end-to-end security. 160 Note: It is not possible to compress the encrypted part of an ESP 161 header, nor the cryptographic data in an AH header. 163 5. TCP: All fields supported by [4] should be handled with efficient 164 compression, and so also the cases when the SYN, FIN or TCP ECN 165 [10] bits are set. 167 Justification: These bits are expected to be commonly used. 169 6. TCP options: The scheme must support compression of packets with 170 any TCP option present, even if the option itself is not 171 compressed. Further, for some commonly used options the scheme 172 should provide compression mechanisms also for the options. 174 Justification: Since various TCP options are commonly used, 175 applicability of the compression scheme would be significantly 176 reduced if packets with options could not be compressed. 178 Note: Options that should be compressed are: 179 - Selective Acknowledgement (SACK), [8], [9] 180 - Timestamp, [7] 182 2.3. Performance Issues 184 1. Performance/Spectral Efficiency: The scheme must provide low 185 relative overhead under expected operating conditions; compression 186 efficiency should be better than for RFC 2507 [4] under equivalent 187 operating conditions. 189 Justification: Spectrum efficiency is a primary goal. 191 Note: The relative overhead is the average header overhead 192 relative to the payload. Any auxiliary (e.g., control or feedback) 193 channels used by the scheme should be taken into account when 194 calculating the header overhead. 196 2. Losses between compressor and decompressor: The scheme should make 197 sure losses between compressor and decompressor do not result in 198 losses of subsequent packets, or cause damage to the context that 199 result in incorrect decompression of subsequent packet headers. 201 Justification: Even though link layer retransmission in most cases 202 is expected to almost eliminate losses between compressor and 203 decompressor, there are still many scenarios where TCP header 204 compression will be implemented over less reliable links [11], 205 [12]. In such cases, loss propagation due to header compression 206 could affect certain TCP mechanisms that are capable of handling 207 some losses, and have a negative impact on the performance of TCP 208 loss recovery. 210 3. Residual errors in compressed headers: Residual errors in 211 compressed headers may result in delivery of incorrectly 212 decompressed headers not only for the damaged packet itself, but 213 also for subsequent packets, since errors may be saved in the 214 context state. For TCP, the compression scheme is not required to 215 implement explicit mechanisms for residual error detection, but 216 the compression scheme must not affect TCP's end-to-end mechanisms 217 for error detection. 219 Justification: For links carrying TCP traffic, the residual error 220 rate is expected to be insignificant. However, residual errors may 221 still occur, especially in the end-to-end path, and therefore it 222 is crucial that TCP is not prevented from handling these. 224 Note: This requirement implies that the TCP checksum must be 225 carried unmodified in all compressed headers. 227 Note: The error detection mechanism in TCP may be able to detect 228 residual bit errors, but the mechanism is not designed for this 229 purpose, and might actually provide a rather weak protection. 230 Therefore, although it is not a requirement on the compression 231 scheme, it should be possible for the decompressor to detect 232 residual errors and discard such packets. 234 4. Short-lived TCP transfers: The scheme should provide mechanisms 235 for efficient compression of short-lived TCP transfers, minimizing 236 the size of context initiation headers. 238 Justification: Many TCP transfers are short-lived. This may lead 239 to a low gain for header compression schemes that, for each new 240 packet stream, require full headers to be sent initially and allow 241 small compressed headers only after the initialization phase. 243 Note: This requirement implies that mechanisms for building new 244 contexts based on information from previous contexts or for 245 concurrent packet streams to share context information should be 246 considered. 248 5a. Moderate Packet Misordering: The scheme should efficiently handle 249 moderate misordering (2-3 packets) in the packet stream reaching 250 the compressor. 252 Justification: This kind of misordering is common. 254 5b. Packet Misordering: The scheme must be able to correctly handle 255 and preferably compress also when there are misordered packets in 256 the TCP stream reaching the compressor. 258 Justification: Misordering happens regularly in the Internet. 259 However, since the Internet is engineered to run TCP reasonably 260 well, excessive misordering will not be common and need not be 261 handled with optimum efficiency. 263 6. Processing delay: The scheme should not contribute significantly 264 to the system delay budget. 266 2.4. Requirements Related to Link Layer Characteristics 268 1. Unidirectional links: Must be possible to implement (possibly with 269 less efficiency) without explicit feedback messages from 270 decompressor to compressor. 272 Justification: There are links that do not provide a feedback 273 channel or where feedback is not desirable for other reasons. 275 2. Link delay: Must operate under all expected link delay conditions. 277 3. Header compression coexistence: The scheme must fit into the ROHC 278 framework together with other ROHC profiles (e.g. [6]). 280 4. Note on misordering between compressor and decompressor: 282 When compression is applied over tunnels, misordering often cannot 283 be completely avoided. The header compression scheme should not 284 prohibit misordering between compressor and decompressor, as it 285 would therefore not be applicable in many tunneling scenarios. 286 However, in the case of tunneling, it is usually possible to get 287 misordering indications. Therefore, the compression scheme does 288 not have to support detection of misordering, but can assume that 289 such information is available from lower layers when misordering 290 can occur. 292 2.5. Intellectual Property Rights (IPR) 294 The ROHC WG must spend effort to achieve a high degree of confidence 295 that there are no known IPR that covers a final compression solution 296 for TCP. 298 Justification: Currently there is no TCP header compression scheme 299 available that can efficiently compress the packet headers of modern 300 TCP, e.g. with SACK, ECN, etc. ROHC is expected to fill this gap by 301 providing a ROHC TCP scheme that is applicable in the wide area 302 Internet, not only over error-prone radio links. It must thus attempt 303 to be as future-proof as possible, and only unencumbered solutions 304 will be acceptable to the Internet at large. 306 3. Security Consideration 308 A protocol specified to meet these requirements must be able to 309 compress packets containing IPSEC headers according to the IPSEC 310 requirement, 2.2.4. There may be other security aspects to consider 311 in such protocols. This document by itself, however, does not add 312 any security risks. 314 4. IANA Considerations 316 A protocol that meets these requirements will require the IANA to 317 assign various numbers. This document by itself, however, does not 318 require any IANA involvement. 320 5. Acknowledgments 322 This document has evolved through fruitful discussions with and input 323 from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West, 324 Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The 325 document quality was significantly improved thanks to Peter Eriksson, 326 who made a thorough linguistic review. 328 Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served 329 as committed working group document reviewers. 331 6. Authors' Address 333 Lars-Erik Jonsson Phone: +46 8 404 29 61 334 Ericsson AB Fax: +46 920 996 21 335 Box 920 336 SE-971 28 Lulea 337 Sweden EMail: lars-erik.jonsson@ericsson.com 339 7. Informative References 341 [1] Jon Postel, Internet Protocol, RFC 791, September 1981. 343 [2] Jon Postel, Transport Control Protocol, RFC 793, September 1981. 345 [3] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial 346 Links", RFC 1144, February 1990. 348 [4] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header 349 Compression", RFC 2507, February 1999. 351 [5] Mikael Degermark, "Requirements for IP/UDP/RTP header 352 compression", RFC 3096, July 2001. 354 [6] Carsten Bormann, et. al., "Robust Header Compression (ROHC)", 355 RFC 3095, July 2001. 357 [7] Van Jacobson, Bob Braden, Dave Borman, "TCP Extensions for High 358 Performance", RFC 1323, May 1992. 360 [8] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn Romanow, "TCP 361 Selective Acknowledgement Option", RFC 2018, October 1996. 363 [9] Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew Podolsky, "An 364 Extension to the Selective Acknowledgement (SACK) Option for 365 TCP", RFC 2883, July 2000. 367 [10] K. K. Ramakrishnan, Sally Floyd, David L. Black, "The Addition 368 of Explicit Congestion Notification (ECN) to IP", RFC 3168, 369 September 2001. 371 [11] Spencer Dawkins, Gabriel Montenegro, Markku Kojo, Vincent 372 Magret, "End-to-end Performance Implications of Slow Links", RFC 373 3150, July 2001. 375 [12] Gorry Fairhurst, Lloyd Wood, "Advice to link designers on link 376 Automatic Repeat reQuest (ARQ)", RFC 3366, August 2002. 378 Intellectual Property Statement 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the IETF's procedures with respect to rights in IETF Documents can 387 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at ietf- 400 ipr@ietf.org. 402 Copyright Statement 404 Copyright (C) The Internet Society (2004). This document is subject 405 to the rights, licenses and restrictions contained in BCP 78, and 406 except as set forth therein, the authors retain all their rights. 408 Disclaimer of Validity 410 This document and the information contained herein are provided on an 411 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 412 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 413 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 414 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 415 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 416 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 418 This Internet-Draft expires March 14, 2005.