Administrators may not be familiar with the Cubic congestion control provider, but Microsoft’s move to make this the default setting in the Windows networking stack means IT will need to learn how it works and how to manage it.
When Microsoft released Windows Server version 1709 in its Semi-Annual Channel, the company introduced a number of features, such as support for data deduplication in the Resilient File System and support for virtual network encryption.
Microsoft also made the Cubic algorithm the default congestion control provider for that version of Windows Server. The most recent preview builds of Windows 10 and Windows Server 2019 (Long-Term Servicing Channel) also enable Cubic by default.
Microsoft added Cubic to Windows Server 2016, as well, but it calls this implementation an experimental feature. Due to this disclaimer, administrators should learn how to manage Cubic if unexpected behavior occurs.
Why Cubic matters in today’s data centers
Congestion control mechanisms improve performance by monitoring packet loss and latency and making adjustments accordingly. TCP/IP limits the size of the congestion window and then gradually increases the window size over time. This process stops when the maximum receive window size is reached or packet loss occurs. However, this method hasn’t aged well with the advent of high-bandwidth networks.
For the last several years, Windows has used Compound TCP as its standard congestion control provider. Compound TCP increases the size of the receive window and the volume of data sent.
Cubic, which has been the default congestion provider for Linux since 2006, is a protocol that improves traffic flow by keeping track of congestion events and dynamically adjusting the congestion window.
A Microsoft blog on the networking features in Windows Server 2019 said Cubic performs better over a high-speed, long-distance network because it accelerates to optimal speed more quickly than Compound TCP.
Enable and disable Cubic with netsh commands
Microsoft added Cubic to later builds of Windows Server 2016. You can use the following PowerShell command to see if Cubic is in your build:
Get-NetTCPSetting| Select-Object SettingName, CcongestionProvider
Technically, Cubic is a TCP/IP add-on. Because PowerShell does not support Cubic yet, admins must enable it in Windows Server 2016 from the command line with the netsh command from an elevated command prompt.
Netsh uses the concepts of contexts and subcontexts to configure many aspects of Windows Server’s networking stack. A context is similar to a mode. For example, the netsh firewall command places netsh in a firewall context, which means that the utility will accept firewall-related commands.
Microsoft added Cubic-related functionality into the netsh interface context. The interface context — abbreviated as INT in some Microsoft documentation — provides commands to manage the TCP/IP protocol.
Prior to Windows Server 2012, admins could make global changes to the TCP/IP stack by referencing the desired setting directly. For example, if an administrator wanted to use the Compound TCP congestion control provider — which was the congestion control provider since Windows Vista and Windows Server 2008 — they could use the following command:
netsh int tcp set global congestionprovider=ctcp
Newer versions of Windows Server use netsh and the interface context, but Microsoft made some syntax changes in Windows Server 2012 that carried over to Windows Server 2016. Rather than setting values directly, Windows Server 2012 and Windows Server 2016 use supplemental templates.
In this example, we enable Cubic in Windows Server 2016:
netsh int tcp set supplemental template=internet congestionprovider=cubic
This command launches netsh, switches to the interface context, loads the Internet CongestionProvider template and sets the congestion control provider to Cubic. Similarly, we can switch from the Cubic provider to the default Compound congestion provider with the following command:
netsh int tcp set supplemental template=internet congestionprovider=compound