[Bloat] Dual Channel Wi-Fi

[Bloat] Dual Channel Wi-Fi

[Etienne Champetier]

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

I'm curious what people on this mailing list think about this Wi-Fi
optimisation

https://www.cablelabs.com/technologies/dual-channel-wi-fi
https://github.com/openwrt/packages/pull/9972

[-- Attachment #2: Type: text/html, Size: 449 bytes --]

Re: [Bloat] Dual Channel Wi-Fi

[Dave Taht]

Hmm. In essence most of the wifi traffic I get from comcast is already
"dual channel" as they mark everything
they don't recognise as CS1, thus data down is deprio'd compared to
acks or data up, unless you wash it out.

Their implementation uses a hidden SSID...

deserves a look-see.

On Fri, Sep 13, 2019 at 6:47 AM Etienne Champetier
<champetier.etienne@gmail.com> wrote:
>
> I'm curious what people on this mailing list think about this Wi-Fi optimisation
>
> https://www.cablelabs.com/technologies/dual-channel-wi-fi
> https://github.com/openwrt/packages/pull/9972
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Bloat] Dual Channel Wi-Fi

[David Lang]

it's an optimization that will work well when there is only one person using the 
network, and utterly collapse when there is a lot of use.

it assumes that 'high priority' and bulk things only move in one direction, it 
uses more channels, which will cause more collisions with other users and other 
networks.

a fairly typical type of idea to someone who doesn't look at what's actually 
happening at the RF level.

David Lang

On Fri, 13 Sep 2019, Etienne Champetier wrote:

> Date: Fri, 13 Sep 2019 14:47:38 +0900
> From: Etienne Champetier <champetier.etienne@gmail.com>
> To: bloat <bloat@lists.bufferbloat.net>
> Subject: [Bloat] Dual Channel Wi-Fi
> 
> I'm curious what people on this mailing list think about this Wi-Fi
> optimisation
>
> https://www.cablelabs.com/technologies/dual-channel-wi-fi
> https://github.com/openwrt/packages/pull/9972
>

Re: [Bloat] Dual Channel Wi-Fi

[Dave Taht]

There's more to it than that.

https://www-res.cablelabs.com/wp-content/uploads/2019/06/24150908/Dual-Channel-Wi-Fi-Performance-Test-Report-June-2019.pdf

On Fri, Sep 13, 2019 at 7:03 AM David Lang <david@lang.hm> wrote:
>
> it's an optimization that will work well when there is only one person using the
> network, and utterly collapse when there is a lot of use.
>
> it assumes that 'high priority' and bulk things only move in one direction, it
> uses more channels, which will cause more collisions with other users and other
> networks.
>
> a fairly typical type of idea to someone who doesn't look at what's actually
> happening at the RF level.
>
> David Lang
>
> On Fri, 13 Sep 2019, Etienne Champetier wrote:
>
> > Date: Fri, 13 Sep 2019 14:47:38 +0900
> > From: Etienne Champetier <champetier.etienne@gmail.com>
> > To: bloat <bloat@lists.bufferbloat.net>
> > Subject: [Bloat] Dual Channel Wi-Fi
> >
> > I'm curious what people on this mailing list think about this Wi-Fi
> > optimisation
> >
> > https://www.cablelabs.com/technologies/dual-channel-wi-fi
> > https://github.com/openwrt/packages/pull/9972
> >
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Bloat] Dual Channel Wi-Fi

[Dave Taht]

and this: https://www.edgewaterwireless.com/

On Fri, Sep 13, 2019 at 7:13 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> There's more to it than that.
>
> https://www-res.cablelabs.com/wp-content/uploads/2019/06/24150908/Dual-Channel-Wi-Fi-Performance-Test-Report-June-2019.pdf
>
> On Fri, Sep 13, 2019 at 7:03 AM David Lang <david@lang.hm> wrote:
> >
> > it's an optimization that will work well when there is only one person using the
> > network, and utterly collapse when there is a lot of use.
> >
> > it assumes that 'high priority' and bulk things only move in one direction, it
> > uses more channels, which will cause more collisions with other users and other
> > networks.
> >
> > a fairly typical type of idea to someone who doesn't look at what's actually
> > happening at the RF level.
> >
> > David Lang
> >
> > On Fri, 13 Sep 2019, Etienne Champetier wrote:
> >
> > > Date: Fri, 13 Sep 2019 14:47:38 +0900
> > > From: Etienne Champetier <champetier.etienne@gmail.com>
> > > To: bloat <bloat@lists.bufferbloat.net>
> > > Subject: [Bloat] Dual Channel Wi-Fi
> > >
> > > I'm curious what people on this mailing list think about this Wi-Fi
> > > optimisation
> > >
> > > https://www.cablelabs.com/technologies/dual-channel-wi-fi
> > > https://github.com/openwrt/packages/pull/9972
> > >
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
>
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740



-- 

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740

Re: [Bloat] Dual Channel Wi-Fi

[Sebastian Moeller]

I am with David, this is going to be fun on densely populated apartment buildings. For people with no RF-competition it is sort of a "nice" trick to more or less go "duplex".

What a I missing?

Best Regards
	Sebastian



> On Sep 13, 2019, at 08:13, Dave Taht <dave.taht@gmail.com> wrote:
> 
> There's more to it than that.
> 
> https://www-res.cablelabs.com/wp-content/uploads/2019/06/24150908/Dual-Channel-Wi-Fi-Performance-Test-Report-June-2019.pdf
> 
> On Fri, Sep 13, 2019 at 7:03 AM David Lang <david@lang.hm> wrote:
>> 
>> it's an optimization that will work well when there is only one person using the
>> network, and utterly collapse when there is a lot of use.
>> 
>> it assumes that 'high priority' and bulk things only move in one direction, it
>> uses more channels, which will cause more collisions with other users and other
>> networks.
>> 
>> a fairly typical type of idea to someone who doesn't look at what's actually
>> happening at the RF level.
>> 
>> David Lang
>> 
>> On Fri, 13 Sep 2019, Etienne Champetier wrote:
>> 
>>> Date: Fri, 13 Sep 2019 14:47:38 +0900
>>> From: Etienne Champetier <champetier.etienne@gmail.com>
>>> To: bloat <bloat@lists.bufferbloat.net>
>>> Subject: [Bloat] Dual Channel Wi-Fi
>>> 
>>> I'm curious what people on this mailing list think about this Wi-Fi
>>> optimisation
>>> 
>>> https://www.cablelabs.com/technologies/dual-channel-wi-fi
>>> https://github.com/openwrt/packages/pull/9972
>>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> 
> 
> -- 
> 
> Dave Täht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Dual Channel Wi-Fi

[Toke Høiland-Jørgensen]

Dave Taht <dave.taht@gmail.com> writes:

> There's more to it than that.
>
> https://www-res.cablelabs.com/wp-content/uploads/2019/06/24150908/Dual-Channel-Wi-Fi-Performance-Test-Report-June-2019.pdf

Looking at the code[0], it seems to be a userspace daemon that does
encapsulation of traffic and sends it over a separate, hidden BSS that
is access-controlled to only allow stations that already performed their
handshake.

So, conceptually it turns several WiFi links into a bonded device where
the AP can steer the traffic between underlying devices.

It's an interesting idea, but I doubt it'll see much deployment: Just
the requirement of running a daemon on each client device is bound to
put a damper on that. It's not quite clear to me whether the station
would need to support associating on multiple bands at the same time;
not sure how many clients do that...

Also, I wonder how well the userspace encapsulation stuff works on a
low-powered AP?

-Toke

[0] https://github.com/ewsi/dcstad is the client daemon; the github org
    has the rest.