By
Published
Feb 14 2019 10:02 AM
11.5K
Views
First published on TECHNET on Jul 10, 2018
Authors: Praveen Balasubramanian, Daniel Havey
Windows core networking team has been introducing innovations in transport and blogging about it since the Anniversary Edition . We do this because we are committed to providing continuous performance improvements, better security, reliability, battery life and diagnostics as well as making Windows a better member of the Internet community. Here is a summary for Fall Creators Update:
LEDBAT for Windows is an inbox experimental non-interference technology designed to keep heavy workflows (such as system updates) from interfering with normal network usage. LedBat has a great deal of capabilities not found in other non-interference technologies because it is a kernel level transport flow control.
In addition to our original testing of LedBat on the WAN (Figure 1 lower left) we are in the process of testing LedBat on the LAN. The test topology is shown at the top of Figure 1. A system connected to Microsoft corpnet provides the test workloads. There are 10 bulk traffic loads transported with LedBats shown in blue and one regular workload transported with Cubic TCP and shown in orange. Some preliminary results are shown in the lower left-hand corner of Figure 1. The 10 buld data flows using LedBats start first and use all of the available bandwidth. Every 10 seconds a regular workflow is started using TCP Cubic. The results speak for themselves. All 10 LedBats are out of the way immediately one the regular workflow starts and when it is done the 10 LedBats return to full utilization of the link. We encourage data transport professionals and Creators to join us in experimentation. For more details join the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
Figure 1 -- LEDBAT Testbed Topologies in Redmond
Figure 2 -- Windows Pluggable CC Algorithms
TCP Cubic is the latest addition to Windows pluggable Congestion Control (CC) algorithm modules bringing the total to 4. Figure 2 is a chart to help describe the passive aggressive range of CC alg options. All CC algs attempt to take their min max fair share of the network bandwidth. However, some algs are more aggressive than others about it. More aggressive algs such as Cubic are placed in the upper left quadrant because they tend to grab a little more of their bandwidth share and create a little extra latency with their aggressive behavior. Less aggressive algs such as New Reno are towards the lower right quadrant. New Reno creates less latency, but, will lose a little bandwidth in competition with more aggressive algs. Notice that LedBat looks a little different from the other algs and is placed separately from them. This is because LedBat is a specialized CC algorithm that is designed to “not compete” with other algs. LedBat’s distribution is bi-modal being in the upper right quadrant (high throughput/low latency) except when in competition with an “aggressive” algorithm. For more details join the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
TCP Fast Open is a latency reducing technology that achieves zero RTT TCP connections using secure TFO Cookies in the TCP options field. The problem is that middleboxes sometimes do not understand the TFO Cookie option even though it is well documented in RFC 7413 . These misguided middleboxes mangle TCP connections tampering with TCP connection semantics and distorting or destroying the TCP connection. Because of this questionable behavior no browser has been able to deploy TFO "on by default". Until now! Using Windows TCP fallback algorithm the Edge browser has successfully deployed TCP Fast Open and Edge users are able to enjoy zero RTT TCP connections. For more details join the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
Figure 3 -- TCP Fast Open on the Datapath with Windows TCP Fallback
TCP and UDP data path upgrades including software Receive Side Coalescing (RSC) have nearly doubled throughput for both UDP and TCP send/receive data paths. This data was collected using microbenchmarks and inhouse (Redmond) testbeds.
We invite you to join us in this journey of Windows Networking development and experimentation by following the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
Works Cited:
[1] Y. Cheng et al, "RFC: 7413: TCP Fast Open," December 2014. [Online]. Available: https://tools.ietf.org/html/rfc7413
[2] S. Shalunov et al, "RFC 6817 Low Extra Delay Background Transport (LEDBAT)," December 2012. [Online]. Available: https://tools.ietf.org/html/rfc6817
[3] S. Ha et al, "CUBIC: A New TCP-friendly High-speed TCP Variant"," July 2008
Authors: Praveen Balasubramanian, Daniel Havey
Windows core networking team has been introducing innovations in transport and blogging about it since the Anniversary Edition . We do this because we are committed to providing continuous performance improvements, better security, reliability, battery life and diagnostics as well as making Windows a better member of the Internet community. Here is a summary for Fall Creators Update:
- LEDBAT for background connections IETF RFC 6817 [2]
- TCP Cubic [3], [4]
- TCP Fast Open (TFO) for zero RTT TCP connection setup. IETF RFC 7413 [1]
- Software Receive Side Coalescing
LEDBAT for Windows is an inbox experimental non-interference technology designed to keep heavy workflows (such as system updates) from interfering with normal network usage. LedBat has a great deal of capabilities not found in other non-interference technologies because it is a kernel level transport flow control.
- LedBat can sense and adapt to network data flows from any other systems anywhere on the network.
- LedBat is topologically agnostic . It will find and measure the loading characteristics of the bottleneck link in any network equipment.
- LedBat is faster and more efficient than technologies based on non-transport layer flow control techniques.
In addition to our original testing of LedBat on the WAN (Figure 1 lower left) we are in the process of testing LedBat on the LAN. The test topology is shown at the top of Figure 1. A system connected to Microsoft corpnet provides the test workloads. There are 10 bulk traffic loads transported with LedBats shown in blue and one regular workload transported with Cubic TCP and shown in orange. Some preliminary results are shown in the lower left-hand corner of Figure 1. The 10 buld data flows using LedBats start first and use all of the available bandwidth. Every 10 seconds a regular workflow is started using TCP Cubic. The results speak for themselves. All 10 LedBats are out of the way immediately one the regular workflow starts and when it is done the 10 LedBats return to full utilization of the link. We encourage data transport professionals and Creators to join us in experimentation. For more details join the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
Figure 1 -- LEDBAT Testbed Topologies in Redmond
Figure 2 -- Windows Pluggable CC Algorithms
TCP Cubic is the latest addition to Windows pluggable Congestion Control (CC) algorithm modules bringing the total to 4. Figure 2 is a chart to help describe the passive aggressive range of CC alg options. All CC algs attempt to take their min max fair share of the network bandwidth. However, some algs are more aggressive than others about it. More aggressive algs such as Cubic are placed in the upper left quadrant because they tend to grab a little more of their bandwidth share and create a little extra latency with their aggressive behavior. Less aggressive algs such as New Reno are towards the lower right quadrant. New Reno creates less latency, but, will lose a little bandwidth in competition with more aggressive algs. Notice that LedBat looks a little different from the other algs and is placed separately from them. This is because LedBat is a specialized CC algorithm that is designed to “not compete” with other algs. LedBat’s distribution is bi-modal being in the upper right quadrant (high throughput/low latency) except when in competition with an “aggressive” algorithm. For more details join the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
TCP Fast Open is a latency reducing technology that achieves zero RTT TCP connections using secure TFO Cookies in the TCP options field. The problem is that middleboxes sometimes do not understand the TFO Cookie option even though it is well documented in RFC 7413 . These misguided middleboxes mangle TCP connections tampering with TCP connection semantics and distorting or destroying the TCP connection. Because of this questionable behavior no browser has been able to deploy TFO "on by default". Until now! Using Windows TCP fallback algorithm the Edge browser has successfully deployed TCP Fast Open and Edge users are able to enjoy zero RTT TCP connections. For more details join the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
Figure 3 -- TCP Fast Open on the Datapath with Windows TCP Fallback
TCP and UDP data path upgrades including software Receive Side Coalescing (RSC) have nearly doubled throughput for both UDP and TCP send/receive data paths. This data was collected using microbenchmarks and inhouse (Redmond) testbeds.
We invite you to join us in this journey of Windows Networking development and experimentation by following the Windows 10 discussion group at: mailto:Win10talk@microsoft.com
Works Cited:
[1] Y. Cheng et al, "RFC: 7413: TCP Fast Open," December 2014. [Online]. Available: https://tools.ietf.org/html/rfc7413
[2] S. Shalunov et al, "RFC 6817 Low Extra Delay Background Transport (LEDBAT)," December 2012. [Online]. Available: https://tools.ietf.org/html/rfc6817
[3] S. Ha et al, "CUBIC: A New TCP-friendly High-speed TCP Variant"," July 2008