On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun <[email protected]> wrote:
> On Sun, Feb 1, 2015 at 9:43 AM, <[email protected]> wrote:
>> Just to clarify, managing queueing in a single access point WiFi network is
>> only a small part of the problem of fixing the rapidly degrading performance
>> of WiFi based systems.
>
> Can you explain what you mean by "rapidly degrading?" The performance
> in odd situations is certainly not inspirational, but I haven't
> noticed it getting worse over time.
>
>> Similarly, mesh routing is only a small part of the
>> problem with the scalability of cooperative meshes based on the WiFi MAC.
>
> That's certainly true. Not to say the mesh routing algorithms are
> much good either.
>
>> Also, as we noted
>> earlier, "handoff" from one next hop to another is a huge problem with
>> performance in practical deployments (a factor of 10x at least, just in
>> that).
>
> While there is definitely some work to be done in handoff, it seems
> like there are some find implementations of this already in existence.
> Several brands of "enterprise access point" setups seem to do well at
> this. It would be nice if they interoperated, I guess.
>
> The fact that there's no open source version of this kind of handoff
> feature bugs me, but we are working on it here and the work is all
> planned to be open source, for example: (very early version)
> https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/
We've got an SDN-inspired architecture with 802.11 frame tunneling (a
la CAPWAP), airtime fairness, infrastructure initiated hand-over,
Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and
a few more goodies. It's currently free as in beer
(http://anyfi.net/software,
https://github.com/carrierwrt/carrierwrt/pull/7 and
http://www.anyfinetworks.com/download) up to 100 APs, but we're
definitely going to open source in one form or another.
We've also tried to raise some interest in fixing up CAPWAP
(https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html),
which is (unfortunately) the best open standard at the moment.
Interest seems marginal though...
If anybody's interested in joining forces on either front we'd be be
happy to talk.
Cheers,
Björn
On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman <[email protected]> wrote:
> On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun <[email protected]> wrote:
>> While there is definitely some work to be done in handoff, it seems
>> like there are some find implementations of this already in existence.
>> Several brands of "enterprise access point" setups seem to do well at
>> this. It would be nice if they interoperated, I guess.
>>
>> The fact that there's no open source version of this kind of handoff
>> feature bugs me, but we are working on it here and the work is all
>> planned to be open source, for example: (very early version)
>> https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/
>
> We've got an SDN-inspired architecture with 802.11 frame tunneling (a
> la CAPWAP), airtime fairness, infrastructure initiated hand-over,
> Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and
> a few more goodies. It's currently free as in beer
> (http://anyfi.net/software,
> https://github.com/carrierwrt/carrierwrt/pull/7 and
> http://www.anyfinetworks.com/download) up to 100 APs, but we're
> definitely going to open source in one form or another.
>
> We've also tried to raise some interest in fixing up CAPWAP
> (https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html),
> which is (unfortunately) the best open standard at the moment.
> Interest seems marginal though...
This sounds cool. Is the CAPWAP/encapsulation stuff separable from
the rest? At 802.11ac speeds, a super fast WAN link, and a low-cost
SoC, too many layers can be a killer.
On Mon, 2 Feb 2015, Avery Pennarun wrote:
> On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman <[email protected]> wrote:
>> On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun <[email protected]> wrote:
>>> While there is definitely some work to be done in handoff, it seems
>>> like there are some find implementations of this already in existence.
>>> Several brands of "enterprise access point" setups seem to do well at
>>> this. It would be nice if they interoperated, I guess.
>>>
>>> The fact that there's no open source version of this kind of handoff
>>> feature bugs me, but we are working on it here and the work is all
>>> planned to be open source, for example: (very early version)
>>> https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/
>>
>> We've got an SDN-inspired architecture with 802.11 frame tunneling (a
>> la CAPWAP), airtime fairness, infrastructure initiated hand-over,
>> Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and
>> a few more goodies. It's currently free as in beer
>> (http://anyfi.net/software,
>> https://github.com/carrierwrt/carrierwrt/pull/7 and
>> http://www.anyfinetworks.com/download) up to 100 APs, but we're
>> definitely going to open source in one form or another.
Please keep in touch, when it is released open source I'd be very interested in
trying it for SCaLE. I'll probably exceed your 100 radio free limit this year,
and it's hard to justify using non-free code at a linux conference (not
impossible, but not something I'm going to try to do 3 weeks before the show :-)
I'm doing social engineering to push people to the 5GHz network (SSID for 5G is
scale, for 2.4 is scale-slow), it would be great to be able to do this directly.
And better handoffs as people move around would be good.
It would also be good if something like this could help identify gaps in
coverage. If it can identify cases where users go from having coverage to poor
connectivity to having coverage, we can manually investigate to see where in the
building that is and see what we can do to fix it.
David Lang
>> We've also tried to raise some interest in fixing up CAPWAP
>> (https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html),
>> which is (unfortunately) the best open standard at the moment.
>> Interest seems marginal though...
>
> This sounds cool. Is the CAPWAP/encapsulation stuff separable from
> the rest? At 802.11ac speeds, a super fast WAN link, and a low-cost
> SoC, too many layers can be a killer.
> _______________________________________________
> Cerowrt-devel mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
On Mon, Feb 2, 2015 at 11:53 PM, Avery Pennarun <[email protected]> wrote:
> On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman <[email protected]> wrote:
>> On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun <[email protected]> wrote:
>>> While there is definitely some work to be done in handoff, it seems
>>> like there are some find implementations of this already in existence.
>>> Several brands of "enterprise access point" setups seem to do well at
>>> this. It would be nice if they interoperated, I guess.
>>>
>>> The fact that there's no open source version of this kind of handoff
>>> feature bugs me, but we are working on it here and the work is all
>>> planned to be open source, for example: (very early version)
>>> https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/
>>
>> We've got an SDN-inspired architecture with 802.11 frame tunneling (a
>> la CAPWAP), airtime fairness, infrastructure initiated hand-over,
>> Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and
>> a few more goodies. It's currently free as in beer
>> (http://anyfi.net/software,
>> https://github.com/carrierwrt/carrierwrt/pull/7 and
>> http://www.anyfinetworks.com/download) up to 100 APs, but we're
>> definitely going to open source in one form or another.
>>
>> We've also tried to raise some interest in fixing up CAPWAP
>> (https://www.ietf.org/mail-archive/web/opsawg/current/msg03196.html),
>> which is (unfortunately) the best open standard at the moment.
>> Interest seems marginal though...
>
> This sounds cool. Is the CAPWAP/encapsulation stuff separable from
> the rest? At 802.11ac speeds, a super fast WAN link, and a low-cost
> SoC, too many layers can be a killer.
Our current architecture is a bit "fixed function" with tunneling
built in. That's because it's targeted at guest access / homespots
where there's typically a "local MAC" for the home Wi-Fi network
(which we don't touch), and for guests you usually want to tunnel
anyway. Many use L2oGRE to tunnel a "second SSID" in this use-case,
but since the visited AP is a point of attack we think you should
encrypt "through" the AP. You can do that without any extra overhead
since you're just shoveling encrypted 802.11 frames from one interface
to another, but you're right it's a bit slower in practice: in the
extreme case of frame shoveling in user space you're limited to about
40 Mbps (for guests) on a $10 SoC (but home Wi-Fi throughput is not
impacted).
What we're working on now though is an "Open wSwitch" that lets you
pick and choose which frames to tunnel and where, even within one BSS
/ for a single STA. You'll also be able to set the temporal key (TK)
from a central location so that you can do e.g. OKC / 802.11r combined
with local bridging. This should make it possible to do both the
secure guest access and the more enterprisy stuff over the same
control plane protocol. We're also planning to put the 802.11
tunneling in kernel space this time, which should easily get you 100
Mbps of AES-128-CCM through a cheap SoC (and into/out of a cheap
mobile device!).
On Tue, Feb 3, 2015 at 12:27 AM, David Lang <[email protected]> wrote:
> On Mon, 2 Feb 2015, Avery Pennarun wrote:
>> On Mon, Feb 2, 2015 at 11:44 AM, Björn Smedman <[email protected]> wrote:
>>> We've got an SDN-inspired architecture with 802.11 frame tunneling (a
>>> la CAPWAP), airtime fairness, infrastructure initiated hand-over,
>>> Opportunistic Key Caching (OKC), IEEE 802.11r Fast BSS Transition and
>>> a few more goodies. It's currently free as in beer
>>> (http://anyfi.net/software,
>>> https://github.com/carrierwrt/carrierwrt/pull/7 and
>>> http://www.anyfinetworks.com/download) up to 100 APs, but we're
>>> definitely going to open source in one form or another.
>
> Please keep in touch, when it is released open source I'd be very interested
> in trying it for SCaLE. I'll probably exceed your 100 radio free limit this
> year, and it's hard to justify using non-free code at a linux conference
> (not impossible, but not something I'm going to try to do 3 weeks before the
> show :-)
Will do. :)
> I'm doing social engineering to push people to the 5GHz network (SSID for 5G
> is scale, for 2.4 is scale-slow), it would be great to be able to do this
> directly. And better handoffs as people move around would be good.
>
> It would also be good if something like this could help identify gaps in
> coverage. If it can identify cases where users go from having coverage to
> poor connectivity to having coverage, we can manually investigate to see
> where in the building that is and see what we can do to fix it.
Both of those should be well within scope. :)