TCP’s initial congestion window is a key performance factor for short TCP connections. For many years, the initial value of the congestion window was set to less than two segments RFC2581. In 2002, RFC3390 proposed to increase this value up to 4 segments. This conservative value was a compromise between a fast startup of the TCP connection and preventing congestion collapse. In 2010, Nandita Dukkipati and her colleagues argued in An Argument for Increasing TCP’s Initial Congestion Window for increasing this initial value and demonstrated its benefits on google servers. After the publication of this article, and a patch to include this modification in the Linux kernel, it took only three years for the IETF to adopt the change in RFC6928.

Four years after the publication of RFC6928, we could expect all Internet servers to use an initial window of ten segments. CDNPlanet provides a simple web interface that allows to check the initial congestion window of remote servers, but unfortunately it only supports http and does not work with the popular https servers. During IETF’100, Marcelo Bagnulo released a summary of the results of a recent measurement campaign over the Alexa top 500k web servers.

The first two slides provide interesting and recent data about TCP’s initial congestion window. First, half of the popular web servers use an initial congestion window of 10 segments, but there are still a large number of servers that use shorter initial congestion windows.

- source : Marcelo Bagnulo’s email to tcpm working group

Second, surpringly, some server administrators seem to have manually tuned the initial congestion window of their servers to match the size of their homepage. While this can reduce the page load times when there is no congestion, this is a recipe for disaster in the long term…

- source : Marcelo Bagnulo’s email to tcpm working group