396 lines
12 KiB
Plaintext
396 lines
12 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
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
|
||
|
||
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.
|
||
|
||
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).
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Shepard & Partridge Informational [Page 1]
|
||
|
||
RFC 2416 TCP with Four Packets into Three Buffers September 1998
|
||
|
||
|
||
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.
|
||
|
||
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 +----------+
|
||
|
||
| |
|
||
| |
|
||
(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.
|
||
|
||
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).
|
||
|
||
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
|
||
|
||
|
||
|
||
Shepard & Partridge Informational [Page 2]
|
||
|
||
RFC 2416 TCP with Four Packets into Three Buffers September 1998
|
||
|
||
|
||
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.)
|
||
|
||
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.)
|
||
|
||
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.)
|
||
|
||
What happens with normal slow start
|
||
|
||
At time 0.0 packet number 1 is sent.
|
||
|
||
At time 1.222 an ack is received covering packet number 1, and
|
||
packets 2 and 3 are sent.
|
||
|
||
At time 2.444 an ack is received covering packet number 2, and
|
||
packets 4 and 5 are sent.
|
||
|
||
At time 3.278 an ack is received covering packet number 3, and
|
||
packets 6 and 7 are sent.
|
||
|
||
At time 4.111 an ack is received covering packet number 4, and
|
||
packets 8 and 9 are sent.
|
||
|
||
At time 4.944 an ack is received covering packet number 5, and
|
||
packets 10 and 11 are sent.
|
||
|
||
At time 5.778 an ack is received covering packet number 6, and
|
||
packets 12 and 13 are sent.
|
||
|
||
At time 6.111 a duplicate ack is recieved (covering packet number 6).
|
||
|
||
At time 7.444 another duplicate ack is received (covering packet
|
||
number 6).
|
||
|
||
At time 8.278 a third duplicate ack is received (covering packet
|
||
number 6) and packet number 7 is retransmitted.
|
||
|
||
(And the trace continues...)
|
||
|
||
What happens with a four-packet start
|
||
|
||
At time 0.0, packets 1, 2, 3, and 4 are sent.
|
||
|
||
|
||
|
||
Shepard & Partridge Informational [Page 3]
|
||
|
||
RFC 2416 TCP with Four Packets into Three Buffers September 1998
|
||
|
||
|
||
At time 1.222 an ack is received covering packet number 1, and
|
||
packets 5 and 6 are sent.
|
||
|
||
At time 2.055 an ack is received covering packet number 2, and
|
||
packets 7 and 8 are sent.
|
||
|
||
At time 2.889 an ack is received covering packet number 3, and
|
||
packets 9 and 10 are sent.
|
||
|
||
At time 3.722 a duplicate ack is received (covering packet number 3).
|
||
|
||
At time 4.555 another duplicate ack is received (covering packet
|
||
number 3).
|
||
|
||
At time 5.389 a third duplicate ack is received (covering packet
|
||
number 3) and packet number 4 is retransmitted.
|
||
|
||
(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).
|
||
|
||
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.
|
||
|
||
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.)
|
||
|
||
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
|
||
|
||
|
||
|
||
Shepard & Partridge Informational [Page 4]
|
||
|
||
RFC 2416 TCP with Four Packets into Three Buffers September 1998
|
||
|
||
|
||
difference in timing was much smaller than the 0.229 second
|
||
difference discribed above.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
References
|
||
|
||
1. S. Floyd, Increasing TCP's Initial Window (January 29, 1997).
|
||
URL 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
|
||
|
||
3. Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
|
||
Initial Window", RFC 2414, September 1998.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Shepard & Partridge Informational [Page 5]
|
||
|
||
RFC 2416 TCP with Four Packets into Three Buffers September 1998
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Tim Shepard
|
||
BBN Technologies
|
||
10 Moulton Street
|
||
Cambridge, MA 02138
|
||
|
||
EMail: shep@alum.mit.edu
|
||
|
||
|
||
Craig Partridge
|
||
BBN Technologies
|
||
10 Moulton Street
|
||
Cambridge, MA 02138
|
||
|
||
EMail: craig@bbn.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Shepard & Partridge Informational [Page 6]
|
||
|
||
RFC 2416 TCP with Four Packets into Three Buffers September 1998
|
||
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Shepard & Partridge Informational [Page 7]
|
||
|