RFC 2416

When TCP Starts Up With Four Packets Into Only Three Buffers

📅 published September 1998, from ietf

RFC 2416 💖 When TCP Starts Up With Four Packets Into Only Three Buffers

Network Working Group 🎀 Request for Comments: 2416 🎀 Category: Informational ✨ Authors: T. Shepard and C. Partridge, both from BBN Technologies 🧚 Date: September 1998 📅

Okay so bestie, the title block tells us this is an Informational doc (so it's sharing info, not setting a standard 💅), it was written by Tim Shepard and Craig Partridge at BBN Technologies, and it's dated September 1998. The block doesn't list anything it obsoletes or updates, so it isn't replacing or changing any other RFC. 🦋

Status of this Memo ✨

Quick vibe check: this memo is here to share information with the Internet community. It is NOT a standard of any kind 🙅‍♀️, and anyone can see it freely since distribution is totally unlimited 🌈.

Copyright (C) The Internet Society (1998). All Rights Reserved. 🔒

Abstract 🌸

This memo is basically a tiny experiment write-up 🧪. Here's the setup: a TCP receiver sits behind a 9600 bps modem link at the edge of a super fast Internet, and there are only 3 buffers before the modem. So the fourth packet of a four-packet start is going to get dropped, no cap 😭. The result? Compared with a normal slow start (which just starts with one packet), a TCP sender using a four-packet start shows no significant degradation in performance 💅✨.

Background 🧚

Sally Floyd proposed that TCPs kick off their initial slow start by sending up to four packets instead of the usual one. The goal is to get TCP up to speed faster 🚀. (Slow starts triggered by timeouts still begin with just one packet, so don't mix those up 🙈.) Starting with more than one packet could cut start-up latency over long-fat pipes by two round-trip times. You can read more about this idea in [1], [2], and in [3], and this doc assumes you already know the details 🤓.

Then on the end2end-interest mailing list, someone raised a concern 😬. In the (allegedly common) case where a slow modem is served by a router that only allocates three buffers per modem (one buffer being transmitted while two packets wait), starting with four packets wouldn't be good, because that fourth packet is sure to be dropped.

Vern Paxson replied (among other things) that the four-packet start is no worse than what normal slow start does after two round trip times. So no new problem is introduced by starting with up to four packets. If there's a problem with a four-packet start, then that problem already exists in a normal slow-start startup after two round trips, when slow start releases four closely spaced packets into the net 🫶.

The experiment in this memo confirmed Vern Paxson's reasoning 👑.

Scenario and experimental setup 🎀

Here's the lineup, bestie 👇

+--------+  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 has three links between the source and the sink 🔗. The first is a 100 Mbps link with no delay, connecting the sender to a router. It's there so the returning ACKs can be logged at the moment the sender would see them 👀. The second is a 1.5 Mbps link with a 25 ms one-way delay, which roughly models an un-congested, intra-continental piece of the terrestrial Internet 🌍. The third is a 9600 bps link with a 150 ms one-way delay, connecting the edge of the net to a receiver sitting behind that slow modem 🐌.

The queue limits at each end of the first two links were set to 100, which is big enough that the limit never mattered 💅. 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 🧃.

They used Version 1.2a2 of the NS simulator (available from LBL) to simulate both one-packet and four-packet starts for each available TCP algorithm (tahoe, reno, sack, fack). The authors believe the conclusion here doesn't depend on which TCP algorithm you pick, at least in general 🤍. This memo uses the "tahoe" module 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 window-init value only on connection start. Other instances of slow start set cwnd to 1 instead. (The tcp.cc module as shipped with ns-1.2a2 would use the window-init value in all cases, so they had to tweak it 🛠️.)

The packets in the simulation are 1024 bytes long, which is what determines how long they take to transmit across the links 📦. (The TCP modules in the LBL NS simulator don't simulate TCP sequence number mechanisms. They just use packet numbers 🔢.)

All packets and acknowledgements crossing the 100 Mbps no-delay link, near the sender, were observed. Every description below is from that point of view 👀✨.

What happens with normal slow start 🐢

Here's the trace, verbatim, no cap:

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 🚀

Now the spicy version 🌶️, verbatim too:

At time 0.0, packets 1, 2, 3, and 4 are sent.

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 🧠

By the point where the two traces above stop, the two systems are in almost identical states 🪞. From there on, the traces are almost the same, except for a time shift of (8.278 - 5.389) = 2.889 seconds and a shift of three packets. So if the normal TCP (with the one-packet start) delivers packet N at time T, then the TCP with the four-packet start delivers packet N - 3 at time T - 2.889 (seconds) ⏰.

Now, sending three 1024-byte TCP segments through a 9600 bps modem takes 2.66 seconds 🐌. So when does the four-packet-start TCP deliver packet N? At time T - 2.889 + 2.66 = T - 0.229 in most cases. In some cases it's earlier, and in some cases it's later, because different packets (by number) experience loss in the two traces 🎲.

So the four-packet-start TCP is, in a sense, 0.229 seconds (or about one fifth of a packet) ahead of where the one-packet-start TCP would be 🏃‍♀️💨. This comes from the extra time the modem sits idle while the one-packet-start TCP waits for the dally timer to go off in the receiver ⌛.

The two systems aren't exactly identical, though 🤏. Their round-trip-time estimators differ slightly because the start-up behaviour isn't identical. (Observed round trip times may differ a little because of dally timers, and because the one-packet start goes through more round trip times before the first loss.) In the cases where a retransmit timer went off later, the extra timing difference was much smaller than the 0.229 second difference described 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 when a long-delay link is involved, since it could cut transfer times for moderately sized transfers by as much as two round-trip times 🎉. But (in the authors' opinions at this time) it's still an open question whether the four-packet start would be safe for the network 🤔.

It would be nice to see whether this result can be duplicated with real TCPs, real modems, and real three-buffer limits 🙏.

Security Considerations 🔐

⚠️ Serious moment, bestie: this document discusses a simulation study of the effects of a proposed change to TCP. Because of that, 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.

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

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. 💜🦋

📦 where this page comes from