Jump straight to the issue: https://youtu.be/ad-lsbhb5xM?si=LKsVm7iUBSg-1u5x
74 karma · joined March 27, 2018
What we’re doing is slightly different though. We’re not only reacting to signal strength or a broken connection. Because we have multiple active paths, we can also move real-time traffic away from a Wi-Fi path that is still connected but has temporarily become bad - for example because that AP is congested or somebody else is consuming a lot of airtime.
So even if the roaming itself is perfect, you can still have a path that is technically connected but no longer able to meet the latency budget.
Another advantage is that this doesn’t depend on the AP infrastructure supporting fast roaming or coordination features. It works above the Wi-Fi layer, and the same mechanism can also combine Wi-Fi with completely different networks such as 5G or Starlink.
On the three interfaces: others have pointed that out too, and we’ll try to make it clearer in the article. In this test the laptop had three Wi-Fi adapters, each pinned to a different AP. There’s nothing particularly special about three though - with two adapters connected to two different APs you should already be able to get a lot of the benefit.
On the IP side, the overlay works a bit like a VPN. Traffic is sent over all the available interfaces to software on the other side, which combines the paths and presents a normal IP stream towards the final destination. Encryption isn’t the primary purpose here - the main goal is making the connection more robust - although encryption can of course be added.
The pinned-AP comparison is a fair criticism. For this demo we deliberately kept each interface associated with one AP because we wanted to isolate the effect of using several paths at once, rather than also introducing the behaviour of the Wi-Fi roaming implementation into the test. Comparing against normal roaming, including 802.11k/v/r, is definitely something we want to test next.
We want to experiment with a small daemon that keeps the different Wi-Fi interfaces associated with different APs. If one drops out, it can reassociate that interface with another available AP, so in principle you can move through a much larger Wi-Fi deployment while still maintaining multiple active paths.
We haven’t done a proper comparison against Wi-Fi 7 MLO yet, but that would be a very interesting comparison. Conceptually there is definitely some overlap, although our approach sits above the individual Wi-Fi link and can also combine completely different networks.
In this particular test, the laptop had three Wi-Fi adapters, one connected to each AP. You should still see benefits with just two independent Wi-Fi connections, but for the results shown here we used three.
The problem we wanted to look at was roaming. Even when you have good Wi-Fi coverage, moving between access points can cause short interruptions that are long enough to matter for a real-time application.
Instead of relying on a single Wi-Fi connection and hoping the handover is fast enough, we tested our overlay multi-connectivity transport using three Wi-Fi access points at the same time.
The transport can use all three paths simultaneously, so a roaming event or temporary interruption on one connection doesn’t necessarily interrupt the stream.
We’re still digging into the results, but it’s an interesting way of thinking about Wi-Fi reliability: rather than trying to make one connection perfect, use several imperfect ones together.
Did that make sense?
In the article we simply show that substituting one "old" algorithm for a more modern one can give you much better efficiency (protection against packet loss) for the same bandwidth and latency/delay budget.