⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc2414.txt

📁 RFC 的详细文档!
💻 TXT
📖 第 1 页 / 共 3 页
字号:
       segment.

   An increased packet drop rate:

       For a network with a high segment drop rate, increasing the TCP
       initial window could increase the segment drop rate even further.
       This is in part because routers with Drop Tail queue management
       have difficulties with bursty traffic in times of congestion.
       However, given uncorrelated arrivals for TCP connections, the
       larger TCP initial window should not significantly increase the
       segment drop rate.  Simulation-based explorations of these issues
       are discussed in Section 7.2.






Allman, et. al.               Experimental                      [Page 5]

RFC 2414            Increasing TCP's Initial Window       September 1998


   These potential dangers for the network are explored in simulations
   and experiments described in the section below.  Our judgement would
   be, while there are dangers of congestion collapse in the current
   Internet (see [FF98] for a discussion of the dangers of congestion
   collapse from an increased deployment of UDP connections without
   end-to-end congestion control), there is no such danger to the
   network from increasing the TCP initial window to 4K bytes.

6.  Typical Levels of Burstiness for TCP Traffic.

   Larger TCP initial windows would not dramatically increase the
   burstiness of TCP traffic in the Internet today, because such traffic
   is already fairly bursty.  Bursts of two and three segments are
   already typical of TCP [Flo97]; A delayed ACK (covering two
   previously unacknowledged segments) received during congestion
   avoidance causes the congestion window to slide and two segments to
   be sent.  The same delayed ACK received during slow start causes the
   window to slide by two segments and then be incremented by one
   segment, resulting in a three-segment burst.  While not necessarily
   typical, bursts of four and five segments for TCP are not rare.
   Assuming delayed ACKs, a single dropped ACK causes the subsequent ACK
   to cover four previously unacknowledged segments.  During congestion
   avoidance this leads to a four-segment burst and during slow start a
   five-segment burst is generated.

   There are also changes in progress that reduce the performance
   problems posed by moderate traffic bursts.  One such change is the
   deployment of higher-speed links in some parts of the network, where
   a burst of 4K bytes can represent a small quantity of data.  A second
   change, for routers with sufficient buffering, is the deployment of
   queue management mechanisms such as RED, which is designed to be
   tolerant of transient traffic bursts.

7.  Simulations and Experimental Results

7.1 Studies of TCP Connections using that Larger Initial Window

   This section surveys simulations and experiments that have been used
   to explore the effect of larger initial windows on the TCP connection
   using that larger window.  The first set of experiments explores
   performance over satellite links.  Larger initial windows have been
   shown to improve performance of TCP connections over satellite
   channels [All97b].  In this study, an initial window of four segments
   (512 byte MSS) resulted in throughput improvements of up to 30%
   (depending upon transfer size).  [KAGT98] shows that the use of
   larger initial windows results in a decrease in transfer time in HTTP
   tests over the ACTS satellite system.  A study involving simulations




Allman, et. al.               Experimental                      [Page 6]

RFC 2414            Increasing TCP's Initial Window       September 1998


   of a large number of HTTP transactions over hybrid fiber coax (HFC)
   indicates that the use of larger initial windows decreases the time
   required to load WWW pages [Nic97].

   A second set of experiments has explored TCP performance over dialup
   modem links.  In experiments over a 28.8 bps dialup channel [All97a,
   AHO98], a four-segment initial window decreased the transfer time of
   a 16KB file by roughly 10%, with no accompanying increase in the drop
   rate.  A particular area of concern has been TCP performance over low
   speed tail circuits (e.g., dialup modem links) with routers with
   small buffers.  A simulation study [SP97] investigated the effects of
   using a larger initial window on a host connected by a slow modem
   link and a router with a 3 packet buffer.  The study concluded that
   for the scenario investigated, the use of larger initial windows was
   not harmful to TCP performance.  Questions have been raised
   concerning the effects of larger initial windows on the transfer time
   for short transfers in this environment, but these effects have not
   been quantified.  A question has also been raised concerning the
   possible effect on existing TCP connections sharing the link.

7.2 Studies of Networks using Larger Initial Windows

   This section surveys simulations and experiments investigating the
   impact of the larger window on other TCP connections sharing the
   path.  Experiments in [All97a, AHO98] show that for 16 KB transfers
   to 100 Internet hosts, four-segment initial windows resulted in a
   small increase in the drop rate of 0.04 segments/transfer.  While the
   drop rate increased slightly, the transfer time was reduced by
   roughly 25% for transfers using the four-segment (512 byte MSS)
   initial window when compared to an initial window of one segment.

   One scenario of concern is heavily loaded links.  For instance, a
   couple of years ago, one of the trans-Atlantic links was so heavily
   loaded that the correct congestion window size for a connection was
   about one segment.  In this environment, new connections using larger
   initial windows would be starting with windows that were four times
   too big.  What would the effects be?  Do connections thrash?

   A simulation study in [PN98] explores the impact of a larger initial
   window on competing network traffic.  In this investigation, HTTP and
   FTP flows share a single congested gateway (where the number of HTTP
   and FTP flows varies from one simulation set to another).  For each
   simulation set, the paper examines aggregate link utilization and
   packet drop rates, median web page delay, and network power for the
   FTP transfers.  The larger initial window generally resulted in
   increased throughput, slightly-increased packet drop rates, and an
   increase in overall network power.  With the exception of one
   scenario, the larger initial window resulted in an increase in the



Allman, et. al.               Experimental                      [Page 7]

RFC 2414            Increasing TCP's Initial Window       September 1998


   drop rate of less than 1% above the loss rate experienced when using
   a one-segment initial window; in this scenario, the drop rate
   increased from 3.5% with one-segment initial windows, to 4.5% with
   four-segment initial windows.  The overall conclusions were that
   increasing the TCP initial window to three packets (or 4380 bytes)
   helps to improve perceived performance.

   Morris [Mor97] investigated larger initial windows in a very
   congested network with transfers of size 20K.  The loss rate in
   networks where all TCP connections use an initial window of four
   segments is shown to be 1-2% greater than in a network where all
   connections use an initial window of one segment.  This relationship
   held in scenarios where the loss rates with one-segment initial
   windows ranged from 1% to 11%.  In addition, in networks where
   connections used an initial window of four segments, TCP connections
   spent more time waiting for the retransmit timer (RTO) to expire to
   resend a segment than was spent when using an initial window of one
   segment.  The time spent waiting for the RTO timer to expire
   represents idle time when no useful work was being accomplished for
   that connection.  These results show that in a very congested
   environment, where each connection's share of the bottleneck
   bandwidth is close to one segment, using a larger initial window can
   cause a perceptible increase in both loss rates and retransmit
   timeouts.

8.  Security Considerations

   This document discusses the initial congestion window permitted for
   TCP connections.  Changing this value does not raise any known new
   security issues with TCP.

9.  Conclusion

   This document proposes a small change to TCP that may be beneficial
   to short-lived TCP connections and those over links with long RTTs
   (saving several RTTs during the initial slow-start phase).

10.  Acknowledgments

   We would like to acknowledge Vern Paxson, Tim Shepard, members of the
   End-to-End-Interest Mailing List, and members of the IETF TCP
   Implementation Working Group for continuing discussions of these
   issues for discussions and feedback on this document.








Allman, et. al.               Experimental                      [Page 8]

RFC 2414            Increasing TCP's Initial Window       September 1998


11.  References

   [All97a]    Mark Allman.  An Evaluation of TCP with Larger Initial
               Windows.  40th IETF Meeting -- TCP Implementations WG.
               December, 1997.  Washington, DC.

   [AHO98]     Mark Allman, Chris Hayes, and Shawn Ostermann, An
               Evaluation of TCP with Larger Initial Windows, March
               1998.  Submitted to ACM Computer Communication Review.
               URL: "http://gigahertz.lerc.nasa.gov/~mallman/papers/
               initwin.ps".

   [All97b]    Mark Allman.  Improving TCP Performance Over Satellite
               Channels.  Master's thesis, Ohio University, June 1997.

   [BLFN96]    Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
               Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.

   [Bra89]     Braden, R., "Requirements for Internet Hosts --
               Communication Layers", STD 3, RFC 1122, October 1989.

   [FF96]      Fall, K., and Floyd, S., Simulation-based Comparisons of
               Tahoe, Reno, and SACK TCP.  Computer Communication
               Review, 26(3), July 1996.

   [FF98]      Sally Floyd, Kevin Fall.  Promoting the Use of End-to-End
               Congestion Control in the Internet.  Submitted to IEEE
               Transactions on Networking.  URL "http://www-
               nrg.ee.lbl.gov/floyd/end2end-paper.html".

   [FJGFBL97]  Fielding, R., Mogul, J., Gettys, J., Frystyk, H., and T.
               Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
               RFC 2068, January 1997.

   [FJ93]      Floyd, S., and Jacobson, V., Random Early Detection
               gateways for Congestion Avoidance. IEEE/ACM Transactions
               on Networking, V.1 N.4, August 1993, p. 397-413.

   [Flo94]     Floyd, S., TCP and Explicit Congestion Notification.
               Computer Communication Review, 24(5):10-23, October 1994.

   [Flo96]     Floyd, S., Issues of TCP with SACK. Technical report,
               January 1996.  Available from http://www-
               nrg.ee.lbl.gov/floyd/.

   [Flo97]     Floyd, S., Increasing TCP's Initial Window.  Viewgraphs,
               40th IETF Meeting - TCP Implementations WG. December,
               1997.  URL "ftp://ftp.ee.lbl.gov/talks/sf-tcp-ietf97.ps".



Allman, et. al.               Experimental                      [Page 9]

RFC 2414            Increasing TCP's Initial Window       September 1998


   [KAGT98]    Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran.  HTTP
               Page Transfer Rates Over Geo-Stationary Satellite Links.
               March 1998.  Proceedings of the Sixth International
               Conference on Telecommunication Systems.  URL
               "http://gigahertz.lerc.nasa.gov/~mallman/papers/nash98.ps".

   [MD90]      Mogul, J., and S. Deering, "Path MTU Discovery", RFC
               1191, November 1990.

   [MMFR96]    Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
               Selective Acknowledgment Options", RFC 2018, October
               1996.

   [Mor97]     Robert Morris.  Private communication, 1997.  Cited for
               acknowledgement purposes only.

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -