Summary

  • RFC 2416 modeled a 9600 bps modem behind a router with room for three packets. The fourth packet in a four-packet TCP start was therefore certain to be dropped in that topology.
  • That local loss was not the experiment’s end-to-end verdict. Ordinary slow start later produced a comparable burst, and the two simulated traces entered nearly the same recovery state at different times and packet numbers.
  • After accounting for modem transmission time, the four-packet trace was about 0.229 seconds ahead in most cases. The memo called the result harmless only “in this particular case”; network-wide safety and real-device behavior remained open.
  • The historical lesson is evidentiary: count the baseline’s later losses and the whole measured outcome, but do not turn one simulator run into a universal safety claim.

The queue was certain; the verdict was not

The objection was almost too simple to argue with. Put four packets into a queue that can hold three and the fourth cannot stay. RFC 2416 did not try to wish that arithmetic away. Its question was whether an initial TCP burst that predictably lost one packet performed worse than the established alternative once both were followed through the same constrained path.

The September 1998 memo was explicitly Informational, not a standard. Its model ran from a source across a 100 Mbps link with no delay, through a 1.5 Mbps link with 25 milliseconds of one-way delay, and then over a 9600 bps modem link with 150 milliseconds of one-way delay to a receiver. The router feeding the modem had three packet buffers: one packet could be on the wire while two waited. The first two links had queues large enough not to bind the experiment.

The authors used LBL’s NS simulator, version 1.2a2. They compared one- and four-packet starts across Tahoe, Reno, SACK and FACK modules; Tahoe supplied the illustrated traces. Packets were modeled as 1024 bytes for transmission timing. The memo notes that these TCP modules used packet numbers rather than simulating TCP sequence-number machinery. Observations were taken near the sender, on the fast, zero-delay link. Those choices make the run legible, but they also draw its perimeter.

The baseline eventually sent a burst too

With normal slow start, the sender begins with packet 1. An acknowledgment at 1.222 seconds allows packets 2 and 3; the next relevant acknowledgment at 2.444 seconds releases packets 4 and 5. At 3.278 seconds, the acknowledgment for packet 3 allows packets 6 and 7. Packet 7 is later lost, and the third duplicate acknowledgment retransmits it at 8.278 seconds.

The four-packet case begins by sending packets 1 through 4 at once. Packet 4 is lost at the three-packet queue. Its third duplicate acknowledgment arrives at 5.389 seconds and triggers retransmission. At that point, the traces are nearly in the same state. From there, the memo says, they are almost the same after shifting by 2.889 seconds and three packet numbers.

That comparison changes the question. The first trace does not avoid a four-packet burst forever; slow start reaches one later. A loss in the four-packet opening flight is real, but the baseline’s later packet-7 loss is real too. Looking only at the first dropped packet would compare unlike slices of two executions.

What the 0.229 seconds measured

The time shift alone was 2.889 seconds. The modem took 2.66 seconds to transmit three 1024-byte segments. Subtracting one from the other left the four-packet case about 0.229 seconds ahead in most of the simulated cases. The authors attributed that small difference to the modem sitting idle while the one-packet start waited for the receiver’s delayed-acknowledgment timer. Because packet losses differed, some cases finished earlier and some later; 0.229 seconds was not a promise for every run.

This is useful evidence about the modeled connection, not proof that a larger opening flight is safe for every path. The memo itself says it remained an open question whether four-packet starts were safe for the network. It asks for the result to be repeated with real TCP implementations, real modems and real three-buffer limits. That request matters: the simulator made the suspected local loss certain, but it could not settle the external costs that a shared network might impose on other flows.

This is where two distinctions in Heng Lu’s notes are useful as analytical lenses, not as historical authorship. Running-Code Primacy favors the packet and acknowledgment traces over intuition, while insisting that evidence stop where the tested code and topology stop. Reality Layers keeps a queue drop, a connection’s completion time and network-wide stability from being treated as the same fact. RFC 2416 gives evidence for the first two within a model; it expressly withholds the third.

Sources