We all want, and need, the fastest possible Internet. To give that to its customers, Microsoft is upgrading its TCP/IP networking stack in Windows 10 and Windows Server 2016.
These improvements are designed to decrease TCP connection setup time, increase TCP startup speed, and to decrease time to recover from packet loss. Specifically, in the Windows Redstone releases, these are:
While Microsoft implies that these are Microsoft improvements. Most of them come from work by Google. Here's a summary of what they bring to the table.
TCP Fast Open is based on the Internet Engineering Task Force (IETF) experimental request for comment (RFC) 2070 work by Google. TFO allows data to be carried in the SYN and SYN-ACK packets and consumed by the receiving end during the initial connection handshake. This saves up to one full round-trip time (RTT) compared to the standard TCP, which requires a three-way handshake (3WHS) to complete before data can be exchanged.
That may not sound like much, but it provides latency savings that are very important for short web transfers over the Internet where the average latency is on the order of 40 milliseconds. With web pages with multiple elements that saves real time.
To use TCP safely, you need to use it with Transport Layer Security (TLS). The Anniversary Update for Windows 10 will ship with a fully compliant client side implementation enabled by default. The Microsoft Edge browser will ship with a About:Flags setting for TCP Fast Open which will be disabled by default. The eventual goal is to have it enabled by default in IE and Edge browsers in a subsequent Windows 10 release. Later, Microsoft plans to fully integrate the server side implementation with its IIS web server. The server side implementation will be disabled by default.
To use it in Edge, you'll need to navigate to "about:flags" or "about:config" and use check-box for "Enable TCP Fast Open", Netsh int tcp set global fastopen=<enabled | disabled>
Initial Congestionis based on Google's IETF RFC 2070. TCP flows historically start with an initial congestion window of at most four segments or about 4KB of data. Because most web transactions are short-lived, the initial congestion window is a critical TCP parameter in determining how quickly flows can finish. While the Internet has sped up dramatically, TCP's initial congestion window has remained unchanged. Google has proposed to increase TCP's initial congestion window to at least ten segments, about 15KB.
Microsoft is implementing Google's suggestion. Windows 10 and Server 2016's new default value will be 10 milliseconds. IW10 default improves slow start speed over the previous default value of IW4. The net result should be small Internet data streams transported at twice their speed today.
Tail Loss Probe (TLP), another Google IETF RFC, is designed to improve TCP's latency when recovering from packet loss. TLP improves TCP recovery behavior by converting Retransmit TimeOuts (RTOs) into Fast Retransmits for much faster recovery.
TLP transmits one packet in two round-trips when a connection has outstanding data and is not receiving any ACKs. The transmitted packet (the loss probe), can be either new or a retransmission. When there is tail loss, the ACKnowledgments from a loss probe triggers Selective Acknowledgement (SACK) and Forward Acknowledgement (FACK) based fast recovery, thus avoiding a costly retransmission timeout.
In Windows, TLP is enabled only for connections that have an RTT of at least 10 milliseconds. This is to avoid spurious retransmissions for low latency connections. The most beneficial scenario for TLP is short web transfers over a wide area network.
Recent ACKnowledgement (RACK) is a Google IETF RFC that implements a new TCP loss detection algorithm. Instead of counting duplicate ACKnowledgements it looks at the packets' timestamps to see if there's data loss.
On Windows RACK will only be enabled for connections that have an RTT of at least 10 milliseconds in both Windows Client and Server 2016. This is to avoid spurious retransmissions for low latency connections. RACK is also only enabled for connections that successfully negotiate SACK.
Finally, WindowsLow Extra Delay BAckground Transport (LEDBAT) is based on IETF RFC 6817 by academics and BitTorrent. This is a delay-based congestion control algorithm that seeks to utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queuing delay on that path.
The net effect is a background transport that does not interfere with other TCP connections. Windows LEDBAT is implemented as an experimental Windows TCP Congestion Control Module (CCM).
Windows LEDBAT transfers data in the background and does not interfere with other TCP connections. LEDBAT does this by only consuming unused bandwidth. When LEDBAT detects increased latency that indicates other TCP connections are consuming bandwidth it reduces its own consumption to prevent interference. When the latency decreases again LEDBAT ramps up and consumes the unused bandwidth. This makes it ideal for BitTorrent and other low priority networks.
Overall, up-to-date Windows users should see a significant improvement in their network performance immediately. Since many of these updates are still being implemented, over time you'll see an even greater throughput boost.