rfc2415.txt

<VC++网络游戏建摸与实现>源代码

Network Working Group                                            K. Poduri
Request for Comments: 2415                                      K. Nichols
Category: Informational                                       Bay Networks
                                                            September 1998


        Simulation Studies of Increased Initial TCP Window Size

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

   An increase in the permissible initial window size of a TCP
   connection, from one segment to three or four segments, has been
   under discussion in the tcp-impl working group. This document covers
   some simulation studies of the effects of increasing the initial
   window size of TCP. Both long-lived TCP connections (file transfers)
   and short-lived web-browsing style connections were modeled. The
   simulations were performed using the publicly available ns-2
   simulator and our custom models and files are also available.

1. Introduction

   We present results from a set of simulations with increased TCP
   initial window (IW). The main objectives were to explore the
   conditions under which the larger IW was a "win" and to determine the
   effects, if any, the larger IW might have on other traffic flows
   using an IW of one segment.

   This study was inspired by discussions at the Munich IETF tcp-impl
   and tcp-sat meetings. A proposal to increase the IW size to about 4K
   bytes (4380 bytes in the case of 1460 byte segments) was discussed.
   Concerns about both the utility of the increase and its effect on
   other traffic were raised. Some studies were presented showing the
   positive effects of increased IW on individual connections, but no
   studies were shown with a wide variety of simultaneous traffic flows.
   It appeared that some of the questions being raised could be
   addressed in an ns-2 simulation. Early results from our simulations
   were previously posted to the tcp-impl mailing list and presented at
   the tcp-impl WG meeting at the December 1997 IETF.



Poduri & Nichols             Informational                      [Page 1]

RFC 2415                    TCP Window Size               September 1998


2. Model and Assumptions

   We simulated a network topology with a bottleneck link as shown:

           10Mb,                                    10Mb,
           (all 4 links)                          (all 4 links)

      C   n2_________                               ______ n6     S
      l   n3_________\                             /______ n7     e
      i              \\              1.5Mb, 50ms   //             r
      e               n0 ------------------------ n1              v
      n   n4__________//                          \ \_____ n8     e
      t   n5__________/                            \______ n9     r
      s                                                           s

                    URLs -->          <--- FTP & Web data

   File downloading and web-browsing clients are attached to the nodes
   (n2-n5) on the left-hand side. These clients are served by the FTP
   and Web servers attached to the nodes (n6-n9) on the right-hand side.
   The links to and from those nodes are at 10 Mbps. The bottleneck link
   is between n1 and n0. All links are bi-directional, but only ACKs,
   SYNs, FINs, and URLs are flowing from left to right. Some simulations
   were also performed with data traffic flowing from right to left
   simultaneously, but it had no effect on the results.

   In the simulations we assumed that all ftps transferred 1-MB files
   and that all web pages had exactly three embedded URLs. The web
   clients are browsing quite aggressively, requesting a new page after
   a random delay uniformly distributed between 1 and 5 seconds. This is
   not meant to realistically model a single user's web-browsing
   pattern, but to create a reasonably heavy traffic load whose
   individual tcp connections accurately reflect real web traffic. Some
   discussion of these models as used in earlier studies is available in
   references [3] and [4].

   The maximum tcp window was set to 11 packets, maximum packet (or
   segment) size to 1460 bytes, and buffer sizes were set at 25 packets.
   (The ns-2 TCPs require setting window sizes and buffer sizes in
   number of packets. In our tcp-full code some of the internal
   parameters have been set to be byte-oriented, but external values
   must still be set in number of packets.)  In our simulations, we
   varied the number of data segments sent into a new TCP connection (or
   initial window) from one to four, keeping all segments at 1460 bytes.
   A dropped packet causes a restart window of one segment to be used,
   just as in current practice.





Poduri & Nichols             Informational                      [Page 2]

RFC 2415                    TCP Window Size               September 1998


   For ns-2 users: The tcp-full code was modified to use an
   "application" class and three application client-server pairs were
   written: a simple file transfer (ftp), a model of http1.0 style web
   connection and a very rough model of http1.1 style web connection.
   The required files and scripts for these simulations are available
   under the contributed code section on the ns-simulator web page at
   the sites ftp://ftp.ee.lbl.gov/IW.{tar, tar.Z} or http://www-
   nrg.ee.lbl.gov/floyd/tcp_init_win.html.

   Simulations were run with 8, 16, 32 web clients and a number of ftp
   clients ranging from 0 to 3. The IW was varied from 1 to 4, though
   the 4-packet case lies beyond what is currently recommended. The
   figures of merit used were goodput, the median page delay seen by the
   web clients and the median file transfer delay seen by the ftp
   clients. The simulated run time was rather large, 360 seconds, to
   ensure an adequate sample. (Median values remained the same for
   simulations with larger run times and can be considered stable)

3. Results

   In our simulations, we varied the number of file transfer clients in
   order to change the congestion of the link. Recall that our ftp
   clients continuously request 1 Mbyte transfers, so the link
   utilization is over 90% when even a single ftp client is present.
   When three file transfer clients are running simultaneously, the
   resultant congestion is somewhat pathological, making the values
   recorded stable. Though all connections use the same initial window,
   the effect of increasing the IW on a 1 Mbyte file transfer is not
   detectable, thus we focus on the web browsing connections.  (In the
   tables, we use "webs" to indicate number of web clients and "ftps" to
   indicate the number of file transfer clients attached.) Table 1 shows
   the median delays experienced by the web transfers with an increase
   in the TCP IW.  There is clearly an improvement in transfer delays
   for the web connections with increase in the IW, in many cases on the
   order of 30%.  The steepness of the performance improvement going
   from an IW of 1 to an IW of 2 is mainly due to the distribution of
   files fetched by each URL (see references [1] and [2]); the median
   size of both primary and in-line URLs fits completely into two
   packets. If file distributions change, the shape of this curve may
   also change.











Poduri & Nichols             Informational                      [Page 3]

RFC 2415                    TCP Window Size               September 1998


   Table 1. Median web page delay

   #Webs   #FTPs   IW=1    IW=2    IW=3    IW=4
                   (s)        (% decrease)
   ----------------------------------------------
     8      0      0.56    14.3  17.9   16.1
     8      1      1.06    18.9  25.5   32.1
     8      2      1.18    16.1  17.1   28.9
     8      3      1.26    11.9  19.0   27.0
    16      0      0.64    11.0  15.6   18.8
    16      1      1.04    17.3  24.0   35.6
    16      2      1.22    17.2  20.5   25.4
    16      3      1.31    10.7  21.4   22.1
    32      0      0.92    17.6  28.6   21.0
    32      1      1.19    19.6  25.0   26.1
    32      2      1.43    23.8  35.0   33.6
    32      3      1.56    19.2  29.5   33.3

   Table 2 shows the bottleneck link utilization and packet drop
   percentage of the same experiment. Packet drop rates did increase
   with IW, but in all cases except that of the single most pathological
   overload, the increase in drop percentage was less than 1%. A
   decrease in packet drop percentage is observed in some overloaded
   situations, specifically when ftp transfers consumed most of the link
   bandwidth and a large number of web transfers shared the remaining
   bandwidth of the link. In this case, the web transfers experience
   severe packet loss and some of the IW=4 web clients suffer multiple
   packet losses from the same window, resulting in longer recovery
   times than when there is a single packet loss in a window. During the
   recovery time, the connections are inactive which alleviates
   congestion and thus results in a decrease in the packet drop
   percentage. It should be noted that such observations were made only
   in extremely overloaded scenarios.


















Poduri & Nichols             Informational                      [Page 4]

RFC 2415                    TCP Window Size               September 1998


Table 2. Link utilization and packet drop rates

         Percentage Link Utilization            |      Packet drop rate
#Webs   #FTPs   IW=1    IW=2    IW=3  IW=4      |IW=1  IW=2  IW=3  IW=4
-----------------------------------------------------------------------
  8     0        34     37      38      39      | 0.0   0.0  0.0   0.0
  8     1        95     92      93      92      | 0.6   1.2  1.4   1.3
  8     2        98     97      97      96      | 1.8   2.3  2.3   2.7
  8     3        98     98      98      98      | 2.6   3.0  3.5   3.5
-----------------------------------------------------------------------
 16     0        67     69      69      67      | 0.1   0.5  0.8   1.0
 16     1        96     95      93      92      | 2.1   2.6  2.9   2.9
 16     2        98     98      97      96      | 3.5   3.6  4.2   4.5
 16     3        99     99      98      98      | 4.5   4.7  5.2   4.9
-----------------------------------------------------------------------
 32     0        92     87      85      84      | 0.1   0.5  0.8   1.0
 32     1        98     97      96      96      | 2.1   2.6  2.9   2.9
 32     2        99     99      98      98      | 3.5   3.6  4.2   4.5
 32     3       100     99      99      98      | 9.3   8.4  7.7   7.6

   To get a more complete picture of performance, we computed the
   network power, goodput divided by median delay (in Mbytes/ms), and
   plotted it against IW for all scenarios. (Each scenario is uniquely
   identified by its number of webs and number of file transfers.) We
   plot these values in Figure 1 (in the pdf version), illustrating a
   general advantage to increasing IW. When a large number of web
   clients is combined with ftps, particularly multiple ftps,
   pathological cases result from the extreme congestion. In these
   cases, there appears to be no particular trend to the results of
   increasing the IW, in fact simulation results are not particularly
   stable.

   To get a clearer picture of what is happening across all the tested
   scenarios, we normalized the network power values for the non-
   pathological scenario by the network power for that scenario at IW of
   one. These results are plotted in Figure 2. As IW is increased from
   one to four, network power increased by at least 15%, even in a
   congested scenario dominated by bulk transfer traffic. In simulations
   where web traffic has a dominant share of the available bandwidth,
   the increase in network power was up to 60%.

   The increase in network power at higher initial window sizes is due
   to an increase in throughput and a decrease in the delay. Since the
   (slightly) increased drop rates were accompanied by better
   performance, drop rate is clearly not an indicator of user level
   performance.





Poduri & Nichols             Informational                      [Page 5]

RFC 2415                    TCP Window Size               September 1998


   The gains in performance seen by the web clients need to be balanced
   against the performance the file transfers are seeing. We computed
   ftp network power and show this in Table 3.  It appears that the
   improvement in network power seen by the web connections has
   negligible effect on the concurrent file transfers. It can be
   observed from the table that there is a small variation in the
   network power of file transfers with an increase in the size of IW
   but no particular trend can be seen. It can be concluded that the
   network power of file transfers essentially remained the same.
   However, it should be noted that a larger IW does allow web transfers
   to gain slightly more bandwidth than with a smaller IW. This could
   mean fewer bytes transferred for FTP applications or a slight
   decrease in network power as computed by us.

   Table 3. Network power of file transfers with an increase in the TCP
            IW size

   #Webs   #FTPs   IW=1    IW=2    IW=3    IW=4
   --------------------------------------------
     8      1      4.7     4.2     4.2     4.2
     8      2      3.0     2.8     3.0     2.8
     8      3      2.2     2.2     2.2     2.2
    16      1      2.3     2.4     2.4     2.5
    16      2      1.8     2.0     1.8     1.9