LEDBAT++, or Windows LEDBAT as the Microsoft implementation is called, is yet another option to reduce the impact Windows 10, and other software distribution, will have on your network. This feature is currently available on Windows Server 2016 (July 2018 CU, KB4284833, enables the feature) or later, but does not have any client requirement (unlike some early LEDBAT docs stated), meaning it will work with both Windows 7 and Windows 10 clients.
Anyway, unlike BITS, which is used to restrict network bandwidth, LEDBAT does the opposite, it tries to use as much as bandwidth as possible, but in a way so when bandwidth is needed for something else, it becomes the good citizen and backs off until the other data transfer is completed.
ConfigMgr Integration
Starting in ConfigMgr TP 1805, there is an option to enabled LEDBAT for traffic between the DP's, and the client. The scenario is that you have a remote distribution point, and you don't want clients to overuse the bandwidth available on the WAN link. You enable LEDBAT by simply select the LEDBAT check box on the remote distribution point properties, and ConfigMgr takes care of the configuration for you.
Note: Due to a bug in TP 1805 and 1806, ConfigMgr fails to create the needed network transport rules when using Windows Server, version 1709 (Server Core). But you can configure that manually to as a workaround (see the "Known issues" section later in the post on how).
Behind the scenes
When selecting the LEDBAT check box, ConfigMgr configures the InternetCustom TCP template to use LEDBAT as it's congestionprovider, and setup transportfilter rules for port 80 and 443. You can verify this by running the following PowerShell commands:
Get-NetTCPSetting -SettingName InternetCustom | Select CongestionProvider
Get-NetTransportFilter -SettingName InternetCustomVerify LEDBAT
To verify LEDBAT, I configured two virtual networks, Seattle and Stockholm, connected via a virtual pfsense router with two NICs, and I setup limiters on 10 mbit for upload and download. The network looks like below:
First, I started an 200 MB application setup via Software Center on PC0001, waited until the download started, and then open tcpview (sysinternals).
In tcpview I saw a http download to PC0001 with a steady 10 mbit download (give or take), and I saw the percentages ticking in Software center too.
Then on PC0001, I started a normal file copy from CM02, the primary site server, which is located on the same network subnet as DP02, and then the LEDBAT magic happened:
The http download from DP02 basically suspended immediately, only a few 100 kb was transferred, but the normal file copy went ahead with full 10 mbit speed. As soon as the normal file copy was completed, the http download from my DP resumed.
Shorthand: LEDBAT is making DP02 behave like a good network citizen: When network is available, it uses all of it, but as soon as the WAN link is needed for something else it backs off.
Here is another view of it, task manager on DP02, and you can see it's traffic dropping during the file copy from CM02 to PC0001, and resume back when the copy was completed.
Known issues
As you learned earlier, due to a bug in TP 1805 and 1806, ConfigMgr fails to create the needed network transport rules when using Windows Server, version 1709. If you don't see the preceding rules being set, you can run the following commands to set them manually.
Set-NetTCPSetting -SettingName InternetCustom -CongestionProvider LEDBAT
New-NetTransportFilter -SettingName InternetCustom -LocalPortStart 80 -LocalPortEnd 80 -RemotePortStart 0 -RemotePortEnd 65535
New-NetTransportFilter -SettingName InternetCustom -LocalPortStart 443 -LocalPortEnd 443 -RemotePortStart 0 -RemotePortEnd 65535Resources
Below is Microsoft official blog for all things LEDBAT:
Support for LEDBAT: Public Service Announcement
https://techcommunity.microsoft.com/t5/networking-blog/support-for-ledbat-public-service-announcement/ba-p/339796
Enjoy! / Johan Arwidmark
Hello Johan,
One more interesting post.
Thanks for sharing
Quite interesting post. Thanks for sharing!