Here is a new post by guest blogger Daniel Olsson @danielolsson100 covering a quite exciting network feature in Windows 10 and Windows Server 2016. Take it away Daniel (and thanks). / Johan
So what is LEDBAT?
LEDBAT stands for Low Extra Delay Background Transport, and it is an algorithm that is used within the TCP stack in Windows 10 and Server 2016. The goal is to better utilize the available bandwidth on WAN/Internet traffic when it's not used by anyone else.
Microsoft describes LEDBAT pretty good
"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."
Why is it so interesting with ConfigMgr?
The short answer is content replication. LEDBAT works with standard DPs (TCP traffic, traditionally throttled by ConfigMgr Sender) and with BITS ( Background Intelligent Transfer Service) which ConfigMgr use to do content replication to Pull DPs.
So if you have a lot of DP:s worldwide then you can do the "old school traffic shaping" on the DP as before (see below), or you can configure it to use all available bandwidth, and put a more modern traffic shaper in place.
Update October 8, 2018: Starting with ConfigMgr 1806, there is now an option to enable LEDBAT between the DP and the clients. However this post focus on the traffic between the site server and the DPs.
When using LEDBAT for Site Server to DP traffic, you don't need to configure ConfigMgr rate limits at all to limit traffic between site server and DPs, (see below), but rather let LEDBAT handling the control.
LEDBAT requires Windows Server 2016 with July CU installed (or later), and all you need to do is to run some PowerShell commands, so that the traffic from ConfigMgr site server to the DP is using LEDBAT instead. Again, note that ConfigMgr since 1806 have an option to also use LEDBAT to control traffic between DPs and Clients.
# Define InternetCustom profile to use LEDBAT as CongestionProvider
Set-NetTCPSetting -SettingName "InternetCustom" -CongestionProvider LEDBAT
# Set the LEDBAT filter to only apply for specific DP:s
New-NetTransportFilter -SettingName InternetCustom -DestinationPrefix 172.16.21.47/32
New-NetTransportFilter -SettingName InternetCustom -DestinationPrefix 172.16.42.16/32
If you have one ConfigMgr server/DP and the rest of the devices are over WAN ? Then apply one PowerShell line to run all traffic within the LEDBAT TCP flow
New-NetTransportFilter -SettingName InternetCustom -DestinationPrefix 172.16.0.0/16
Finally, transport filter does not apply to existing traffic so do a reboot on the ConfigMgr site server.
Notes from the real world (enterprise customer test, large retail chain)
In early testing (2017), the LEDBAT algorithm seems to work best in traditional WAN scenarios, we got some great results for the ConfigMgr to remote DPs traffic. We are still investigating it's behavior in LAN areas with very low latency (close to 0), where it did not behave very well. This will hopefully be fixed in the final release, in one of the upcoming versions of the windows Server 2016 operating system.
Also note that if you implement LEDBAT in networks when the WAN links are already fully used, meaning when you have like 0 kb bandwidth available .well… Then the LEDBAT TCP traffic will politely wait until there is free bandwidth available, and that might take a very long time:)
Update October 8, 2018: Using the InternetCustom template instead of the DatacenterCustom template solves the above issue when using LEDBAT on a LAN.
In the best of worlds
Add LEDBAT / BranchCache to your ConfigMgr environment, where it's applicable, to use more bandwidth without interfering with normal TCP traffic
Need to learn more?
That's all for me, thanks for reading