Summary

  • RFC 2414 made a larger TCP initial window optional: min(4*MSS, max(2*MSS, 4380 bytes)). It changed the first flight of a new connection, not every way TCP restarts after idleness or loss.
  • The practical wager was that a second segment could trigger an acknowledgment without waiting for a delayed-ACK timer, helping short transfers. RFC 2415's ns-2 simulations found lower median web-page delays in many modeled cases.
  • Mixed-flow results resisted a single verdict. At moderate modeled loads, IW=3 did not harm the IW=1 group; at 32/32 web clients in an extremely congested scenario, the larger-window group itself fared worse.
  • Those were simulations, not an Internet-wide deployment study. A per-connection speed gain and the distribution of effects on a shared path remained different questions.

The first acknowledgment was the prize

The idea sounded modest: begin a new TCP connection with more than one data segment instead of one. Its payoff could appear before a large transfer had really begun. With only one segment in flight, a receiver using delayed acknowledgments might wait for its timer before answering. Send at least two and the second arrival can prompt an acknowledgment sooner. For a short email or web object, that avoided wait could decide whether the transfer finished in a single round trip.

For a connection able to grow its congestion window, RFC 2414 said the change might remove as many as three round trips and a delayed-ACK timeout from the opening slow-start phase.

RFC 2414 did not prescribe four segments for every connection. Published as Experimental in September 1998, it raised the permitted upper bound to min(4*MSS, max(2*MSS, 4380 bytes)) and said a TCP MAY use the larger value. MSS mattered: depending on segment size, the bound could be two, three or four segments. The proposal applied to the initial window after the three-way handshake. It kept the loss window at one segment, and treated restarting after a long idle period as a separate, optional rule. “A larger start” was therefore a bounded experiment, not permission to enlarge every congestion window whenever traffic paused.

The endpoint could choose the first flight; it could not reserve the queue it entered. RFC 2414 names two sides of that bargain. A burst might cost the initiating connection packets or timeouts, while other traffic could bear drops or unfairness at a congested shared link. The authors also warned that browsers opening several connections simultaneously would compound that problem if each connection began larger. Their concern was not abstract: a per-flow improvement can change the load presented to a queue that does not belong to that flow alone.

The simulations kept more than one score

RFC 2415, an Informational companion rather than a deployment report, tested the dispute in ns-2. Its model placed a 1.5 Mbps, 50 ms bottleneck between faster links. It varied 8, 16 or 32 web clients, added up to three long FTP transfers, and tried initial windows from one to four 1460-byte segments. The web model used small pages with three embedded URLs and made new requests after randomized waits; FTP moved one-megabyte files. These choices made a controlled comparison possible, but also defined exactly what its results could speak for.

Across many modeled cases, web clients with larger initial windows saw lower median page delay—often around 30 percent. The authors tied much of the steep improvement from one to two segments to their URL-size distribution: the median primary and inline objects fit into two packets. Change the distribution and the curve could change too. The result was a mechanism-plus-model finding, not a universal percentage for browsers or links.

The split cohorts sharpened the question. With 8/8 and 16/16 web clients divided between IW=1 and IW=3, the authors reported no negative effect on the one-segment group while the larger-window group retained an advantage. At 32/32, under what the paper called pathological congestion, IW=3 clients were adversely affected. The authors attributed that case to many simultaneous connection openings and multiple losses. The experiment did not show that every larger start harms its neighbors; it showed that an aggregate or median improvement could not settle every cohort's experience under every modeled load.

That is distinct from RFC 2416's already published single-connection, three-buffer trace. RFC 2415's evidence is about many modeled flows sharing a bottleneck and about how the result changes with their mix. Neither simulation established real-device behavior across the Internet, and neither supplied a universal fairness measure. Later, RFC 3390 obsoleted RFC 2414 with a standards-track optional bound; RFC 5681 recorded that rule, and RFC 6928 explored a ten-segment start experimentally. Their publication history does not retroactively turn the 1998 model into a deployment census.

Heng Lu's Running-Code Primacy is useful here only as an evidentiary restraint: keep the mechanism and the system actually tested in view. On Reality Layers offers a second narrow lens: do not collapse a page's delay, a queue's losses and a network-wide conclusion into one observation. Neither note supplies historical evidence about TCP; RFC 2414 and RFC 2415 do.

Sources