From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <toke@toke.dk>
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a00:7660:6da:2001::664])
 (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id 411F53B2A4
 for <bloat@lists.bufferbloat.net>; Fri, 13 Sep 2019 07:58:21 -0400 (EDT)
From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023;
 t=1568375899; bh=T/izdDRDp8yIHUp2gD9OAEwvu8Dihxod20WXPC8IrTc=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=SVwzpH7FF2o4x5VoOcndLp+XLSzchq7JxNV7NYcNC0t/A0qdc0oQOhcenLz3K3LSJ
 3mPuwHQCaNjLGkpKJNUDh3Ry39zR+Gs2E7e3ikc1JougfoPkmd2UvCebWgGqmKTMno
 7z3KWWyj8oVICY7TiRYywuslQLRqtGvEKMaySZGboAxVxQAoXsmPkoGc22qUBE/m7G
 dRTxMyq+CpQaPru0N9rxBtNCY+TqrDu8F+3V5JhncreppV0gLGFm2AN0s9MDKOUP7e
 GcMQI6RD3m/mxCiOV3WJdkwD5VLgcmo5+0b5vkS4YT55DsXr8oGO2D6NyXKOSG18rX
 NiwxlrtyUxQfw==
To: Dave Taht <dave.taht@gmail.com>, David Lang <david@lang.hm>
Cc: bloat <bloat@lists.bufferbloat.net>
In-Reply-To: <CAA93jw4AK7xz6R+SXiOmze1w9P5Z4OtN8xrdL8g3jn+2+d6Ang@mail.gmail.com>
References: <CAOdf3gr7uxuLhYksnvt_SZ14Q8NShNpDnONbj0b2ZAYpQ6BDsw@mail.gmail.com>
 <nycvar.QRO.7.76.6.1909122301110.6081@qynat-yncgbc>
 <CAA93jw4AK7xz6R+SXiOmze1w9P5Z4OtN8xrdL8g3jn+2+d6Ang@mail.gmail.com>
Date: Fri, 13 Sep 2019 13:58:18 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87muf8s90l.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [Bloat] Dual Channel Wi-Fi
X-BeenThere: bloat@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: General list for discussing Bufferbloat <bloat.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/bloat>
List-Post: <mailto:bloat@lists.bufferbloat.net>
List-Help: <mailto:bloat-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/bloat>,
 <mailto:bloat-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2019 11:58:21 -0000

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.