HighSpeed TCP (HSTCP)

Papers:

• RFC 3649: HighSpeed TCP for Large Congestion Windows .
  Sally Floyd.
  RFC 3649, Experimental, December 2003. Local copy: (postscript, text).

• RFC 3742: Limited Slow-Start for TCP with Large Congestion Windows .
  Sally Floyd.
  RFC 3742, Experimental, March 2004.
  Local copy: (postscript, text). Errata.

• S. Floyd, S. Ratnasamy, and S. Shenker.
  Modifying TCP's Congestion Control for High Speeds (postscript, PDF).
  Rough draft, May 2002. Or the November 2001 version.

Talks:

• HighSpeed TCP and Quick-Start for Fast Long-Distance Networks ,
  tsvwg, IETF, March 2003. (postscript, PDF).

• Sally Floyd, Congestion Control for High-Bandwidth-Delay-Product Networks: XCP vs. HighSpeed TCP and QuickStart,
  ICIR Wednesday Lunch, September 11, 2002 (postscript, PDF).

• Sally Floyd, HighSpeed TCP for Large Congestion Windows and Quick-Start for TCP and IP,
  (postscript, PDF), Yokohama IETF, tsvwg, July 18, 2002

• Sally Floyd, TCP for Large Congestion Windows (postscript, PDF),
  End-to-End Research Group, May 13, 2002.

Evaluations

• A Comprehensive TCP Fairness Analysis in High Speed Networks,
  S. Molnár, B. Sonkoly, T. A. Trinh,
  to appear in Computer Communications Journal, 2009.
  "We present our comprehensive performance evaluation results of both inter- and intra-protocol fairness behavior of different TCP versions."

• A Simulation Based Comparison Between XCP and HighSpeed TCP.
  Gleb A. Chuvpilo and Jae Wook Lee,
  6.829 Computer Networks Final Project. Massachusetts Institute of Technology, Cambridge, Massachusetts, December, 2002.

Implementations and Experimental Reports:

• Riverbed uses High-Speed TCP.

• Linux:
  • Tests over ESNet by Tom Dunigan. Tom added HighSpeed TCP to the Linux 2.4.16 Web100 kernel.

  • HighSpeed TCP implementation from Gareth Fairey at Manchester University and from Yee-Ting Li from UCL, for Linux 2.4.19 and 2.4.20, with experimental results.

  • D. X. Wei and P. Cao, NS-2 TCP-Linux: An NS-2 TCP Implementation with Congestion Control Algorithms from Linux, Workshop on NS-2, October 2006.
    Section 4.4 is on "An Example: Fixing Bugs in the Linux HighSpeed TCP Implementation": "This figure illustrates three bugs in the HighSpeed TCP implementation in Linux 2.6.16-3, found in our testings with NS-2 TCP-Linux."

• Les Cottrell's experiments of TCP Stack measurements, from SLAC, comparing HS TCP, FAST TCP, Scalable TCP, and stock TCP. Experiments include TCP Stacks comparison with a single stream, comparisons with multiple streams, and more.

• A. Antony, J. Blom, C. de Laat, J. Lee, and W. Sjouw, Macroscopic Examination of TCP Flows over Transatlantic Links, January 2003.
  "We have shown that tuning the host parameters and HSTCP are very important when trying to make best use of avaliable bandwidth over high-bandwidth long-delay networks. The maximum throughtput obtained over the Trans-Atlantic link (96 msec RTT) was 730 Mbps using a single TCP stream."

• Hadrien Bullot, R. Les Cottrell, and Richard Hughes-Jones, Evaluation of Advanced TCP Stacks on Fast Long-Distance Production Networks (with slides), February 2004, PFLDnet 2004.

• Yee-Ting Li, Stephen Dallison, Richard Hughes-Jones, Peter Clarke, A Systematic Analysis of High Throughput TCP in Real Network Environments (with slides), February 2004, PFLDnet 2004.
  "Preliminary studies show that HighSpeed TCP is safely deployable."

Simulations:

• Notes on the HighSpeedTCP code in NS.

• Souza, E., and Agarwal, D.A., A HighSpeed TCP Study: Characteristics and Deployment Issues. LBNL Technical Report LBNL-53215.
  "In this paper, simulation results showing the performance of HighSpeed TCP and the impact of its use on the present implementation of TCP are presented." Evandro's web site.

• Sally's very simple simulations of Slow-start.

• Note on the HighSpeed TCP code in NS:
  The code in NS, in case 8 of procedure opencwnd() and in procedure slowdown() in the file tcp/tcp.cc, includes the following comment: "For an efficient implementation, this would just be looked up in a table, with the increase and decrease being a function of the congestion window." The current code is rather inefficient, and calculates the increase and decrease parameters separately each time. If anyone ever wanted to improve the code to use a more efficient lookup approach, I would be happy to add it to the NS distribution. - Sally

• I would also recommend the following:
  Agent/TCP set numdupacksFrac_ 10
  This was just added to NS in October, 2002. With the new option, numdupacks() is set to the maximum of numdupacks_ (with a default of 3 packets) and cwnd/numdupacksFrac_. Thus, when the congestion window is large, the numdupacks threshold is increased, to allow a larger wait before retransmitting the lost or delayed packet. The purpose of this is to reduce the chances that the retransmitted packet is itself dropped, without appreciably increasing the delay for a retransmitted packet.

Convergence times:

• R.N. Shorten, D.J. Leith, J. Foy, and R. Kilduff, Analysis and Design of Congestion Control in Synchronised Communication Networks. Proc. 12th Yale Workshop on Adaptive & Learning Systems, May 2003.
  "We show that networks of communicating devices operating additive-increase multiplicative-decrease (AIMD) congestion control algorithms may be modelled as a positive linear system." Section 5 of the paper considers convergence times for TCP, High-Speed TCP, and H-TCP in environments with global synchronization.

• M. Nabeshima, K. Yata, Improving the Convergence Time of HighSpeed TCP, IEEE International Conference on Networks (ICON2004), pp. 19-23, Nov. 2004.
  "This paper proposes a new mechanism to improve the convergence time of HS-TCP." The simulations in the paper also examine the effect of background traffic, bandwidth, and the number of competing flows on convergence times.

• S. Hassayoun and David Ros, Loss Synchronization and Router Buffer Sizing with High-Speed Versions of TCP, 2008.
  "Our preliminary findings suggest that high-speed versions of TCP do yield higher levels of synchronization. However, in spite of a strong drop synchronization, such TCP versions can achieve both high goodput and link utilization, as long as enough buffering is provided."

Related work: