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

Document Type RFC - Informational (September 1998; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2416 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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-
Show full document text