Network Working Group M. Allman
Request for Comments: 3390 BBN/NASA GRC
Obsoletes: 2414 S. Floyd
Updates: 2581 ICIR
Category: Standards Track C. Partridge
BBN Technologies
October 2002
Network Working Group M. Allman
Request for Comments: 3390 BBN/NASA GRC
Obsoletes: 2414 S. Floyd
Updates: 2581 ICIR
Category: Standards Track C. Partridge
BBN Technologies
October 2002
Increasing TCP's Initial Window
增加TCP的初始窗口
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document specifies an optional standard for TCP to increase the permitted initial window from one or two segment(s) to roughly 4K bytes, replacing RFC 2414. It discusses the advantages and disadvantages of the higher initial window, and includes discussion of experiments and simulations showing that the higher initial window does not lead to congestion collapse. Finally, this document provides guidance on implementation issues.
本文档为TCP指定了一个可选标准，将允许的初始窗口从一个或两个段增加到大约4K字节，以取代RFC 2414。它讨论了较高初始窗口的优缺点，并包括实验和模拟的讨论，表明较高初始窗口不会导致拥塞崩溃。最后，本文件就实施问题提供了指导。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document obsoletes [RFC2414] and updates [RFC2581] and specifies an increase in the permitted upper bound for TCP's initial window from one or two segment(s) 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 may be significantly larger than 4K bytes).
本文件淘汰[RFC2414]并更新[RFC2581]，并规定将TCP初始窗口的允许上限从一个或两个段增加到两个至四个段之间。在大多数情况下，此更改导致初始窗口的上限约为4K字节（尽管给定了较大的段大小，但允许的两个段的初始窗口可能明显大于4K字节）。
The upper bound for the initial window is given more precisely in (1):
初始窗口的上限在（1）中给出得更精确：
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
最小值（4*MSS，最大值（2*MSS，4380字节））（1）
Note: Sending a 1500 byte packet indicates a maximum segment size (MSS) of 1460 bytes (assuming no IP or TCP options). Therefore, limiting the initial window's MSS to 4380 bytes allows the sender to transmit three segments initially in the common case when using 1500 byte packets.
注意：发送1500字节的数据包表示最大段大小（MSS）为1460字节（假设没有IP或TCP选项）。因此，当使用1500字节的数据包时，将初始窗口的MSS限制在4380字节允许发送方在常见情况下最初传输三个段。
Equivalently, the upper bound for the initial window size is based on the MSS, as follows:
等效地，初始窗口大小的上限基于MSS，如下所示：
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;
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: a TCP MAY start with a larger initial window. However, we expect that most general-purpose TCP implementations would choose to use the larger initial congestion window given in equation (1) above.
此增加的初始窗口是可选的：TCP可以从较大的初始窗口开始。然而，我们期望大多数通用TCP实现会选择使用上面等式（1）中给出的较大初始拥塞窗口。
This upper bound for the initial window size represents a change from RFC 2581 [RFC2581], which specified that the congestion window be initialized to one or two segments.
初始窗口大小的上限表示RFC 2581[RFC2581]的变化，RFC 2581[RFC2581]指定将拥塞窗口初始化为一个或两个段。
This change applies to the initial window of the connection in the first round trip time (RTT) of data 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 consisting of MSS bytes.
此更改适用于TCP三方握手后数据传输的第一次往返时间（RTT）中连接的初始窗口。三向握手中的SYN/ACK及其确认（ACK）都不应将初始窗口大小增加到方程（1）中所述的大小以上。如果SYN或SYN/ACK丢失，发送方在正确传输SYN后使用的初始窗口必须是一个由MSS字节组成的段。
TCP implementations use slow start in as many as three different ways: (1) to start a new connection (the initial window); (2) to restart transmission after a long idle period (the restart window); and (3) to restart transmission after a retransmit timeout (the loss window). The change specified 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 of MSS bytes (to
TCP实现使用慢启动的方式多达三种：（1）启动新连接（初始窗口）；（2） 长时间闲置后重新启动变速箱（重新启动窗口）；以及（3）在重新传输超时（丢失窗口）后重新启动传输。此文档中指定的更改会影响初始窗口的值。或者，TCP可以将重新启动窗口设置为初始窗口使用的值和cwnd的当前值中的最小值（换句话说，为重新启动窗口使用较大的值不应增加cwnd的大小）。这些更改不会更改丢失窗口，丢失窗口必须保留1段MSS字节（到
permit the lowest possible window size in the case of severe congestion).
在严重拥挤的情况下，允许最小的窗口大小）。
When larger initial windows are implemented along with Path MTU Discovery [RFC1191], 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.
当较大的初始窗口与路径MTU发现[RFC1191]一起实施时，并且发现所使用的MSS太大，则应减少拥塞窗口“cwnd”，以防止较小段的大突发。具体而言，“cwnd”应按旧段大小与新段大小的比率减少。
When larger initial windows are implemented along with Path MTU Discovery [RFC1191], 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 as to which of these two alternatives is best; we would hope that implementation experiences will shed light on this question. 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.
当较大的初始窗口与路径MTU发现[RFC1191]一起实施时，替代方法是在初始窗口的所有段中设置“不分段”（DF）位，或在其中一段中设置“不分段”（DF）位。这两个选择中哪一个是最好的，这是一个悬而未决的问题；我们希望，执行经验将阐明这一问题。在第一种情况下，在所有段中设置DF位，如果初始数据包太大，则所有初始数据包将在网络中丢弃。在仅在一个段中设置DF位的第二种情况下，如果初始数据包太大，则除了一个初始数据包之外，所有初始数据包都将在网络中被分段。当遵循第二种情况时，在初始窗口的最后一个段中设置DF位，当发现初始段大小太大时，提供不必要的重新传输的机会最小，因为它将重复ACK触发快速重新传输的机会降至最低。然而，需要更多地关注较大初始窗口和路径MTU发现之间的交互。
The larger initial window specified in this document is not intended as 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, they are working against TCP's congestion control mechanisms [FF99], 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. We suggest the use of HTTP/1.1 [RFC2068] (persistent TCP connections and pipelining) as a way to achieve better performance of web transfers.
本文档中指定的较大初始窗口并不鼓励web浏览器同时打开多个TCP连接，所有连接都具有较大的初始窗口。当web浏览器同时打开到同一目的地的TCP连接时，无论初始窗口大小如何，它们都在对抗TCP的拥塞控制机制[FF99]。将此行为与较大的初始窗口相结合，会进一步增加对网络中其他流量的不公平性。我们建议使用HTTP/1.1[RFC2068]（持久TCP连接和管道）作为实现更好的web传输性能的方法。
1. When the initial window is one segment, a receiver employing delayed ACKs [RFC1122] 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, and possibly up to 500 msec [RFC1122]).
1. 当初始窗口为一个段时，采用延迟ACK[RFC1122]的接收器在生成ACK之前被迫等待超时。对于至少两个段的初始窗口，接收器将在第二个数据段到达后生成ACK。这消除了超时等待（通常高达200毫秒，可能高达500毫秒[RFC1122]）。
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 [RFC1945, RFC2068]) transfers that are less than 4K bytes, the larger initial window would reduce the data transfer time to a single RTT.
2. 对于仅传输少量数据的连接，较大的初始窗口会缩短传输时间（假设段丢失率最多为中等）。对于许多小于4K字节的电子邮件（SMTP[Pos82]）和网页（HTTP[RFC1945，RFC2068]）传输，较大的初始窗口会将数据传输时间缩短到单个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 will be of particular benefit for high-bandwidth large-propagation-delay TCP connections, such as those over satellite links.
3. 对于能够使用大拥塞窗口的连接，此修改在初始慢速启动阶段消除了多达三个RTT和延迟的ACK超时。这对于高带宽、大传播延迟的TCP连接尤其有利，例如通过卫星链路的TCP连接。
4. Disadvantages of Larger Initial Windows for the Individual Connection
4. 单个连接的初始窗口较大的缺点
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]).
在高拥塞环境中，尤其是对突发流量有偏见的路由器（如典型的掉尾路由器队列），TCP连接有时最好从一个段的初始窗口开始。在某些情况下，从一个段的初始窗口开始的TCP连接速度较慢，可能不会丢弃段，而从四个段的初始窗口开始的TCP连接可能会由于路由器无法处理小突发而经历不必要的重新传输。这可能会导致不必要的重新传输超时。对于能够在无需重新传输超时的情况下恢复的大窗口连接，这可能会导致不必要的提前过渡，从窗口增加算法的慢速启动过渡到拥塞避免阶段。这些过早的段丢失不太可能发生在具有足够缓冲的未阻塞网络中，或者在拥塞路由器使用主动队列管理（例如随机早期检测[FJ93，RFC2309]）的中度拥塞网络中。
Some TCP connections will receive better performance with the larger 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.
一些TCP连接在较大的初始窗口中会获得更好的性能，即使初始窗口的突发性会导致过早的段丢失。如果（1）TCP连接在没有重新传输超时的情况下从段丢失中恢复，并且（2）TCP连接最终被网络拥塞或接收器的播发窗口限制在一个小的拥塞窗口内，则这将是正确的。
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.
就对网络中其他流量的负面影响而言，较大初始窗口的一个潜在缺点是它们会增加网络中的一般分组丢弃率。我们将在下面讨论这三个问题。
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.
如前一节所述，较大的初始窗口偶尔会导致从初始窗口中删除段，如果发送方从一个段的初始窗口缓慢启动，则该段可能不会被删除。然而，附录A显示，即使在这种情况下，较大的初始窗口也不会导致大量重复段的传输。
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.
TCP的初始窗口越大，拥塞链路上在到达最终目的地之前丢弃的段数会增加多少？这是一个仅在具有多个拥塞链路的连接中才会出现的问题，其中一些网段可能在路径上的第一个拥塞链路上使用稀缺带宽，但随后会在路径上丢弃。
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.
首先，许多TCP连接在路径上只有一个拥塞的链路。从这些连接断开的网段不会“浪费”稀缺的带宽，也不会导致拥塞崩溃。
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.
然而，一些网络路径将有多个拥塞链路，从初始窗口丢弃的段可能会使用早期拥塞链路上的稀缺带宽，然后最终在后续拥塞链路上丢弃。由于丢包率与TCP段使用的初始窗口无关，拥塞链路承载的段在到达目的地之前将被丢包的问题对于发送四个段或一个段开始的TCP连接类似。
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.
对于具有高段丢弃率的网络，增加TCP初始窗口可能会进一步增加段丢弃率。这部分是因为具有掉尾队列管理的路由器在拥塞时难以处理突发流量。然而，考虑到TCP连接的不相关到达，较大的TCP初始窗口不应显著增加段丢失率。第7.2节讨论了这些问题的模拟探索。
These potential dangers for the network are explored in simulations and experiments described in the section below. Our judgment is that while there are dangers of congestion collapse in the current Internet (see [FF99] 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.
这些网络的潜在危险将在以下部分描述的模拟和实验中探讨。我们的判断是，虽然当前互联网存在拥塞崩溃的危险（有关在没有端到端拥塞控制的情况下增加部署UDP连接导致拥塞崩溃的危险的讨论，请参见[FF99]），但将TCP初始窗口增加到4K字节对网络没有这种危险。
Using a larger initial burst of data can exacerbate existing problems with spurious retransmit timeouts on low-bandwidth paths, assuming the standard algorithm for determining the TCP retransmission timeout (RTO) [RFC2988]. The problem is that across low-bandwidth network paths on which the transmission time of a packet is a large portion of the round-trip time, the small packets used to establish a TCP connection do not seed the RTO estimator appropriately. When the first window of data packets is transmitted, the sender's retransmit timer could expire before the acknowledgments for those packets are received. As each acknowledgment arrives, the retransmit timer is generally reset. Thus, the retransmit timer will not expire as long as an acknowledgment arrives at least once a second, given the one-second minimum on the RTO recommended in RFC 2988.
假设采用确定TCP重传超时（RTO）的标准算法，使用较大的初始数据突发会加剧低带宽路径上存在的伪重传超时问题[RFC2988]。问题在于，在数据包传输时间占往返时间很大一部分的低带宽网络路径上，用于建立TCP连接的小数据包没有适当地为RTO估计器播种。当数据包的第一个窗口被传输时，发送方的重传计时器可能在接收到这些包的确认之前过期。当每次确认到达时，通常会重置重传计时器。因此，只要确认至少每秒到达一次，那么重传计时器就不会过期，因为RFC 2988中推荐的RTO上的最小值为1秒。
For instance, consider a 9.6 Kbps link. The initial RTT measurement will be on the order of 67 msec, if we simply consider the transmission time of 2 packets (the SYN and SYN-ACK), each consisting of 40 bytes. Using the RTO estimator given in [RFC2988], this yields an initial RTO of 201 msec (67 + 4*(67/2)). However, we round the RTO to 1 second as specified in RFC 2988. Then assume we send an initial window of one or more 1500-byte packets (1460 data bytes plus overhead). Each packet will take on the order of 1.25 seconds to transmit. Therefore, the RTO will fire before the ACK for the first packet returns, causing a spurious timeout. In this case, a larger initial window of three or four packets exacerbates the problems caused by this spurious timeout.
例如，考虑一个9.6 kbps的链接。如果我们简单地考虑2个分组（SYN和SYN-ACK）的传输时间，每个初始的RTT测量将是67毫秒的顺序，每个都由40个字节组成。使用[RFC2988]中给出的RTO估计器，这将产生201毫秒（67+4*（67/2））的初始RTO。但是，我们将RTO四舍五入到RFC 2988中规定的1秒。然后假设我们发送一个或多个1500字节数据包的初始窗口（1460个数据字节加上开销）。每个数据包的传输时间约为1.25秒。因此，RTO将在第一个数据包的ACK返回之前触发，从而导致虚假超时。在这种情况下，三个或四个数据包的较大初始窗口会加剧这种虚假超时所导致的问题。
One way to deal with this problem is to make the RTO algorithm more conservative. During the initial window of data, for instance, the RTO could be updated for each acknowledgment received. In addition, if the retransmit timer expires for some packet lost in the first window of data, we could leave the exponential-backoff of the retransmit timer engaged until at least one valid RTT measurement, that involves a data packet, is received.
解决这个问题的一种方法是使RTO算法更加保守。例如，在数据的初始窗口期间，可以针对接收到的每个确认更新RTO。此外，如果在第一个数据窗口中丢失的某些数据包的重传计时器过期，我们可以保持重传计时器的指数退避，直到接收到至少一个涉及数据包的有效RTT测量。
Another method would be to refrain from taking an RTT sample during connection establishment, leaving the default RTO in place until TCP takes a sample from a data segment and the corresponding ACK. While this method likely helps prevent spurious retransmits, it also may slow the data transfer down if loss occurs before the RTO is seeded. The use of limited transmit [RFC3042] to aid a TCP connection in recovering from loss using fast retransmit rather than the RTO timer mitigates the performance degradation caused by using the high default RTO during the initial window of data transmission.
另一种方法是在连接建立期间避免采集RTT样本，保留默认RTO，直到TCP从数据段和相应的ACK中采集样本。虽然此方法可能有助于防止虚假的重新传输，但如果在RTO播种之前发生丢失，也可能会降低数据传输速度。使用有限传输[RFC3042]来帮助TCP连接使用快速重传（而不是RTO计时器）从丢失中恢复，可以缓解在数据传输的初始窗口期间使用高默认RTO造成的性能下降。
This specification leaves the decision about what to do (if anything) with regards to the RTO, when using a larger initial window, to the implementer. However, the RECOMMENDED approach is to refrain from sampling the RTT during the three-way handshake, keeping the default RTO in place until an RTT sample involving a data packet is taken. In addition, it is RECOMMENDED that TCPs use limited transmit [RFC3042].
当使用较大的初始窗口时，该规范将RTO的相关操作（如果有）留给实现者决定。然而，推荐的方法是避免在三方握手期间对RTT进行采样，保持默认RTO在适当的位置，直到获取涉及数据分组的RTT采样。此外，建议TCP使用有限传输[RFC3042]。
7. Typical Levels of Burstiness for TCP Traffic.
7. TCP流量的典型突发性级别。
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.
较大的TCP初始窗口不会显著增加当前Internet中TCP流量的突发性，因为此类流量已经相当突发。两段和三段的突发已经是TCP的典型特征[Flo97]；在拥塞避免期间接收到的延迟确认（覆盖两个以前未确认的段）会导致拥塞窗口滑动并发送两个段。慢速启动期间接收到的相同延迟ACK会导致窗口滑动两段，然后增加一段，从而导致三段突发。虽然不一定是典型的，但TCP的四段和五段突发并不罕见。假设延迟确认，单个丢弃的确认将导致后续确认覆盖四个先前未确认的段。在避免拥塞期间，这将导致四段突发，而在慢速启动期间，将生成五段突发。
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
还有一些正在进行中的更改，可以减少由中等流量突发造成的性能问题。其中一个变化是在网络的某些部分部署了高速链路，其中4K字节的突发可以表示少量数据。对于具有足够缓冲的路由器，第二个变化是部署
queue management mechanisms such as RED, which is designed to be tolerant of transient traffic bursts.
队列管理机制，如RED，其设计用于容忍瞬时流量突发。
This section surveys simulations and experiments that explore the effect of larger initial windows on TCP connections. The first set of experiments explores performance over satellite links. Larger initial windows have been shown to improve the 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 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 [Nic98].
本节介绍了探索较大初始窗口对TCP连接影响的模拟和实验。第一组实验探索了卫星链路的性能。较大的初始窗口可以提高卫星信道上TCP连接的性能[All97b]。在这项研究中，四个段（512字节MSS）的初始窗口导致吞吐量提高高达30%（取决于传输大小）。[KAGT98]表明，使用较大的初始窗口会减少ACTS卫星系统HTTP测试的传输时间。一项涉及通过混合光纤同轴电缆（HFC）模拟大量HTTP事务的研究表明，使用较大的初始窗口可以减少加载WWW页面所需的时间[Nic98]。
A second set of experiments 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 simulation study [RFC2416] 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.
第二组实验探索了拨号调制解调器链路上的TCP性能。在一个28.8 bps的拨号通道[All97a，AHO98]上进行的实验中，四段初始窗口将16KB文件的传输时间减少了约10%，而丢弃率没有随之增加。一项模拟研究[RFC2416]调查了在通过低速调制解调器链路连接的主机和具有3个数据包缓冲区的路由器上使用较大初始窗口的影响。该研究得出结论，对于所研究的场景，使用较大的初始窗口不会对TCP性能造成损害。
Finally, [All00] illustrates that the percentage of connections at a particular web server that experience loss in the initial window of data transmission increases with the size of the initial congestion window. However, the increase is in line with what would be expected from sending a larger burst into the network.
最后，[All00]说明了特定web服务器上在数据传输的初始窗口中丢失的连接的百分比随着初始拥塞窗口的大小而增加。然而，这一增长与向网络发送更大突发的预期相符。
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.
本节将介绍模拟和实验，研究较大窗口对共享路径的其他TCP连接的影响。[All97a，AHO98]中的实验表明，对于100台Internet主机的16 KB传输，四段初始窗口导致0.04段/传输的下降率略有增加。虽然下降率略有增加，但与一个段的初始窗口相比，使用四段（512字节MSS）初始窗口的传输时间减少了约25%。
A simulation study in [RFC2415] 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 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.
[RFC2415]中的模拟研究探讨了较大初始窗口对竞争网络流量的影响。在本研究中，HTTP和FTP流共享一个拥塞网关（其中HTTP和FTP流的数量因模拟集而异）。对于每个模拟集，本文检查FTP传输的聚合链路利用率和丢包率、中间网页延迟和网络功率。较大的初始窗口通常会增加吞吐量，略微增加丢包率，并增加总体网络功率。除一种情况外，较大的初始窗口导致下降率比使用单段初始窗口时的损失率增加不到1%；在这种情况下，下降率从单段初始窗口的3.5%增加到四段初始窗口的4.5%。总体结论是，将TCP初始窗口增加到三个数据包（或4380字节）有助于提高感知性能。
Morris [Mor97] investigated larger initial windows in a highly congested network with transfers of 20K in size. 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 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.
Morris[Mor97]研究了一个高度拥挤的网络中较大的初始窗口，传输量为20K。所有TCP连接使用四段初始窗口的网络中的丢失率比所有连接使用一段初始窗口的网络中的丢失率高1-2%。这种关系在损失率为1%至11%的情况下保持不变。此外，在连接使用四个段的初始窗口的网络中，TCP连接等待重传计时器（RTO）过期以重新发送段的时间比使用一个段的初始窗口所花费的时间要长。等待RTO计时器过期所花费的时间表示没有为该连接完成任何有用工作时的空闲时间。这些结果表明，在非常拥挤的环境中，每个连接的瓶颈带宽份额接近一个网段，使用较大的初始窗口会导致丢失率和重传超时明显增加。
This document discusses the initial congestion window permitted for TCP connections. Changing this value does not raise any known new security issues with TCP.
本文档讨论TCP连接允许的初始拥塞窗口。更改此值不会导致TCP出现任何已知的新安全问题。
This document specifies a small change to TCP that will likely be beneficial to short-lived TCP connections and those over links with long RTTs (saving several RTTs during the initial slow-start phase).
本文档指定了对TCP的一个小更改，这可能有助于短寿命TCP连接和长RTT链路上的TCP连接（在初始慢启动阶段节省几个RTT）。
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 and for feedback on this document.
我们感谢Vern Paxson、Tim Shepard、端到端兴趣邮件列表的成员以及IETF TCP实施工作组的成员继续讨论这些问题，并就本文件提供反馈。
[AHO98] Mark Allman, Chris Hayes, and Shawn Ostermann, An Evaluation of TCP with Larger Initial Windows, March 1998. ACM Computer Communication Review, 28(3), July 1998. URL "http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps".
[AHO98]Mark Allman、Chris Hayes和Shawn Ostermann，对初始窗口较大的TCP的评估，1998年3月。ACM计算机通信评论，28（3），1998年7月。URL“http://roland.lerc.nasa.gov/~mallman/papers/initwin.ps”。
[All97a] Mark Allman. An Evaluation of TCP with Larger Initial Windows. 40th IETF Meeting -- TCP Implementations WG. December, 1997. Washington, DC.
马克·奥尔曼。具有较大初始窗口的TCP评估。第40次IETF会议——TCP实施工作组。1997年12月。华盛顿特区。
[All97b] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
马克·奥尔曼。提高卫星信道上的TCP性能。俄亥俄大学硕士论文，1997年6月。
[All00] Mark Allman. A Web Server's View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000.
马克·奥尔曼。Web服务器的传输层视图。ACM计算机通信评论，30（5），2000年10月。
[FF96] Fall, K., and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, 26(3), July 1996.
[FF96]Fall，K.，和Floyd，S.，基于模拟的塔霍、雷诺和SACK TCP比较。《计算机通信评论》，26（3），1996年7月。
[FF99] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. IEEE/ACM Transactions on Networking, August 1999. URL "http://www.icir.org/floyd/end2end-paper.html".
萨莉·弗洛伊德，凯文·法尔。促进互联网端到端拥塞控制的使用。IEEE/ACM网络交易，1999年8月。URL“http://www.icir.org/floyd/end2end-paper.html".
[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.
[FJ93]Floyd，S.，和Jacobson，V.，用于避免拥塞的随机早期检测网关。IEEE/ACM网络交易，第1节第4节，1993年8月，第页。397-413.
[Flo94] Floyd, S., TCP and Explicit Congestion Notification. Computer Communication Review, 24(5):10-23, October 1994.
[Flo94]Floyd，S.，TCP和显式拥塞通知。《计算机通信评论》，24（5）：1994年10月10日至23日。
[Flo96] Floyd, S., Issues of TCP with SACK. Technical report, January 1996. Available from http://www-nrg.ee.lbl.gov/floyd/.
[Flo96]Floyd，S.，关于TCP与SACK的问题。技术报告，1996年1月。可从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".
[Flo97]Floyd，S.，增加TCP的初始窗口。Viewgraphs，第40届IETF会议-TCP实施工作组。1997年12月。URL“ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps".
[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://roland.lerc.nasa.gov/~mallman/papers/nash98.ps".
[KAGT98]汉斯·克鲁斯，马克·奥尔曼，吉姆·格林纳，陈迪普奇。地球静止卫星链路上的HTTP页面传输速率。1998年3月。第六届国际电信系统会议记录。URL“http://roland.lerc.nasa.gov/~mallman/papers/nash98.ps”。
[Mor97] Robert Morris. Private communication, 1997. Cited for acknowledgement purposes only.
罗伯特·莫里斯。私人通信，1997年。引用仅供确认之用。
[Nic98] Kathleen Nichols. Improving Network Simulation With Feedback, Proceedings of LCN 98, October 1998. URL "http://www.computer.org/proceedings/lcn/8810/8810toc.htm".
[Nic98]凯瑟琳·尼科尔斯。用反馈改进网络模拟，LCN98会议录，1998年10月。URL“http://www.computer.org/proceedings/lcn/8810/8810toc.htm".
[Pos82] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[Pos82]Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[RFC1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求——通信层”，标准3，RFC 1122，1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1945] Berners-Lee, T., Fielding, R. and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]Berners Lee，T.，Fielding，R.和H.Nielsen，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[RFC2068] Fielding, R., Mogul, J., Gettys, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, January 1997.
[RFC2068]菲尔丁，R.，莫卧儿，J.，盖蒂斯，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[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.和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[RFC2414] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[RFC2414]奥尔曼，M.，弗洛伊德，S.和C.帕特里奇，“增加TCP的初始窗口”，RFC2414141998年9月。
[RFC2415] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[RFC2415]Poduri，K.和K.Nichols，“增加初始TCP窗口大小的模拟研究”，RFC 2415，1998年9月。
[RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[RFC2416]Shepard，T.和C.Partridge，“当TCP启动时，只有四个数据包进入三个缓冲区”，RFC 2416，1998年9月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]Allman，M.，Balakrishnan，H.和S.Floyd，“使用有限传输增强TCP的丢失恢复”，RFC 3042，2001年1月。
[RFC3168] Ramakrishnan, K.K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.K.，Floyd，S.和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
Appendix A - Duplicate Segments
附录A-重复段
In the current environment (without Explicit Congestion Notification [Flo94] [RFC2481]), 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 arrived at the receiver.
在当前环境中（没有明确的拥塞通知[Flo94][RFC2481]），所有TCP使用段丢弃作为来自网络的可用带宽限制指示。我们在此认为，对较大初始窗口的更改不应导致发送方重新传输大量已经到达接收方的重复段。
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 by 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, in the absence of Limited Transmit [RFC3042]. However, dropping the third segment will always allow recovery via the fast retransmit algorithm, as long as no ACKs are lost.
如果从初始窗口中删除一个段，TCP有三种不同的恢复方式：（1）从一个段的窗口缓慢启动，就像在重新传输超时后或在Tahoe TCP中快速重新传输后所做的那样；（2） 快速恢复，无需选择性确认（SACK），就像在Reno TCP中重复三次确认后所做的那样；（3）对于TCP，使用SACK进行快速恢复，其中发送方和接收方都支持SACK选项[MMFR96]。在所有三种情况下，如果从初始窗口删除单个段，则不会发送重复段（即，已在接收器处接收到的段）。请注意，对于在初始窗口中发送四个512字节段的TCP，单个段删除不需要重新传输超时，但可以通过使用快速重新传输算法进行恢复（除非重新传输计时器提前过期）。此外，根据丢弃的段以及是否使用延迟ack，可以使用快速重传算法修复从三个段的初始窗口丢弃的单个段。例如，在没有限制传输的情况下，删除三段初始窗口的第一段始终需要等待超时[RFC3042]。但是，只要没有ACK丢失，丢弃第三段将始终允许通过快速重传算法进行恢复。
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.)
接下来，我们考虑初始窗口包含两个到四个段的场景，并且至少两个片段被丢弃。如果删除了初始窗口中的所有段，那么显然不会重新传输重复的段，因为接收机尚未接收到任何段。（这些被丢弃的网段仍有可能在到达它们的丢弃点的途中使用了稀缺的带宽；第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.
当从包含三个段的初始窗口中删除两个段时，如果删除了三个段中的前两个段，则发送方只会发送一个重复段，并且发送方不会收到SACK选项确认第三个段的数据包。
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
当从一个包含四个片段的初始窗口中删除两个片段时，对六种可能的场景（我们在这里不讨论）的检查表明，这取决于片段的位置
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.
丢弃的数据包，在没有SACK的情况下，发送方可能会发送一个重复的数据段。不存在发送方发送两个重复段的情况。
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.
当从包含四个段的初始窗口中删除三个段时，在没有SACK的情况下，可能会发送一个重复段，具体取决于删除段的位置。
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 in which more than one duplicate segment will be transmitted. Our conclusion is than the number of duplicate segments transmitted as a result of a larger initial window should be small.
总结是，在没有SACK的情况下，存在一些场景，在初始窗口中有多个段丢弃，其中一个重复段将被传输。不存在传输多个重复段的情况。我们的结论是，由于较大的初始窗口而传输的重复段的数量应较小。
Author's Addresses
作者地址
Mark Allman
BBN Technologies/NASA Glenn Research Center
21000 Brookpark Rd
MS 54-5
Cleveland, OH 44135
EMail: mallman@bbn.com
http://roland.lerc.nasa.gov/~mallman/
Mark Allman
BBN Technologies/NASA Glenn Research Center
21000 Brookpark Rd
MS 54-5
Cleveland, OH 44135
EMail: mallman@bbn.com
http://roland.lerc.nasa.gov/~mallman/
Sally Floyd
ICSI Center for Internet Research
1947 Center St, Suite 600
Berkeley, CA 94704
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
http://www.icir.org/floyd/
Sally Floyd
ICSI Center for Internet Research
1947 Center St, Suite 600
Berkeley, CA 94704
Phone: +1 (510) 666-2989
EMail: floyd@icir.org
http://www.icir.org/floyd/
Craig Partridge BBN Technologies 10 Moulton St Cambridge, MA 02138 EMail: craig@bbn.com
Craig Partridge BBN Technologies 10 Moulton St Cambridge，MA 02138电子邮件：craig@bbn.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。