TCP's Initial Congestion Window (ICW, IW or initcwnd)

The original version of TCP Congestion Control specified that the congestion window should start at the maximum segment size (MSS) of the connection, which is computed from the peer's MSS advertisement obtained during SYN handshake and possible results from Path MTU Discovery.

Around the turn of the century, it was suggested that this initial congestion window be increased. This would particularly benefit short transactions such as "Web mice" over connections with high RTTs. In September 1998, RFC 2414 suggested experimentation with an initial window of 2-4 MSS, depending on the range of MSS. This was upgraded to a general recommendation with RFC 3390 in October 2002, and integrated (in slightly refined form) into the current congestion control specification in RFC 5681. The TBIT paper, which used data from early 2004, still found little use of larger initial congestion windows, although it can be expected that this has become widespread by now. According to RFC 5681, the typical machine connected using ~1500-byte MTU links, should be three MSS or around 4300 bytes.

2010 - 2013: Proposals to Increase TCP's Initial Window

More recently, some have proposed to further increase TCP's initial window. In December 2010, there were four proposals being discussed in the IETF's TCPM (Modifications to TCP) WG as well as the IRTF's ICCRG (Internet Congestion Control Research Group): A group of authors from Google, H.K. Jerry Chu, Nandita Dukkipati, Yuchung Cheng, and Matt Mathis, propose (draft-hkchu-tcpm-initcwnd) to increase the initial window to 10 segments. They support this with analytical and experimental work that shows significant improvements in completion times for typical-sized web transfers with little harmful effects. The second proposal (draft-allman-tcpm-bump-initcwnd), by Mark Allman (ICSI), suggests to increase the initial window over time, starting with 6 segments in 2011 and increasing that to 15 segments by 2019. A third proposal (draft-yourtchenko-two-party-initial-window), by Andrew Yourtchenko, Ali Begen, and Anantha Ramaiah (Cisco), suggests to negotiate the initial window between both parties of the TCP connection, similar to what is done for the Maximum Segment Size (MSS). Finally, Joe Touch issued a draft (draft-touch-tcpm-automatic-iw) that proposes to adapt the Initial Window over the long term based on slow additive increase, and multiplicative decrease when it is detected that the IW is too large. Most of these drafts have expired in the meantime.

In July 2011, Joe Touch issued draft-touch-tcpm-automatic-iw-01.txt , which claims that

TCP can objectively measure when an IW is too large, and that such feedback should be used over long timescales to adjust the IW automatically.

The proposals to increase the Initial Window have come under criticism in the context of the BufferBloat debate, because large initial windows from fast servers can create noticeable temporary congestion towards receivers behind slow connections, such as on mobile, especially when multiple connections simultaneously start sending data, as is common with in today's WWW. Recent versions of draft-ietf-tcpm-initcwnd (as of October 2012) attempt to take these concerns into account. Version -06 of the draft went to IETF Last Call in November 2012, resulting in a slightly revised version -07 , which adds some text about possible adverse effects (see BufferBloat) and how those could be addressed. *

In April 2013, RFC 6928 was issued as an Experimental RFC based on draft-ietf-tcpm-initcwnd-08.txt.

In November 2015, Mark Allman published draft-allman-tcpm-no-initwin-00.txt, which suggests to remove initial window restrictions altogether, and allow the sender to send as many packets as it wants under certain conditions. In particular, if the initial cwnd chosen is larger than 10 segments, the packets must be evenly paced over the first round-trip time.