Network Working Group T. Shepard
Request for Comments: 2416 C. Partridge
Category: Informational BBN Technologies
September 1998
Network Working Group T. Shepard
Request for Comments: 2416 C. Partridge
Category: Informational BBN Technologies
September 1998
When TCP Starts Up With Four Packets Into Only Three Buffers
当TCP启动时，只有四个数据包进入三个缓冲区
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
This memo is to document a simple experiment. The experiment showed that in the case of a TCP receiver behind a 9600 bps modem link at the edge of a fast Internet where there are only 3 buffers before the modem (and the fourth packet of a four-packet start will surely be dropped), no significant degradation in performance is experienced by a TCP sending with a four-packet start when compared with a normal slow start (which starts with just one packet).
这份备忘录记录了一个简单的实验。实验表明，在高速互联网边缘的9600 bps调制解调器链路后面的TCP接收器的情况下，在调制解调器之前只有3个缓冲区（四个数据包启动的第四个数据包肯定会被丢弃），与正常的慢启动（仅从一个数据包开始）相比，TCP发送以四个数据包开始时，性能没有明显下降。
Background
出身背景
Sally Floyd has proposed that TCPs start their initial slow start by sending as many as four packets (instead of the usual one packet) as a means of getting TCP up-to-speed faster. (Slow starts instigated due to timeouts would still start with just one packet.) Starting with more than one packet might reduce the start-up latency over long-fat pipes by two round-trip times. This proposal is documented further in [1], [2], and in [3] and we assume the reader is familiar with the details of this proposal.
Sally Floyd建议TCP通过发送多达四个数据包（而不是通常的一个数据包）来启动其初始慢速启动，以此作为加快TCP速度的一种手段。（由于超时而导致的缓慢启动仍将仅从一个数据包开始。）从多个数据包开始可能会将长fat管道上的启动延迟减少两个往返时间。该提案在[1]、[2]和[3]中有进一步的记录，我们假设读者熟悉该提案的细节。
On the end2end-interest mailing list, concern was raised that in the (allegedly common) case where a slow modem is served by a router which only allocates three buffers per modem (one buffer being transmitted while two packets are waiting), that starting with four packets would not be good because the fourth packet is sure to be dropped.
在End2 End interest邮件列表上，有人提出了这样的担忧：在（据称很常见的）一种情况下，一个较慢的调制解调器由一个路由器提供服务，该路由器在每个调制解调器上只分配三个缓冲区（一个缓冲区在两个数据包等待时传输），以四个数据包开始并不好，因为第四个数据包肯定会被丢弃。
Vern Paxson replied with the comment (among other things) that the four-packet start is no worse than what happens after two round trip times in normal slow start, hence no new problem is introduced by starting with as many as four packets. If there is a problem with a four-packet start, then the problem already exists in a normal slow-start startup after two round trip times when the slow-start algorithm will release into the net four closely spaced packets.
Vern Paxson回复说（除其他事项外），四个数据包的启动并不比正常慢启动时两次往返时间后的情况差，因此从四个数据包开始不会带来新问题。如果四个数据包启动存在问题，则在两次往返时间后，当慢启动算法将四个紧密间隔的数据包释放到网络中时，正常慢启动启动中已经存在问题。
The experiment reported here confirmed Vern Paxson's reasoning.
这里报道的实验证实了弗恩·帕克森的推理。
Scenario and experimental setup
场景和实验设置
+--------+ 100 Mbps +---+ 1.5 Mbps +---+ 9600 bps +----------+
| source +------------+ R +-------------+ R +--------------+ receiver |
+--------+ no delay +---+ 25 ms delay +---+ 150 ms delay +----------+
+--------+ 100 Mbps +---+ 1.5 Mbps +---+ 9600 bps +----------+
| source +------------+ R +-------------+ R +--------------+ receiver |
+--------+ no delay +---+ 25 ms delay +---+ 150 ms delay +----------+
| |
| |
(we spy here) (this router has only 3 buffers
to hold packets going into the
9600 bps link)
| |
| |
(we spy here) (this router has only 3 buffers
to hold packets going into the
9600 bps link)
The scenario studied and simulated consists of three links between the source and sink. The first link is a 100 Mbps link with no delay. It connects the sender to a router. (It was included to have a means of logging the returning ACKs at the time they would be seen by the sender.) The second link is a 1.5 Mbps link with a 25 ms one-way delay. (This link was included to roughly model traversing an un-congested, intra-continental piece of the terrestrial Internet.) The third link is a 9600 bps link with a 150 ms one-way delay. It connects the edge of the net to a receiver which is behind the 9600 bps link.
研究和模拟的情景包括源和汇之间的三个环节。第一条链路是没有延迟的100 Mbps链路。它将发送者连接到路由器。（包括它是为了在发送方看到返回的ack时记录它们。）第二条链路是1.5 Mbps链路，单向延迟为25 ms。（包括该链路是为了大致模拟穿越一个不拥挤的大陆内部陆地互联网）第三条链路是一条9600 bps的链路，单向延迟为150 ms。它将网络边缘连接到9600 bps链路后面的接收器。
The queue limits for the queues at each end of the first two links were set to 100 (a value sufficiently large that this limit was never a factor). The queue limits at each end of the 9600 bps link were set to 3 packets (which can hold at most two packets while one is being sent).
前两条链路两端队列的队列限制设置为100（一个足够大的值，该限制永远不是一个因素）。9600 bps链路两端的队列限制设置为3个数据包（其中一个数据包在发送时最多可容纳两个数据包）。
Version 1.2a2 of the the NS simulator (available from LBL) was used to simulate both one-packet and four-packet starts for each of the available TCP algorithms (tahoe, reno, sack, fack) and the conclusion reported here is independent of which TCP algorithm is used (in general, we believe). In this memo, the "tahoe" module will be used to illustrate what happens. In the 4-packet start cases, the "window-init" variable was set to 4, and the TCP implementations were modified to use the value of the window-init variable only on
NS模拟器的1.2a2版（可从LBL获得）用于模拟每个可用TCP算法（tahoe、reno、sack、fack）的一个数据包和四个数据包启动，此处报告的结论与使用的TCP算法无关（通常，我们认为）。在本备忘录中，“tahoe”模块将用于说明发生了什么。在4包启动的情况下，“window init”变量被设置为4，TCP实现被修改为仅在上使用window init变量的值
connection start, but to set cwnd to 1 on other instances of a slow-start. (The tcp.cc module as shipped with ns-1.2a2 would use the window-init value in all cases.)
连接开始，但在缓慢启动的其他实例上将cwnd设置为1。（ns-1.2a2附带的tcp.cc模块在所有情况下都将使用window init值。）
The packets in simulation are 1024 bytes long for purposes of determining the time it takes to transmit them through the links. (The TCP modules included with the LBL NS simulator do not simulate the TCP sequence number mechanisms. They use just packet numbers.)
模拟中的数据包长度为1024字节，用于确定通过链路传输数据包所需的时间。（LBL NS模拟器附带的TCP模块不模拟TCP序列号机制。它们只使用数据包号。）
Observations are made of all packets and acknowledgements crossing the 100 Mbps no-delay link, near the sender. (All descriptions below are from this point of view.)
通过发送方附近100 Mbps无延迟链路对所有数据包和确认进行观察。（以下所有描述都是从这个角度出发的。）
What happens with normal slow start
正常慢速启动会发生什么
At time 0.0 packet number 1 is sent.
在发送0.0数据包编号1时。
At time 1.222 an ack is received covering packet number 1, and packets 2 and 3 are sent.
在时间1.222，接收到覆盖包号1的ack，并且发送包2和3。
At time 2.444 an ack is received covering packet number 2, and packets 4 and 5 are sent.
在时间2.444，接收到覆盖分组编号2的ack，并且发送分组4和5。
At time 3.278 an ack is received covering packet number 3, and packets 6 and 7 are sent.
在时间3.278，接收到覆盖包编号3的ack，并发送包6和7。
At time 4.111 an ack is received covering packet number 4, and packets 8 and 9 are sent.
在时间4.111，接收到覆盖分组编号4的ack，并且发送分组8和9。
At time 4.944 an ack is received covering packet number 5, and packets 10 and 11 are sent.
在时间4.944，接收到覆盖分组编号5的ack，并且发送分组10和11。
At time 5.778 an ack is received covering packet number 6, and packets 12 and 13 are sent.
在时间5.778，接收到覆盖包号6的ack，并且发送包12和13。
At time 6.111 a duplicate ack is recieved (covering packet number 6).
在时间6.111，接收到重复的ack（覆盖包号6）。
At time 7.444 another duplicate ack is received (covering packet number 6).
在时间7.444，接收到另一个重复的ack（覆盖包号6）。
At time 8.278 a third duplicate ack is received (covering packet number 6) and packet number 7 is retransmitted.
在时间8.278，接收到第三个重复ack（覆盖包号6），包号7被重新传输。
(And the trace continues...)
（追踪还在继续…）
What happens with a four-packet start
四包启动会发生什么
At time 0.0, packets 1, 2, 3, and 4 are sent.
在时间0.0，发送包1、2、3和4。
At time 1.222 an ack is received covering packet number 1, and packets 5 and 6 are sent.
在时间1.222，接收到覆盖分组编号1的ack，并且发送分组5和6。
At time 2.055 an ack is received covering packet number 2, and packets 7 and 8 are sent.
在时间2.055，接收到覆盖数据包编号2的ack，并且发送数据包7和8。
At time 2.889 an ack is received covering packet number 3, and packets 9 and 10 are sent.
在时间2.889，接收到覆盖包编号3的ack，并发送包9和包10。
At time 3.722 a duplicate ack is received (covering packet number 3).
在时间3.722，接收到重复的ack（覆盖包编号3）。
At time 4.555 another duplicate ack is received (covering packet number 3).
在时间4.555，接收到另一个重复的ack（覆盖包号3）。
At time 5.389 a third duplicate ack is received (covering packet number 3) and packet number 4 is retransmitted.
在时间5.389，接收到第三个重复ack（覆盖包号3），包号4被重新传输。
(And the trace continues...)
（追踪还在继续…）
Discussion
讨论
At the point left off in the two traces above, the two different systems are in almost identical states. The two traces from that point on are almost the same, modulo a shift in time of (8.278 - 5.389) = 2.889 seconds and a shift of three packets. If the normal TCP (with the one-packet start) will deliver packet N at time T, then the TCP with the four-packet start will deliver packet N - 3 at time T - 2.889 (seconds).
在上面两条记录道中留下的点处，两个不同的系统处于几乎相同的状态。从该点开始的两条记录道几乎相同，模时间偏移（8.278-5.389）=2.889秒，以及三个数据包的偏移。如果正常TCP（具有一个数据包开始）将在时间T传递数据包N，那么具有四个数据包开始的TCP将在时间T-2.889（秒）传递数据包N-3。
Note that the time to send three 1024-byte TCP segments through a 9600 bps modem is 2.66 seconds. So at what time does the four-packet-start TCP deliver packet N? At time T - 2.889 + 2.66 = T - 0.229 in most cases, and in some cases earlier, in some cases later, because different packets (by number) experience loss in the two traces.
请注意，通过9600 bps调制解调器发送三个1024字节TCP段的时间为2.66秒。那么，四个数据包在什么时候开始TCP发送数据包N？在大多数情况下，时间T-2.889+2.66=T-0.229，在某些情况下更早，在某些情况下更晚，因为不同的数据包（按数量）在两条记录道中经历丢失。
Thus the four-packet-start TCP is in some sense 0.229 seconds (or about one fifth of a packet) ahead of where the one-packet-start TCP would be. (This is due to the extra time the modem sits idle while waiting for the dally timer to go off in the receiver in the case of the one-packet-start TCP.)
因此，从某种意义上讲，四包起始TCP比一包起始TCP提前0.229秒（或大约五分之一个包）。（这是由于在单数据包启动TCP的情况下，调制解调器在等待接收器中的dally定时器关闭时有额外的空闲时间。）
The states of the two systems are not exactly identical. They differ slightly in the round-trip-time estimators because the behavior at the start is not identical. (The observed round trip times may differ by a small amount due to dally timers and due to that the one-packet start experiences more round trip times before the first loss.) In the cases where a retransmit timer did later go off, the additional
这两个系统的状态并不完全相同。它们在往返时间估计值上略有不同，因为开始时的行为并不相同。（由于dally定时器以及由于一个数据包开始在第一次丢失之前经历了更多的往返时间，观察到的往返时间可能会略有不同。）在重传定时器后来确实关闭的情况下，额外的
difference in timing was much smaller than the 0.229 second difference discribed above.
时间上的差异远小于上面描述的0.229秒的差异。
Conclusion
结论
In this particular case, the four-packet start is not harmful.
在这种特殊情况下，四个数据包的启动是无害的。
Non-conclusions, opinions, and future work
非结论、意见和未来工作
A four-packet start would be very helpful in situations where a long-delay link is involved (as it would reduce transfer times for moderately-sized transfers by as much as two round-trip times). But it remains (in the authors' opinions at this time) an open question whether or not the four-packet start would be safe for the network.
在涉及长延迟链路的情况下，四包启动将非常有用（因为对于中等大小的传输，它将减少多达两次往返时间的传输时间）。但是（在当时作者的观点中）四包启动是否对网络安全仍然是一个悬而未决的问题。
It would be nice to see if this result could be duplicated with real TCPs, real modems, and real three-buffer limits.
如果能用真正的TCP、真正的调制解调器和真正的三个缓冲区限制复制这个结果，那就太好了。
Security Considerations
安全考虑
This document discusses a simulation study of the effects of a proposed change to TCP. Consequently, there are no security considerations directly related to the document. There are also no known security considerations associated with the proposed change.
本文讨论了对TCP的拟议变更影响的模拟研究。因此，没有与文件直接相关的安全考虑。也没有与拟议变更相关的已知安全考虑因素。
References
工具书类
1. S. Floyd, Increasing TCP's Initial Window (January 29, 1997). URL ftp://ftp.ee.lbl.gov/papers/draft.jan29.
1. 增加TCP的初始窗口（1997年1月29日）。统一资源定位地址ftp://ftp.ee.lbl.gov/papers/draft.jan29.
2. S. Floyd and M. Allman, Increasing TCP's Initial Window (July, 1997). URL http://gigahertz.lerc.nasa.gov/~mallman/share/draft-ss.txt
2. 增加TCP的初始窗口（1997年7月）。统一资源定位地址http://gigahertz.lerc.nasa.gov/~mallman/share/draft-ss.txt
3. Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
3. 奥尔曼，M.，弗洛伊德，S.，和C.帕特里奇，“增加TCP的初始窗口”，RFC 2414，1998年9月。
Authors' Addresses
作者地址
Tim Shepard BBN Technologies 10 Moulton Street Cambridge, MA 02138
蒂姆·谢泼德BBN Technologies马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: shep@alum.mit.edu
EMail: shep@alum.mit.edu
Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138
Craig Partridge BBN Technologies马萨诸塞州剑桥莫尔顿街10号，邮编02138
EMail: craig@bbn.com
EMail: craig@bbn.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。