draft-ietf-rohc-tcp-requirements-08.txt   rfc4163.txt 
Network Working Group L-E. Jonsson Network Working Group L-E. Jonsson
INTERNET-DRAFT Ericsson Request for Comments: 4163 Ericsson
Expires: March 2005 September 14, 2004 Category: Informational August 2005
Requirements on ROHC TCP/IP Header Compression
<draft-ietf-rohc-tcp-requirements-08.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 RObust Header Compression (ROHC):
Task Force (IETF), its areas, and its working groups. Note that other Requirements on TCP/IP Header Compression
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
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 This memo provides information for the Internet community. It does
http://www.ietf.org/ietf/lid-abstracts.txt not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html
This document is a submission of the IETF ROHC WG. Comments should be Copyright (C) The Internet Society (2005).
directed to the ROHC WG mailing list, rohc@ietf.org.
Abstract Abstract
This document contains requirements on the TCP/IP header compression This document contains requirements on the TCP/IP header compression
scheme (profile) to be developed by the ROHC WG. The document scheme (profile) to be developed by the RObust Header Compression
discusses the scope of TCP compression, performance considerations, (ROHC) Working Group. The document discusses the scope of TCP
assumptions on the surrounding environment, as well as IPR concerns. compression, performance considerations, assumptions about the
The structure of this document is inherited from the document surrounding environment, as well as Intellectual Property Rights
defining RTP/UDP/IP requirements [5] for ROHC. concerns. The structure of this document is inherited from RFC 3096,
which defines IP/UDP/RTP requirements for ROHC.
Table of Contents Table of Contents
1. Introduction.....................................................2 1. Introduction ....................................................2
2. Header Compression Requirements..................................2 2. Header Compression Requirements .................................2
2.1. Impact on Internet Infrastructure...........................3 2.1. Impact on Internet Infrastructure ..........................2
2.2. Supported Headers and Kinds of TCP Streams..................3 2.2. Supported Headers and Kinds of TCP Streams .................3
2.3. Performance Issues..........................................4 2.3. Performance Issues .........................................4
2.4. Requirements Related to Link Layer Characteristics..........6 2.4. Requirements Related to Link Layer Characteristics .........6
2.5. Intellectual Property Rights (IPR)..........................7 2.5. Intellectual Property Rights (IPR) .........................7
3. Security Consideration...........................................7 3. Security Consideration ..........................................7
4. IANA Considerations..............................................7 4. IANA Considerations .............................................7
5. Acknowledgments..................................................7 5. Acknowledgements ................................................7
6. Authors' Address.................................................7 6. Informative References ..........................................7
7. Informative References...........................................8
1. Introduction 1. Introduction
The goal of the ROHC WG is to develop header compression schemes that 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 perform well over links with high error rates and long link roundtrip
times. The schemes must perform well for cellular links, using times. The schemes must perform well for cellular links that use
technologies such as WCDMA, EDGE, and CDMA-2000. However, the schemes technologies such as Wideband Code Division Multiple Access (W-CDMA),
should also be applicable to other link technologies with high loss Enhanced Data rates for GSM Evolution (EDGE), and CDMA2000. However,
and long roundtrip times. the schemes should also be applicable to other link technologies with
high loss and long roundtrip times.
The main objective for ROHC has been robust compression of The main objective for ROHC has been robust compression of IP/UDP/RTP
IP/UDP/RTP, but the WG is also chartered to develop new header [5], but the WG is also chartered to develop new header compression
compression solutions for IP/TCP [1], [2]. Since TCP traffic, in solutions for IP/TCP [1], [2]. Because TCP traffic, in contrast to
contrast to RTP, has usually been sent over reliable links, existing RTP, has usually been sent over reliable links, existing schemes for
schemes for TCP, [3] and [4], have not experienced the same TCP, [3] and [4], have not experienced the same robustness problems
robustness problems as RTP compression. However, there are still many as RTP compression. However, there are still many scenarios where
scenarios where TCP header compression will be implemented over less TCP header compression will be implemented over less reliable links
reliable links [11], [12], making robustness an important objective [11], [12], making robustness an important objective for the new TCP
also for the new TCP compression scheme. Other, equally important, compression scheme. Other, equally important, objectives for ROHC
objectives for ROHC TCP compression are: improved compression TCP compression are: improved compression efficiency, enhanced
efficiency, enhanced capabilities for compression of header fields capabilities for compression of header fields including TCP options,
including TCP options, and finally incorporation of TCP compression and finally incorporation of TCP compression into the ROHC framework
into the ROHC framework [6]. [6].
2. Header Compression Requirements 2. Header Compression Requirements
The following requirements have, more or less arbitrarily, been The following requirements have, more or less arbitrarily, been
divided into five groups. The first group deals with requirements divided into five groups. The first group deals with requirements
concerning the impact of a header compression scheme on the rest of concerning the impact of a header compression scheme on the rest of
the Internet infrastructure. The second group defines what kind of the Internet infrastructure. The second group defines what kind of
headers must be compressed efficiently, while the third and fourth headers must be compressed efficiently. The third and fourth groups
groups concern performance requirements and capability requirements concern performance requirements and capability requirements that
that stem from the properties of link technologies where ROHC TCP is stem from the properties of link technologies where ROHC TCP is
expected to be used. Finally, the fifth section discusses expected to be used. Finally, the fifth section discusses
Intellectual Property Rights related to ROHC TCP compression. Intellectual Property Rights related to ROHC TCP compression.
2.1. Impact on Internet Infrastructure 2.1. Impact on Internet Infrastructure
1. Transparency: When a header is compressed and then decompressed, 1. Transparency: When a header is compressed and then decompressed,
the resulting header must be semantically identical to the the resulting header must be semantically identical to the
original header. If this cannot be achieved, the packet containing original header. If this cannot be achieved, the packet
the erroneous header must be discarded. containing the erroneous header must be discarded.
Justification: The header compression process must not produce Justification: The header compression process must not produce
headers that might cause problems for any current or future part headers that might cause problems for any current or future part
of the Internet infrastructure. of the Internet infrastructure.
Note: The ROHC WG has not found a case where "semantically Note: The ROHC WG has not found a case where "semantically
identical" is not the same as "bitwise identical". identical" is not the same as "bitwise identical".
2. Ubiquity: Must not require modifications to existing IP (v4 or 2. Ubiquity: Must not require modifications to existing IP (v4 or
v6) or TCP implementations. v6) or TCP implementations.
Justification: Ease of deployment. Justification: Ease of deployment.
Note: The ROHC WG may recommend changes that would increase the Note: The ROHC WG may recommend changes that would increase the
compression efficiency for the TCP streams emitted by compression efficiency for the TCP streams emitted by
implementations. However, ROHC cannot rely on such recommendations implementations. However, ROHC cannot assume such
being followed. recommendations will be followed.
Note: Several TCP variants are currently in use on the Internet. Note: Several TCP variants are currently in use on the Internet.
This requirement implies that the header compression scheme must This requirement implies that the header compression scheme must
work efficiently and correctly for all expected TCP variants. work efficiently and correctly for all expected TCP variants.
2.2. Supported Headers and Kinds of TCP Streams 2.2. Supported Headers and Kinds of TCP Streams
1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that 1. IPv4 and IPv6: Must support both IPv4 and IPv6. This means that
all expected changes in the IP header fields must be handled by all expected changes in the IP header fields must be handled by
the compression scheme, and commonly changing fields should be the compression scheme, and commonly changing fields should be
compressed efficiently. Compression must still be possible when compressed efficiently. Compression must still be possible when
IPv6 Extensions are present in the header. When designing the IPv6 Extensions are present in the header. When designing the
compression scheme, the usage of Explicit Congestion Notification compression scheme, the usage of Explicit Congestion Notification
(ECN) [10] should be considered as a common behavior. Therefore, (ECN) [10] should be considered as a common behavior. Therefore,
the scheme must compress efficiently also in the case when the ECN the scheme must also compress efficiently in the case when the
bits are used. ECN bits are used.
Justification: IPv4 and IPv6 will both be around for the Justification: IPv4 and IPv6 will both be around for the
foreseeable future, and Options/Extensions are expected to be more foreseeable future, and Options/Extensions are expected to be
commonly used. ECN is expected to have a breakthrough and be more commonly used. ECN is expected to have a breakthrough and
widely deployed, especially in combination with TCP. be widely deployed, especially in combination with TCP.
2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be 2. Mobile IP: The kinds of headers used by Mobile IP{v4,v6} must be
supported and should be compressed efficiently. For IPv4 these supported and should be compressed efficiently. For IPv4 these
include headers of tunneled packets. For IPv6 they include headers include headers of tunneled packets. For IPv6 they include
containing the Routing Header, and the Home Address Option. headers containing the Routing Header and the Home Address
Option.
Justification: It is very likely that Mobile IP will be used by Justification: It is very likely that Mobile IP will be used by
cellular devices. cellular devices.
3. Generality: Must handle all headers from arbitrary TCP streams. 3. Generality: Must handle all headers from arbitrary TCP streams.
Justification: There must be a generic scheme which can compress Justification: There must be a generic scheme that can compress
reasonably well for any TCP traffic pattern. This does not reasonably well for any TCP traffic pattern. This does not
preclude optimizations for certain traffic patterns. preclude optimizations for certain traffic patterns.
4. IPSEC: The scheme should be able to compress headers containing 4. IPSEC: The scheme should be able to compress headers containing
IPSEC sub-headers where the NULL encryption algorithm is used. IPSEC subheaders where the NULL encryption algorithm is used.
Justification: IPSEC is expected to be used to provide necessary Justification: IPSEC is expected to be used to provide necessary
end-to-end security. end-to-end security.
Note: It is not possible to compress the encrypted part of an ESP Note: It is not possible to compress the encrypted part of an ESP
header, nor the cryptographic data in an AH header. header, nor the cryptographic data in an AH header.
5. TCP: All fields supported by [4] should be handled with efficient 5. TCP: All fields supported by [4] should be handled with efficient
compression, and so also the cases when the SYN, FIN or TCP ECN compression, as should be the cases when the SYN, FIN or TCP ECN
[10] bits are set. [10] bits are set.
Justification: These bits are expected to be commonly used. Justification: These bits are expected to be commonly used.
6. TCP options: The scheme must support compression of packets with 6. TCP options: The scheme must support compression of packets with
any TCP option present, even if the option itself is not any TCP option present, even if the option itself is not
compressed. Further, for some commonly used options the scheme compressed. Further, for some commonly used options the scheme
should provide compression mechanisms also for the options. should also provide compression mechanisms for the options.
Justification: Since various TCP options are commonly used, Justification: Because various TCP options are commonly used,
applicability of the compression scheme would be significantly applicability of the compression scheme would be significantly
reduced if packets with options could not be compressed. reduced if packets with options could not be compressed.
Note: Options that should be compressed are: Note: Options that should be compressed are:
- Selective Acknowledgement (SACK), [8], [9] - Selective Acknowledgement (SACK), [8], [9]
- Timestamp, [7] - Timestamp, [7]
2.3. Performance Issues 2.3. Performance Issues
1. Performance/Spectral Efficiency: The scheme must provide low 1. Performance/Spectral Efficiency: The scheme must provide low
relative overhead under expected operating conditions; compression relative overhead under expected operating conditions;
efficiency should be better than for RFC 2507 [4] under equivalent compression efficiency should be better than for RFC 2507 [4]
operating conditions. under equivalent operating conditions.
Justification: Spectrum efficiency is a primary goal. Justification: Spectrum efficiency is a primary goal.
Note: The relative overhead is the average header overhead Note: The relative overhead is the average header overhead
relative to the payload. Any auxiliary (e.g., control or feedback) relative to the payload. Any auxiliary (e.g., control or
channels used by the scheme should be taken into account when feedback) channels used by the scheme should be taken into
calculating the header overhead. account when calculating the header overhead.
2. Losses between compressor and decompressor: The scheme should make 2. Losses between compressor and decompressor: The scheme should
sure losses between compressor and decompressor do not result in make sure losses between compressor and decompressor do not
losses of subsequent packets, or cause damage to the context that result in losses of subsequent packets, or cause damage to the
result in incorrect decompression of subsequent packet headers. context that results in incorrect decompression of subsequent
packet headers.
Justification: Even though link layer retransmission in most cases Justification: Even though link layer retransmission in most
is expected to almost eliminate losses between compressor and cases is expected to almost eliminate losses between compressor
decompressor, there are still many scenarios where TCP header and decompressor, there are still many scenarios where TCP header
compression will be implemented over less reliable links [11], compression will be implemented over less reliable links [11],
[12]. In such cases, loss propagation due to header compression [12]. In such cases, loss propagation due to header compression
could affect certain TCP mechanisms that are capable of handling could affect certain TCP mechanisms that are capable of handling
some losses, and have a negative impact on the performance of TCP some losses; loss propagation could also have a negative impact
loss recovery. on the performance of TCP loss recovery.
3. Residual errors in compressed headers: Residual errors in 3. Residual errors in compressed headers: Residual errors in
compressed headers may result in delivery of incorrectly compressed headers may result in delivery of incorrectly
decompressed headers not only for the damaged packet itself, but decompressed headers not only for the damaged packet itself, but
also for subsequent packets, since errors may be saved in the also for subsequent packets, because errors may be saved in the
context state. For TCP, the compression scheme is not required to context state. For TCP, the compression scheme is not required
implement explicit mechanisms for residual error detection, but to implement explicit mechanisms for residual error detection,
the compression scheme must not affect TCP's end-to-end mechanisms but the compression scheme must not affect TCP's end-to-end
for error detection. mechanisms for error detection.
Justification: For links carrying TCP traffic, the residual error Justification: For links carrying TCP traffic, the residual error
rate is expected to be insignificant. However, residual errors may rate is expected to be insignificant. However, residual errors
still occur, especially in the end-to-end path, and therefore it may still occur, especially in the end-to-end path. Therefore,
is crucial that TCP is not prevented from handling these. it is crucial that TCP is not prevented from handling these.
Note: This requirement implies that the TCP checksum must be Note: This requirement implies that the TCP checksum must be
carried unmodified in all compressed headers. carried unmodified in all compressed headers.
Note: The error detection mechanism in TCP may be able to detect Note: The error detection mechanism in TCP may be able to detect
residual bit errors, but the mechanism is not designed for this residual bit errors, but the mechanism is not designed for this
purpose, and might actually provide a rather weak protection. purpose, and might actually provide rather weak protection.
Therefore, although it is not a requirement on the compression Therefore, although it is not a requirement of the compression
scheme, it should be possible for the decompressor to detect scheme, it should be possible for the decompressor to detect
residual errors and discard such packets. residual errors and discard such packets.
4. Short-lived TCP transfers: The scheme should provide mechanisms 4. Short-lived TCP transfers: The scheme should provide mechanisms
for efficient compression of short-lived TCP transfers, minimizing for efficient compression of short-lived TCP transfers,
the size of context initiation headers. minimizing the size of context initiation headers.
Justification: Many TCP transfers are short-lived. This may lead Justification: Many TCP transfers are short-lived. This may lead
to a low gain for header compression schemes that, for each new to a low gain for header compression schemes that, for each new
packet stream, require full headers to be sent initially and allow packet stream, requires full headers to be sent initially and
small compressed headers only after the initialization phase. allows small compressed headers only after the initialization
phase.
Note: This requirement implies that mechanisms for building new Note: This requirement implies that mechanisms for building new
contexts based on information from previous contexts or for contexts that are based on information from previous contexts or
concurrent packet streams to share context information should be for concurrent packet streams to share context information should
considered. be considered.
5a. Moderate Packet Misordering: The scheme should efficiently handle 5a. Moderate Packet Misordering: The scheme should efficiently handle
moderate misordering (2-3 packets) in the packet stream reaching moderate misordering (2-3 packets) in the packet stream reaching
the compressor. the compressor.
Justification: This kind of misordering is common. Justification: This kind of misordering is common.
5b. Packet Misordering: The scheme must be able to correctly handle 5b. Packet Misordering: The scheme must be able to correctly handle
and preferably compress also when there are misordered packets in packet misordering and preferably compress when misordered
the TCP stream reaching the compressor. packets are in the TCP stream reaching the compressor.
Justification: Misordering happens regularly in the Internet. Justification: Misordering happens regularly in the Internet.
However, since the Internet is engineered to run TCP reasonably However, because the Internet is engineered to run TCP reasonably
well, excessive misordering will not be common and need not be well, excessive misordering will not be common and need not be
handled with optimum efficiency. handled with optimum efficiency.
6. Processing delay: The scheme should not contribute significantly 6. Processing delay: The scheme should not contribute significantly
to the system delay budget. to the system delay budget.
2.4. Requirements Related to Link Layer Characteristics 2.4. Requirements Related to Link Layer Characteristics
1. Unidirectional links: Must be possible to implement (possibly with 1. Unidirectional links: Must be possible to implement (possibly
less efficiency) without explicit feedback messages from with less efficiency) without explicit feedback messages from
decompressor to compressor. decompressor to compressor.
Justification: There are links that do not provide a feedback Justification: There are links that do not provide a feedback
channel or where feedback is not desirable for other reasons. channel or where feedback is not desirable for other reasons.
2. Link delay: Must operate under all expected link delay conditions. 2. Link delay: Must operate under all expected link delay
conditions.
3. Header compression coexistence: The scheme must fit into the ROHC 3. Header compression coexistence: The scheme must fit into the ROHC
framework together with other ROHC profiles (e.g. [6]). framework together with other ROHC profiles (e.g., [6]).
4. Note on misordering between compressor and decompressor: 4. Note on misordering between compressor and decompressor:
When compression is applied over tunnels, misordering often cannot When compression is applied over tunnels, misordering often
be completely avoided. The header compression scheme should not cannot be completely avoided. The header compression scheme
prohibit misordering between compressor and decompressor, as it should not prohibit misordering between compressor and
would therefore not be applicable in many tunneling scenarios. decompressor, as it would therefore not be applicable in many
However, in the case of tunneling, it is usually possible to get tunneling scenarios. However, in the case of tunneling, it is
misordering indications. Therefore, the compression scheme does usually possible to get misordering indications. Therefore, the
not have to support detection of misordering, but can assume that compression scheme does not have to support detection of
such information is available from lower layers when misordering misordering, but can assume that such information is available
can occur. from lower layers when misordering occurs.
2.5. Intellectual Property Rights (IPR) 2.5. Intellectual Property Rights (IPR)
The ROHC WG must spend effort to achieve a high degree of confidence The ROHC WG must spend effort to achieve a high degree of confidence
that there are no known IPR that covers a final compression solution that there are no known IPR claims that cover the final compression
for TCP. solution for TCP.
Justification: Currently there is no TCP header compression scheme Justification: Currently there is no TCP header compression scheme
available that can efficiently compress the packet headers of modern 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 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 providing a ROHC TCP scheme that is applicable in the wide area
Internet, not only over error-prone radio links. It must thus attempt Internet, not only over error-prone radio links. It must thus
to be as future-proof as possible, and only unencumbered solutions attempt to be as future-proof as possible, and only unencumbered
will be acceptable to the Internet at large. solutions, or solutions where the terms of any IPR are such that
there is no hindrance on implementation and deployment, will be
acceptable to the Internet at large.
3. Security Consideration 3. Security Consideration
A protocol specified to meet these requirements must be able to A protocol specified to meet these requirements must be able to
compress packets containing IPSEC headers according to the IPSEC compress packets containing IPSEC headers according to the IPSEC
requirement, 2.2.4. There may be other security aspects to consider requirement, 2.2.4. There may be other security aspects to consider
in such protocols. This document by itself, however, does not add in such protocols. This document by itself, however, does not add
any security risks. any security risks.
4. IANA Considerations 4. IANA Considerations
A protocol that meets these requirements will require the IANA to A protocol that meets these requirements will require the IANA to
assign various numbers. This document by itself, however, does not assign various numbers. This document by itself, however, does not
require any IANA involvement. require any IANA involvement.
5. Acknowledgments 5. Acknowledgements
This document has evolved through fruitful discussions with and input This document has evolved through fruitful discussions with and input
from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West, from Gorry Fairhurst, Carsten Bormann, Mikael Degermark, Mark West,
Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The Jan Kullander, Qian Zhang, Richard Price, and Aaron Falk. The
document quality was significantly improved thanks to Peter Eriksson, document quality was significantly improved thanks to Peter Eriksson,
who made a thorough linguistic review. who made a thorough linguistic review.
Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served Last, but not least, Ghyslain Pelletier and Kristofer Sandlund served
as committed working group document reviewers. as committed working group document reviewers.
6. Authors' Address 6. Informative References
Lars-Erik Jonsson Phone: +46 8 404 29 61
Ericsson AB Fax: +46 920 996 21
Box 920
SE-971 28 Lulea
Sweden EMail: lars-erik.jonsson@ericsson.com
7. Informative References
[1] Jon Postel, Internet Protocol, RFC 791, September 1981. [1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Jon Postel, Transport Control Protocol, RFC 793, September 1981. [2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[3] Van Jacobson, "Compressing TCP/IP Headers for Low-Speed Serial [3] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
Links", RFC 1144, February 1990. links", RFC 1144, February 1990.
[4] Mikael Degermark, Bjorn Nordgren, Stephen Pink, "IP Header [4] Degermark, M., Nordgren, B., and S. Pink, "IP Header
Compression", RFC 2507, February 1999. Compression", RFC 2507, February 1999.
[5] Mikael Degermark, "Requirements for IP/UDP/RTP header [5] Degermark, M., "Requirements for robust IP/UDP/RTP header
compression", RFC 3096, July 2001. compression", RFC 3096, July 2001.
[6] Carsten Bormann, et. al., "Robust Header Compression (ROHC)", [6] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H.,
Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu,
Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T.,
Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC):
Framework and four profiles: RTP, UDP, ESP, and uncompressed",
RFC 3095, July 2001. RFC 3095, July 2001.
[7] Van Jacobson, Bob Braden, Dave Borman, "TCP Extensions for High [7] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for
Performance", RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[8] Matt Mathis, Jamshid Mahdavi, Sally Floyd, Allyn Romanow, "TCP [8] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgement Option", RFC 2018, October 1996. Selective Acknowledgement Options", RFC 2018, October 1996.
[9] Sally Floyd, Jamshid Mahdavi, Matt Mathis, Matthew Podolsky, "An [9] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
Extension to the Selective Acknowledgement (SACK) Option for Extension to the Selective Acknowledgement (SACK) Option for
TCP", RFC 2883, July 2000. TCP", RFC 2883, July 2000.
[10] K. K. Ramakrishnan, Sally Floyd, David L. Black, "The Addition [10] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
of Explicit Congestion Notification (ECN) to IP", RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001. September 2001.
[11] Spencer Dawkins, Gabriel Montenegro, Markku Kojo, Vincent [11] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, "End-to-
Magret, "End-to-end Performance Implications of Slow Links", RFC end Performance Implications of Slow Links", BCP 48, RFC 3150,
3150, July 2001. July 2001.
[12] Gorry Fairhurst, Lloyd Wood, "Advice to link designers on link [12] Fairhurst, G. and L. Wood, "Advice to link designers on link
Automatic Repeat reQuest (ARQ)", RFC 3366, August 2002. Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, August 2002.
Intellectual Property Statement Author's Address
Lars-Erik Jonsson
Ericsson AB
Box 920
SE-971 28 Lulea
Sweden
Phone: +46 8 404 29 61
Fax: +46 920 996 21
EMail: lars-erik.jonsson@ericsson.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Acknowledgement
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.
This Internet-Draft expires March 14, 2005. Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 90 change blocks. 
278 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/