diff options
Diffstat (limited to 'doc/rfc/rfc2414.txt')
| -rw-r--r-- | doc/rfc/rfc2414.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc2414.txt b/doc/rfc/rfc2414.txt new file mode 100644 index 0000000..9ee9895 --- /dev/null +++ b/doc/rfc/rfc2414.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group M. Allman +Request for Comments: 2414 NASA Lewis/Sterling Software +Category: Experimental S. Floyd + LBNL + C. Partridge + BBN Technologies + September 1998 + + + Increasing TCP's Initial Window + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document specifies an increase in the permitted initial window + for TCP from one segment to roughly 4K bytes. This document + discusses the advantages and disadvantages of such a change, + outlining experimental results that indicate the costs and benefits + of such a change to TCP. + +Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1. TCP Modification + + This document specifies an increase in the permitted upper bound for + TCP's initial window from one segment to between two and four + segments. In most cases, this change results in an upper bound on + the initial window of roughly 4K bytes (although given a large + segment size, the permitted initial window of two segments could be + significantly larger than 4K bytes). The upper bound for the initial + window is given more precisely in (1): + + min (4*MSS, max (2*MSS, 4380 bytes)) (1) + + + + +Allman, et. al. Experimental [Page 1] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + Equivalently, the upper bound for the initial window size is based on + the maximum segment size (MSS), as follows: + + If (MSS <= 1095 bytes) + then win <= 4 * MSS; + If (1095 bytes < MSS < 2190 bytes) + then win <= 4380; + If (2190 bytes <= MSS) + then win <= 2 * MSS; + + This increased initial window is optional: that a TCP MAY start with + a larger initial window, not that it SHOULD. + + This upper bound for the initial window size represents a change from + RFC 2001 [S97], which specifies that the congestion window be + initialized to one segment. If implementation experience proves + successful, then the intent is for this change to be incorporated + into a revision to RFC 2001. + + This change applies to the initial window of the connection in the + first round trip time (RTT) of transmission following the TCP three- + way handshake. Neither the SYN/ACK nor its acknowledgment (ACK) in + the three-way handshake should increase the initial window size above + that outlined in equation (1). If the SYN or SYN/ACK is lost, the + initial window used by a sender after a correctly transmitted SYN + MUST be one segment. + + TCP implementations use slow start in as many as three different + ways: (1) to start a new connection (the initial window); (2) to + restart a transmission after a long idle period (the restart window); + and (3) to restart after a retransmit timeout (the loss window). The + change proposed in this document affects the value of the initial + window. Optionally, a TCP MAY set the restart window to the minimum + of the value used for the initial window and the current value of + cwnd (in other words, using a larger value for the restart window + should never increase the size of cwnd). These changes do NOT change + the loss window, which must remain 1 segment (to permit the lowest + possible window size in the case of severe congestion). + +2. Implementation Issues + + When larger initial windows are implemented along with Path MTU + Discovery [MD90], and the MSS being used is found to be too large, + the congestion window `cwnd' SHOULD be reduced to prevent large + bursts of smaller segments. Specifically, `cwnd' SHOULD be reduced + by the ratio of the old segment size to the new segment size. + + + + + +Allman, et. al. Experimental [Page 2] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + When larger initial windows are implemented along with Path MTU + Discovery [MD90], alternatives are to set the "Don't Fragment" (DF) + bit in all segments in the initial window, or to set the "Don't + Fragment" (DF) bit in one of the segments. It is an open question + which of these two alternatives is best; we would hope that + implementation experiences will shed light on this. In the first + case of setting the DF bit in all segments, if the initial packets + are too large, then all of the initial packets will be dropped in the + network. In the second case of setting the DF bit in only one + segment, if the initial packets are too large, then all but one of + the initial packets will be fragmented in the network. When the + second case is followed, setting the DF bit in the last segment in + the initial window provides the least chance for needless + retransmissions when the initial segment size is found to be too + large, because it minimizes the chances of duplicate ACKs triggering + a Fast Retransmit. However, more attention needs to be paid to the + interaction between larger initial windows and Path MTU Discovery. + + The larger initial window proposed in this document is not intended + as an encouragement for web browsers to open multiple simultaneous + TCP connections all with large initial windows. When web browsers + open simultaneous TCP connections to the same destination, this works + against TCP's congestion control mechanisms [FF98], regardless of the + size of the initial window. Combining this behavior with larger + initial windows further increases the unfairness to other traffic in + the network. + +3. Advantages of Larger Initial Windows + + 1. When the initial window is one segment, a receiver employing + delayed ACKs [Bra89] is forced to wait for a timeout before + generating an ACK. With an initial window of at least two + segments, the receiver will generate an ACK after the second data + segment arrives. This eliminates the wait on the timeout (often + up to 200 msec). + + 2. For connections transmitting only a small amount of data, a + larger initial window reduces the transmission time (assuming at + most moderate segment drop rates). For many email (SMTP [Pos82]) + and web page (HTTP [BLFN96, FJGFBL97]) transfers that are less + than 4K bytes, the larger initial window would reduce the data + transfer time to a single RTT. + + 3. For connections that will be able to use large congestion + windows, this modification eliminates up to three RTTs and a + delayed ACK timeout during the initial slow-start phase. This + + + + + +Allman, et. al. Experimental [Page 3] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + would be of particular benefit for high-bandwidth large- + propagation-delay TCP connections, such as those over satellite + links. + +4. Disadvantages of Larger Initial Windows for the Individual + Connection + + In high-congestion environments, particularly for routers that have a + bias against bursty traffic (as in the typical Drop Tail router + queues), a TCP connection can sometimes be better off starting with + an initial window of one segment. There are scenarios where a TCP + connection slow-starting from an initial window of one segment might + not have segments dropped, while a TCP connection starting with an + initial window of four segments might experience unnecessary + retransmits due to the inability of the router to handle small + bursts. This could result in an unnecessary retransmit timeout. For + a large-window connection that is able to recover without a + retransmit timeout, this could result in an unnecessarily-early + transition from the slow-start to the congestion-avoidance phase of + the window increase algorithm. These premature segment drops are + unlikely to occur in uncongested networks with sufficient buffering + or in moderately-congested networks where the congested router uses + active queue management (such as Random Early Detection [FJ93, + RFC2309]). + + Some TCP connections will receive better performance with the higher + initial window even if the burstiness of the initial window results + in premature segment drops. This will be true if (1) the TCP + connection recovers from the segment drop without a retransmit + timeout, and (2) the TCP connection is ultimately limited to a small + congestion window by either network congestion or by the receiver's + advertised window. + +5. Disadvantages of Larger Initial Windows for the Network + + In terms of the potential for congestion collapse, we consider two + separate potential dangers for the network. The first danger would + be a scenario where a large number of segments on congested links + were duplicate segments that had already been received at the + receiver. The second danger would be a scenario where a large number + of segments on congested links were segments that would be dropped + later in the network before reaching their final destination. + + In terms of the negative effect on other traffic in the network, a + potential disadvantage of larger initial windows would be that they + increase the general packet drop rate in the network. We discuss + these three issues below. + + + + +Allman, et. al. Experimental [Page 4] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + Duplicate segments: + + As described in the previous section, the larger initial window + could occasionally result in a segment dropped from the initial + window, when that segment might not have been dropped if the + sender had slow-started from an initial window of one segment. + However, Appendix A shows that even in this case, the larger + initial window would not result in the transmission of a large + number of duplicate segments. + + Segments dropped later in the network: + + How much would the larger initial window for TCP increase the + number of segments on congested links that would be dropped + before reaching their final destination? This is a problem that + can only occur for connections with multiple congested links, + where some segments might use scarce bandwidth on the first + congested link along the path, only to be dropped later along the + path. + + First, many of the TCP connections will have only one congested + link along the path. Segments dropped from these connections do + not "waste" scarce bandwidth, and do not contribute to congestion + collapse. + + However, some network paths will have multiple congested links, + and segments dropped from the initial window could use scarce + bandwidth along the earlier congested links before ultimately + being dropped on subsequent congested links. To the extent that + the drop rate is independent of the initial window used by TCP + segments, the problem of congested links carrying segments that + will be dropped before reaching their destination will be similar + for TCP connections that start by sending four segments or one + segment. + + An increased packet drop rate: + + For a network with a high segment drop rate, increasing the TCP + initial window could increase the segment drop rate even further. + This is in part because routers with Drop Tail queue management + have difficulties with bursty traffic in times of congestion. + However, given uncorrelated arrivals for TCP connections, the + larger TCP initial window should not significantly increase the + segment drop rate. Simulation-based explorations of these issues + are discussed in Section 7.2. + + + + + + +Allman, et. al. Experimental [Page 5] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + These potential dangers for the network are explored in simulations + and experiments described in the section below. Our judgement would + be, while there are dangers of congestion collapse in the current + Internet (see [FF98] for a discussion of the dangers of congestion + collapse from an increased deployment of UDP connections without + end-to-end congestion control), there is no such danger to the + network from increasing the TCP initial window to 4K bytes. + +6. Typical Levels of Burstiness for TCP Traffic. + + Larger TCP initial windows would not dramatically increase the + burstiness of TCP traffic in the Internet today, because such traffic + is already fairly bursty. Bursts of two and three segments are + already typical of TCP [Flo97]; A delayed ACK (covering two + previously unacknowledged segments) received during congestion + avoidance causes the congestion window to slide and two segments to + be sent. The same delayed ACK received during slow start causes the + window to slide by two segments and then be incremented by one + segment, resulting in a three-segment burst. While not necessarily + typical, bursts of four and five segments for TCP are not rare. + Assuming delayed ACKs, a single dropped ACK causes the subsequent ACK + to cover four previously unacknowledged segments. During congestion + avoidance this leads to a four-segment burst and during slow start a + five-segment burst is generated. + + There are also changes in progress that reduce the performance + problems posed by moderate traffic bursts. One such change is the + deployment of higher-speed links in some parts of the network, where + a burst of 4K bytes can represent a small quantity of data. A second + change, for routers with sufficient buffering, is the deployment of + queue management mechanisms such as RED, which is designed to be + tolerant of transient traffic bursts. + +7. Simulations and Experimental Results + +7.1 Studies of TCP Connections using that Larger Initial Window + + This section surveys simulations and experiments that have been used + to explore the effect of larger initial windows on the TCP connection + using that larger window. The first set of experiments explores + performance over satellite links. Larger initial windows have been + shown to improve performance of TCP connections over satellite + channels [All97b]. In this study, an initial window of four segments + (512 byte MSS) resulted in throughput improvements of up to 30% + (depending upon transfer size). [KAGT98] shows that the use of + larger initial windows results in a decrease in transfer time in HTTP + tests over the ACTS satellite system. A study involving simulations + + + + +Allman, et. al. Experimental [Page 6] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + of a large number of HTTP transactions over hybrid fiber coax (HFC) + indicates that the use of larger initial windows decreases the time + required to load WWW pages [Nic97]. + + A second set of experiments has explored TCP performance over dialup + modem links. In experiments over a 28.8 bps dialup channel [All97a, + AHO98], a four-segment initial window decreased the transfer time of + a 16KB file by roughly 10%, with no accompanying increase in the drop + rate. A particular area of concern has been TCP performance over low + speed tail circuits (e.g., dialup modem links) with routers with + small buffers. A simulation study [SP97] investigated the effects of + using a larger initial window on a host connected by a slow modem + link and a router with a 3 packet buffer. The study concluded that + for the scenario investigated, the use of larger initial windows was + not harmful to TCP performance. Questions have been raised + concerning the effects of larger initial windows on the transfer time + for short transfers in this environment, but these effects have not + been quantified. A question has also been raised concerning the + possible effect on existing TCP connections sharing the link. + +7.2 Studies of Networks using Larger Initial Windows + + This section surveys simulations and experiments investigating the + impact of the larger window on other TCP connections sharing the + path. Experiments in [All97a, AHO98] show that for 16 KB transfers + to 100 Internet hosts, four-segment initial windows resulted in a + small increase in the drop rate of 0.04 segments/transfer. While the + drop rate increased slightly, the transfer time was reduced by + roughly 25% for transfers using the four-segment (512 byte MSS) + initial window when compared to an initial window of one segment. + + One scenario of concern is heavily loaded links. For instance, a + couple of years ago, one of the trans-Atlantic links was so heavily + loaded that the correct congestion window size for a connection was + about one segment. In this environment, new connections using larger + initial windows would be starting with windows that were four times + too big. What would the effects be? Do connections thrash? + + A simulation study in [PN98] explores the impact of a larger initial + window on competing network traffic. In this investigation, HTTP and + FTP flows share a single congested gateway (where the number of HTTP + and FTP flows varies from one simulation set to another). For each + simulation set, the paper examines aggregate link utilization and + packet drop rates, median web page delay, and network power for the + FTP transfers. The larger initial window generally resulted in + increased throughput, slightly-increased packet drop rates, and an + increase in overall network power. With the exception of one + scenario, the larger initial window resulted in an increase in the + + + +Allman, et. al. Experimental [Page 7] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + drop rate of less than 1% above the loss rate experienced when using + a one-segment initial window; in this scenario, the drop rate + increased from 3.5% with one-segment initial windows, to 4.5% with + four-segment initial windows. The overall conclusions were that + increasing the TCP initial window to three packets (or 4380 bytes) + helps to improve perceived performance. + + Morris [Mor97] investigated larger initial windows in a very + congested network with transfers of size 20K. The loss rate in + networks where all TCP connections use an initial window of four + segments is shown to be 1-2% greater than in a network where all + connections use an initial window of one segment. This relationship + held in scenarios where the loss rates with one-segment initial + windows ranged from 1% to 11%. In addition, in networks where + connections used an initial window of four segments, TCP connections + spent more time waiting for the retransmit timer (RTO) to expire to + resend a segment than was spent when using an initial window of one + segment. The time spent waiting for the RTO timer to expire + represents idle time when no useful work was being accomplished for + that connection. These results show that in a very congested + environment, where each connection's share of the bottleneck + bandwidth is close to one segment, using a larger initial window can + cause a perceptible increase in both loss rates and retransmit + timeouts. + +8. Security Considerations + + This document discusses the initial congestion window permitted for + TCP connections. Changing this value does not raise any known new + security issues with TCP. + +9. Conclusion + + This document proposes a small change to TCP that may be beneficial + to short-lived TCP connections and those over links with long RTTs + (saving several RTTs during the initial slow-start phase). + +10. Acknowledgments + + We would like to acknowledge Vern Paxson, Tim Shepard, members of the + End-to-End-Interest Mailing List, and members of the IETF TCP + Implementation Working Group for continuing discussions of these + issues for discussions and feedback on this document. + + + + + + + + +Allman, et. al. Experimental [Page 8] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + +11. References + + [All97a] Mark Allman. An Evaluation of TCP with Larger Initial + Windows. 40th IETF Meeting -- TCP Implementations WG. + December, 1997. Washington, DC. + + [AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An + Evaluation of TCP with Larger Initial Windows, March + 1998. Submitted to ACM Computer Communication Review. + URL: "http://gigahertz.lerc.nasa.gov/~mallman/papers/ + initwin.ps". + + [All97b] Mark Allman. Improving TCP Performance Over Satellite + Channels. Master's thesis, Ohio University, June 1997. + + [BLFN96] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext + Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. + + [Bra89] Braden, R., "Requirements for Internet Hosts -- + Communication Layers", STD 3, RFC 1122, October 1989. + + [FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of + Tahoe, Reno, and SACK TCP. Computer Communication + Review, 26(3), July 1996. + + [FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End + Congestion Control in the Internet. Submitted to IEEE + Transactions on Networking. URL "http://www- + nrg.ee.lbl.gov/floyd/end2end-paper.html". + + [FJGFBL97] Fielding, R., Mogul, J., Gettys, J., Frystyk, H., and T. + Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", + RFC 2068, January 1997. + + [FJ93] Floyd, S., and Jacobson, V., Random Early Detection + gateways for Congestion Avoidance. IEEE/ACM Transactions + on Networking, V.1 N.4, August 1993, p. 397-413. + + [Flo94] Floyd, S., TCP and Explicit Congestion Notification. + Computer Communication Review, 24(5):10-23, October 1994. + + [Flo96] Floyd, S., Issues of TCP with SACK. Technical report, + January 1996. Available from http://www- + nrg.ee.lbl.gov/floyd/. + + [Flo97] Floyd, S., Increasing TCP's Initial Window. Viewgraphs, + 40th IETF Meeting - TCP Implementations WG. December, + 1997. URL "ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps". + + + +Allman, et. al. Experimental [Page 9] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + [KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP + Page Transfer Rates Over Geo-Stationary Satellite Links. + March 1998. Proceedings of the Sixth International + Conference on Telecommunication Systems. URL + "http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps". + + [MD90] Mogul, J., and S. Deering, "Path MTU Discovery", RFC + 1191, November 1990. + + [MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, October + 1996. + + [Mor97] Robert Morris. Private communication, 1997. Cited for + acknowledgement purposes only. + + [Nic97] Kathleen Nichols. Improving Network Simulation with + Feedback. Com21, Inc. Technical Report. Available from + http://www.com21.com/pages/papers/068.pdf. + + [PN98] Poduri, K., and K. Nichols, "Simulation Studies of + Increased Initial TCP Window Size", RFC 2415, September + 1998. + + [Pos82] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, August 1982. + + [RF97] Ramakrishnan, K., and S. Floyd, "A Proposal to Add + Explicit Congestion Notification (ECN) to IPv6 and to + TCP", Work in Progress. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, + S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., + Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, + S., Wroclawski, J., and L. Zhang, "Recommendations on + Queue Management and Congestion Avoidance in the + Internet", RFC 2309, April 1998. + + [S97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast + Retransmit, and Fast Recovery Algorithms", RFC 2001, + January 1997. + + [SP97] Shepard, T., and C. Partridge, "When TCP Starts Up With + Four Packets Into Only Three Buffers", RFC 2416, + September 1998. + + + +Allman, et. al. Experimental [Page 10] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + +12. Author's Addresses + + Mark Allman + NASA Lewis Research Center/Sterling Software + 21000 Brookpark Road + MS 54-2 + Cleveland, OH 44135 + + EMail: mallman@lerc.nasa.gov + http://gigahertz.lerc.nasa.gov/~mallman/ + + + Sally Floyd + Lawrence Berkeley National Laboratory + One Cyclotron Road + Berkeley, CA 94720 + + EMail: floyd@ee.lbl.gov + + + Craig Partridge + BBN Technologies + 10 Moulton Street + Cambridge, MA 02138 + + EMail: craig@bbn.com + + + + + + + + + + + + + + + + + + + + + + + + + +Allman, et. al. Experimental [Page 11] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + +13. Appendix - Duplicate Segments + + In the current environment (without Explicit Congestion Notification + [Flo94] [RF97]), all TCPs use segment drops as indications from the + network about the limits of available bandwidth. We argue here that + the change to a larger initial window should not result in the sender + retransmitting a large number of duplicate segments that have already + been received at the receiver. + + If one segment is dropped from the initial window, there are three + different ways for TCP to recover: (1) Slow-starting from a window of + one segment, as is done after a retransmit timeout, or after Fast + Retransmit in Tahoe TCP; (2) Fast Recovery without selective + acknowledgments (SACK), as is done after three duplicate ACKs in Reno + TCP; and (3) Fast Recovery with SACK, for TCP where both the sender + and the receiver support the SACK option [MMFR96]. In all three + cases, if a single segment is dropped from the initial window, no + duplicate segments (i.e., segments that have already been received at + the receiver) are transmitted. Note that for a TCP sending four + 512-byte segments in the initial window, a single segment drop will + not require a retransmit timeout, but can be recovered from using the + Fast Retransmit algorithm (unless the retransmit timer expires + prematurely). In addition, a single segment dropped from an initial + window of three segments might be repaired using the fast retransmit + algorithm, depending on which segment is dropped and whether or not + delayed ACKs are used. For example, dropping the first segment of a + three segment initial window will always require waiting for a + timeout. However, dropping the third segment will always allow + recovery via the fast retransmit algorithm, as long as no ACKs are + lost. + + Next we consider scenarios where the initial window contains two to + four segments, and at least two of those segments are dropped. If + all segments in the initial window are dropped, then clearly no + duplicate segments are retransmitted, as the receiver has not yet + received any segments. (It is still a possibility that these dropped + segments used scarce bandwidth on the way to their drop point; this + issue was discussed in Section 5.) + + When two segments are dropped from an initial window of three + segments, the sender will only send a duplicate segment if the first + two of the three segments were dropped, and the sender does not + receive a packet with the SACK option acknowledging the third + segment. + + When two segments are dropped from an initial window of four + segments, an examination of the six possible scenarios (which we + don't go through here) shows that, depending on the position of the + + + +Allman, et. al. Experimental [Page 12] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + + dropped packets, in the absence of SACK the sender might send one + duplicate segment. There are no scenarios in which the sender sends + two duplicate segments. + + When three segments are dropped from an initial window of four + segments, then, in the absence of SACK, it is possible that one + duplicate segment will be sent, depending on the position of the + dropped segments. + + The summary is that in the absence of SACK, there are some scenarios + with multiple segment drops from the initial window where one + duplicate segment will be transmitted. There are no scenarios where + more that one duplicate segment will be transmitted. Our conclusion + is that the number of duplicate segments transmitted as a result of a + larger initial window should be small. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allman, et. al. Experimental [Page 13] + +RFC 2414 Increasing TCP's Initial Window September 1998 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (1998). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Allman, et. al. Experimental [Page 14] + |