Mesh Wi-Fi Mashup

[Phasenoise]

Question is why does eero only do AC1200?

I believe they say most of their customers are using it for internet access, which will almost never be constrained by AC1200.

 

[L&LD]

I believe they say most of their customers are using it for internet access, which will almost never be constrained by AC1200.

That's a false assumption on their part.

That would depend on their actual network usage and their ISP provided speeds.

 

[sfx2000]

From the article

But the big takeaway is what Wi-Fi pros already know: wireless hops can really eat up throughput. So no matter which mesh wireless system you choose, be prepared to experiment with node locations. Unfortunately, only Amplifi provides signal strength information to guide mesh node placement and also provides a clear indication of how nodes are connected. With the others, you're on your own to devise your own methods to determine best node placement. Let's hope vendors improve the situation, because it's clear mesh node placement matters...a lot!

As noted in the past, when I was independent and doing research - I was one of the technical founders of an early stage startup looking at MESH and opportunistic routing - I was brought onboard based on experience with designing AP's and strong standards experience (in case some of the ideas worked, the objective was two fold - patent/license the tech, and get it into the various IEEE/IETF standards)

We got as far as building a couple of very large test ranges and we explored different concepts - we rolled it up as WiFi at the time, wasn't working as well as expected. We went pretty deep into the stack, and without making significant changes to how 802.11 works at a based level...

MESH is really hard stuff, and single radio MESH points are doubly hit, moreso even than WiFi extenders because of the overhead - at the end of the day, it doesn't scale very well, but 3 nodes can work with a dual radio solution.

The Eero solution, IMHO, does make more sense, as one can have a mesh "backhaul" that only carries traffic from AP to AP, and let the other radios handle the Client to AP traffic - but even then, overhead increases in a non-linear curve with the number of MESH points - this is likely the reason why EERO sells 3 packs, as this is a bit of a limit unless one can take the time to really map out coverage zones, which is out of scope for the consumer market...

However - I do believe that Eero at present probably has one of the better solutions out there for small scale meshes at the moment - but it's hard to compete against a hub-spoke traditional multiple AP solution backhauled by Ethernet as the distribution system, and whether fully or semi coordinated by either a WLC or common configution (e.g. common SSID/credentials as part of an 802.11 Extended Service Set (ESS))

Looking back - 802.11 MU-MIMO has some benefits that can be leveraged with Mesh topologies - I don't want to get too in-depth, but if one does look at how MU works, there is benefit with Mesh, and it's a strong benefit to reduce some overhead on the channel - MU as it stands at present isn't a perfect solution (e.g. MU is downlink only, not bidirectional), but considering how asymmetric traffic is, it's not as big of a deal as it sounds..

 

[thiggins]

Question is why does eero only do AC1200?

Cost concerns (or maximizing margin). With the majority of devices being 1x1 or 2x2, it's a reasonable choice.

Amplifi is the only one of the test group with a 3x3 design. Both standard and HD are a 3x3 AC design for the router. Standard Amplifi "mesh points" are 3x3 N; HD are AC.

Ubiquiti was unhappy with the results and complained that I should have tested with a 3x3 STA. That would have been unfair to the 2x2 products. Besides, nothing is stopping Amplifi from using 3x3 for backhaul connections. If 3x3 provided advantage for backhaul, testing should have showed it.

 

[Afullhrey]

From the article



As noted in the past, when I was independent and doing research - I was one of the technical founders of an early stage startup looking at MESH and opportunistic routing - I was brought onboard based on experience with designing AP's and strong standards experience (in case some of the ideas worked, the objective was two fold - patent/license the tech, and get it into the various IEEE/IETF standards)

We got as far as building a couple of very large test ranges and we explored different concepts - we rolled it up as WiFi at the time, wasn't working as well as expected. We went pretty deep into the stack, and without making significant changes to how 802.11 works at a based level...

MESH is really hard stuff, and single radio MESH points are doubly hit, moreso even than WiFi extenders because of the overhead - at the end of the day, it doesn't scale very well, but 3 nodes can work with a dual radio solution.

The Eero solution, IMHO, does make more sense, as one can have a mesh "backhaul" that only carries traffic from AP to AP, and let the other radios handle the Client to AP traffic - but even then, overhead increases in a non-linear curve with the number of MESH points - this is likely the reason why EERO sells 3 packs, as this is a bit of a limit unless one can take the time to really map out coverage zones, which is out of scope for the consumer market...

However - I do believe that Eero at present probably has one of the better solutions out there for small scale meshes at the moment - but it's hard to compete against a hub-spoke traditional multiple AP solution backhauled by Ethernet as the distribution system, and whether fully or semi coordinated by either a WLC or common configution (e.g. common SSID/credentials as part of an 802.11 Extended Service Set (ESS))

Looking back - 802.11 MU-MIMO has some benefits that can be leveraged with Mesh topologies - I don't want to get too in-depth, but if one does look at how MU works, there is benefit with Mesh, and it's a strong benefit to reduce some overhead on the channel - MU as it stands at present isn't a perfect solution (e.g. MU is downlink only, not bidirectional), but considering how asymmetric traffic is, it's not as big of a deal as it sounds..

Great post. any thoughts on what Plume Wifi are saying here:

"Since traditional mesh systems use the same backhaul channel, every hop between source points divides the network capacity by the number of hops taken to deliver your data. So if it takes 3 hops to stream a video to your phone, you’ll be left with only 1/3 the capacity (AKA slower speeds). Plume uses a different channel or band for each hop, never slowing down your WiFi speed."

What do you think of their concept of one in every room?

 

[thiggins]

What do you think of their concept of one in every room?

SFX: I'll let you respond...

 

[L&LD]

Great post. any thoughts on what Plume Wifi are saying here:

"Since traditional mesh systems use the same backhaul channel, every hop between source points divides the network capacity by the number of hops taken to deliver your data. So if it takes 3 hops to stream a video to your phone, you’ll be left with only 1/3 the capacity (AKA slower speeds). Plume uses a different channel or band for each hop, never slowing down your WiFi speed."

What do you think of their concept of one in every room?

I'm positive that sfx2000 will explain it better and more succinctly, but this is the very reason I have a problem with 'mesh', no matter the implementation.

The problem is that there are too many WiFi radios all around us. The most obnoxious ones are the Shaw Go and similar ISP 'open networks' that are not open to anyone without a subscription to them but still interfere and slow down our own (secure) networks.

How will using every single channel available in every single home/apt./office not impact everyone else?

This is a disaster waiting to happen, imo.

But by that point, they'll have collected their bags of cash and will reveal their latest product. A single router that can cover an entire home. Line starts on the left.

 

[Afullhrey]

I'm positive that sfx2000 will explain it better and more succinctly, but this is the very reason I have a problem with 'mesh', no matter the implementation.

The problem is that there are too many WiFi radios all around us. The most obnoxious ones are the Shaw Go and similar ISP 'open networks' that are not open to anyone without a subscription to them but still interfere and slow down our own (secure) networks.

How will using every single channel available in every single home/apt./office not impact everyone else?

This is a disaster waiting to happen, imo.

But by that point, they'll have collected their bags of cash and will reveal their latest product. A single router that can cover an entire home. Line starts on the left.

From Plume's site: "Plume recognizes usage patterns on all your devices, and also remembers the routine behavior of interfering WiFi networks (like your neighbor’s Sunday football parties). Plume continuously tunes the network to deliver an uninterrupted experience for everyone, all the time."

I guess that's why they patented and termed what they call 'Adaptive wifi'.

 

[L&LD]

From Plume's site: "Plume recognizes usage patterns on all your devices, and also remembers the routine behavior of interfering WiFi networks (like your neighbor’s Sunday football parties). Plume continuously tunes the network to deliver an uninterrupted experience for everyone, all the time."

I guess that's why that patented and termed what they call 'Adaptive wifi'.

From experience: Don't believe in marketing when the science hints otherwise.

In other words, when it does interfere, it will switch itself down to the level of other mesh networks, huh?

 

[sfx2000]

Ubiquiti was unhappy with the results and complained that I should have tested with a 3x3 STA. That would have been unfair to the 2x2 products. Besides, nothing is stopping Amplifi from using 3x3 for backhaul connections. If 3x3 provided advantage for backhaul, testing should have showed it.

2*2 STA's are the new "norm" - so I think the tests were totally valid...

 

[sfx2000]

With regards to Plume and the micro-AP mesh implementation - it's too soon to tell honestly - I think they also recognize the challenges that Mesh has, and I'm sure they have developed something around it...

I'd be happy to collaborate with Tim when they're available for test/review as needed.

 

[thiggins]

With regards to Plume and the micro-AP mesh implementation - it's too soon to tell honestly - I think they also recognize the challenges that Mesh has, and I'm sure they have developed something around it...

Thanks for weighing in.

The concept is nice, but implementation will be very challenging. Don't forget that devices will be attached to at least some of those nodes, too. If a device is associated with a middle node and streaming video, that takes bandwidth away from backhaul use. More nodes means more airtime overhead to keep track of link performance. I would not assume Plume or anyone has come up with a secret sauce to solve mesh complexity.

Implementations are still works in progress. Some are doing band steering, few are doing load sharing / node steering. And who knows how often links are being monitored for network tuning.

 

[sfx2000]

I'm positive that sfx2000 will explain it better and more succinctly, but this is the very reason I have a problem with 'mesh', no matter the implementation.

The problem is that there are too many WiFi radios all around us. The most obnoxious ones are the Shaw Go and similar ISP 'open networks' that are not open to anyone without a subscription to them but still interfere and slow down our own (secure) networks.

How will using every single channel available in every single home/apt./office not impact everyone else?

This is a disaster waiting to happen, imo.

But by that point, they'll have collected their bags of cash and will reveal their latest product. A single router that can cover an entire home. Line starts on the left.

Airtime on WiFi is only part of the challenge - the other challenge is the networking side, which may be overlooked - MESH is very dynamic, and which path across the hops on the network layer can seriously improve or impact the network layers and above.

To that end - there's over 70 related routing protocols around MESH... a short list below - and each has strengths and weaknesses with regards to scalability... the work we did was around spatial relationships and time-vectors, and it performed well to a certain extent, but again, we also started running into scalability... both with single frequency networking, along with channel agility - we did sort out some of the challenges, and as part of the rollup of the venture, the IP we developed was sold off, and everyone came out of it a bit smarter, and with a nice little chunk of change - not every startup goes commercial...

MESH starts to run, quite literally, out of time - as we have to manage both the MESH nodes, along with the client stations that are attempting to attach and use (to them) an Access Point.

There's only so much one can do within the 802.11 protocol stack - as it must be assumed that the clients are not aware of the backend for interop purposes...

A short list of the more successful routing protocols out there for MESH - IEEE 802.11s mostly focused around AODV and OSLR, but the others also attempt to mitigate some of the shortcomings...

• AODV (Ad hoc On-Demand Distance Vector)
• B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking)
• Babel (protocol) (a distance-vector routing protocol for IPv6 and IPv4 with fast convergence properties)
• DNVR (Dynamic NIx-Vector Routing)
• DSDV (Destination-Sequenced Distance-Vector Routing)
• DSR (Dynamic Source Routing)
• HSLS (Hazy-Sighted Link State)
• HWMP (Hybrid Wireless Mesh Protocol)
• IWMP (Infrastructure Wireless Mesh Protocol) for Infrastructure Mesh Networks by GRECO UFPB-Brazil
• Wireless mesh networks routing protocol (MRP) by Jangeun Jun and Mihail L. Sichitiu
• OLSR (Optimized Link State Routing protocol)
• OORP (OrderOne Routing Protocol) (OrderOne Networks Routing Protocol)
• OSPF (Open Shortest Path First Routing)
• Routing Protocol for Low-Power and Lossy Networks (IETF ROLL RPL protocol, RFC 6550)
• PWRP (Predictive Wireless Routing Protocol)
• TORA (Temporally-Ordered Routing Algorithm)
• ZRP (Zone Routing Protocol)

 

[sfx2000]

Thanks for weighing in.

The concept is nice, but implementation will be very challenging. Don't forget that devices will be attached to at least some of those nodes, too. If a device is associated with a middle node and streaming video, that takes bandwidth away from backhaul use. More nodes means more airtime overhead to keep track of link performance. I would not assume Plume or anyone has come up with a secret sauce to solve mesh complexity.

Implementations are still works in progress. Some are doing band steering, few are doing load sharing / node steering. And who knows how often links are being monitored for network tuning.

I agree - and your testing shows both the strengths and weaknesses of MESH - it _can_ work.. and perhaps with some of the more interesting silicon implementations that we see these days with 802.11ac (and esp. the Wave 2 silicon and firmware), things might be better than they were when we works with older revisions of the 802.11n chipsets...

Like I mentioned earlier, this is a tough problem to solve, and in many ways, just as challenging, if not more, than MU-MIMO...

But the MU-MIMO problem has been solved to some degree - some implementations more than others, and I figure MESH might be solved in a similar manner as well...

It's all on how it's sold to the customer - MU wasn't about speed, it was around capacity, MESH can leverage in to that at some levels on the Wireless Link, but the devil's job in MESH is not WiFi - it's the routing inside the MESH and trying to squeeze efficiency out of it... because time is the fire in which networking burns, and MESH takes a lot of time...

 

[sfx2000]

One of the other big challenges with MESH is the issue of Trust... e.g. Authentication and Authorization - in a mesh, you have, by design, agents in the middle - how can they be trusted, and how can credentials move around inside that mesh - and that was a hard problem to solve - which we did find a solution for actually...

Let's just say that blockchains are for more than just Electronic Currency

So routing was one problem, and the trust relationships were the second... and the trust relationship ended up being a really big problem, as again, we couldn't change how WiFi authenticates... but we still needed to establish and maintain trust at any point - including the scenario/user story where ALICE moves from NODE A to NODE B, and the relationship between these two nodes is unknown...

 

[Afullhrey]

One of the other big challenges with MESH is the issue of Trust... e.g. Authentication and Authorization - in a mesh, you have, by design, agents in the middle - how can they be trusted, and how can credentials move around inside that mesh - and that was a hard problem to solve - which we did find a solution for actually...

Let's just say that blockchains are for more than just Electronic Currency

So routing was one problem, and the trust relationships were the second... and the trust relationship ended up being a really big problem, as again, we couldn't change how WiFi authenticates... but we still needed to establish and maintain trust at any point - including the scenario/user story where ALICE moves from NODE A to NODE B, and the relationship between these two nodes is unknown...

All of your posts and @thiggins have been fascinating. Thanks.

 

[sfx2000]

All of your posts and @thiggins have been fascinating. Thanks.

thank you - it's been fun to share - it's not a blog post like some vendors - but I've tried to share some insight as to what our startup and myself discovered...

One other aspect - building up a startup is really a cultural thing as well - outside of myself, being in San Diego, the other partners were all up in the Valley, and we did run into a few issues - I built a team here in SD to deal with the technology/wireless issues, and the Valley team was about rinse/lather/repeat - throwing ideas on the wall and see what sticks...

I joined as a principal engineer - I ended up being interim-CTO on that team, going in as a tech cofounder, and I looked out for my crew down in San Diego, but the dynamics were very tough to deal with - no regrets - Learned much, we built good stuff, got paid, and I did inherit one of the two ranges we built for MESH testing (mostly because the land it was built on was in our family trust)...

I'm not sure I would do a SV startup again, it would really depend on the team, and the dynamics...

 

[whsbuss]

2*2 STA's are the new "norm" - so I think the tests were totally valid...

That is true for now but I think Ubnt wants to change that with their HD model.

 

[thiggins]

That is true for now but I think Ubnt wants to change that with their HD model.

I think SFX was referring to DEVICES, not APs or mesh routers.

 

[pete y testing]

i agree that in this case the review is based on comparison , so the testing method should be the fixed point and tim has chosen 2 x 2 as his fixed point and there is certainly nothing wrong with that in comparison testing as its the only known non variable , its also the only non variable that is the best standard of all units under test

sure if you where reviewing the ubiquiti HD unit on its own you would test with 3 x 3 to gain its max capability but then it becomes some what of a pissing contest as only those with 3 x 3 clients will see those figures and as stated more and more portable devices are 2 x 2 AC at best

pete