#LEDBAT @Win10Transports
Why don't we dive right in? What is a Congestion Provider and why do you (the reader) care?
- What is it? A Congestion Provider is an algorithm that controls the flow of data from a Windows server to a Client.
- Congestion Provider defined: Because Cubic is for humans and LEDBAT is for unattended bots.
How does that impact me? In the heart of the Windows kernel there is a networking stack. At the heart of the networking stack there is a layer called Transport and Transport contains a suite of algorithms called Congestion Providers. the data flow across the network/Internet.
Let’s take a look at the difference between the two. Cubic is optimized for throughput while LEDBAT is optimized for low-latency and non-interference. Now the picture is becoming clear. LEDBAT is for unattended bots (meaning that there is not a person actively waiting for the transaction to complete) because these bots should not interfere with human work and Cubic should be used when there is a person waiting for the transaction to complete.
Let’s take a deeper look at the difference between the two using a specific example. Suppose we have a person doing their work with a web browser and a software update that is being delivered by SCCM. The difference here is clear. The software update should be using LEDBAT so that it does not interfere with the person and the web browser should be using Cubic. With this arrangement the software update will do its work leveraging unused bandwidth and when the person with the web browser wants to use the network the software update will relinquish the network resources. This allows the software updates to proceed without interfering with the person. Use your good judgement. Applications that need to proceed without interfering with people that are working need LEDBAT. Applications that people are using to do work need Cubic.
Figure 1 -- Idealized Network Diagram
Let’s look at the idealized network diagram in the figure above. There is a TCP sender on the left and a TCP receiver on the right. The TCP sender sends packets into the network which is modeled by a single queue. Upon receiving a packet, the network devices immediately forward the packet towards its destination. If the device cannot forward the packet immediately (because it is busy forwarding a previously received packet) it will place the packet in a queue. In the figure there are four packets in the queue. If the TCP sender sends another packet at this time, then it will have to wait for the four packets in the queue to be sent. This is called queuing delay and it is what causes the behavior that irritates people.
Figure 2 -- Cubic drives the queue to saturation
Cubic tries to optimize throughput by sending packets faster and faster until one of them is dropped then it slows down and repeats the behavior. Because the sender keeps increasing the sending rate eventually the queue will be full. If a packet arrives when the queue is full then that packet must be dropped. When a packet is dropped (besides retransmitting) Cubic slows the sending rate by half (draining the queue) and repeats the process. The queue repeatedly fills and drains from this process optimizing throughput.
Figure 3 -- LEDBAT controls the queuing delay
LEDBAT (shown in the Figure above) tries to optimize throughput just like Cubic by sending packets faster and faster. However, LEDBAT also keeps track of the queuing delay (lagginess ). When the lagginess increases too much LEDBAT slows down and drains the queue. This accomplishes two things. LEDBAT keeps the queuing delay lower and since Cubic drives the queue past LEDBAT’s delay threshold LEDBAT will always defer the network resources to Cubic. In other words, LEDBAT will use all of the network resources unless Cubic is using them.
This makes the perfect combination. Your background tasks such as software updates, backup, etc. can cruise along doing their work while the network is not in use and when a person hops on the network to do their work the LEDBAT tasks will get out of the way. Let’s use our person with their Edge web browser using Cubic and our software updates using LEDBAT as an example again to see how this works.
What makes this combination work so well is that humans and computers are opposite. The person using the web browser clicks on a few things and impatiently waits for the network to deliver them. This needs to be done as quickly as possible because even a few seconds can be painful and frustrating to a person. However, once the human has their content, they spend a great deal of time reading and looking at pictures. During this time, they are consuming their content and not really using the network at all.
This is what makes the combination awesome! Computers don’t get frustrated and they react very quickly. So, we have our software update proceeding nicely at full speed and then along comes a human who is in need of their information immediately, so they hit their Edge web browser clickity, clickity, clack, click, click, clack! The LEDBAT controller operating the software update download notices the increase in queuing delay (remember the figures?) and gets out of the way right away. The person gets their stuff immediately and happily begins consuming the information. While they are doing that the LEDBAT controller notices the unused network resources and downloads some more data. The person decides that they need more stuff and click away at their web browser and so on. The perfect team!
So, what are your action items here? If you are running a client just get the latest Windows 10 update and you will have Cubic by default. If you have Windows Server 2019 same thing. Cubic is already the default Congestion Provider. If you are running Windows Server 2016 Cubic is not default, but you can fix that by running Windows Update and this powershell:
This is what the default templates look like:
PS C:Usersdahavey> Get-NetTCPSetting | Select SettingName, CongestionProvider, AutomaticUseCustom SettingName CongestionProvider AutomaticUseCustom ----------- ------------------ ------------------ Automatic InternetCustom. CTCP Disabled DatacenterCustom. DCTCP Disabled Compat NewReno Disabled Datacenter DCTCP Disabled Internet CTCP Disabled
We can only change the Custom templates, so we need to make the server use the custom templates. Changing AutomaticUseCustom to Enabled will do this for us:
PS C:Usersdahavey> Set-NetTCPSetting -SettingName InternetCustom -AutomaticUseCustom Enabled PS C:Usersdahavey> Get-NetTCPSetting | Select SettingName, CongestionProvider, AutomaticUseCustom SettingName CongestionProvider AutomaticUseCustom ----------- ------------------ ------------------ Automatic InternetCustom CTCP Enabled DatacenterCustom DCTCP Enabled Compat NewReno Enabled Datacenter DCTCP Enabled Internet CTCP Enabled
Hey, they all changed even though I only changed the InternetCustom template! Yes, AutomaticUseCustom is an all or nothing setting.
Now we need to change the templates Congestion Provider to Cubic! SettingName CongestionProvider AutomaticUseCustom ----------- ------------------ ------------------ Automatic InternetCustom CUBIC Enabled DatacenterCustom CUBIC Enabled Compat NewReno Enabled Datacenter DCTCP Enabled Internet CTCP Enabled
And now we are a Cubic server just like WS 2019!
If you want to use LEDBAT then see the instruction (“Try it out!” link) in my LEDBAT blog: Top 10 Networking Features in Windows Server 2019: #9 LEDBAT – Latency Optimized Background Transport
Thanks for reading!