From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7655B21F2FD for ; Tue, 3 Feb 2015 02:02:43 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ge10so49981376lab.10 for ; Tue, 03 Feb 2015 02:02:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=elRXmV/e8Rql1g+vrRxrQe/I9FJC3MFmHcc7VGqroi4=; b=GIDndsFtG4YvuR1T673D12jXgGNdn4GpKQQd+fpOEvBO7CDROceGgUYHCd7lA+ku0k tU7NpFIx61wGz54l+WBxBA2RG7Xy7bAjfGPl/HGIJ9bmMar3+C9EiBZlltlOUCclPVZb pUocgFqqE5corU6T+3qGWxZHuMn6QoS+THYW+EvEoBjxdFw6Fxxr1j3P5P04S5RHweKa aoIIBe9AHIEmXKT9ov7iCk3Kd80OGlxwBooOs5Xeu/2Nur8as7mYx0oxk+PKgv5ptP6I fa6xJiLTgIeziJWanWokJpjPNGlTHOtBHQaemQHRzznJO1V7f9RQmQSypoS8n0Ixy86f nX3A== X-Gm-Message-State: ALoCoQmzZkaFNMrGKBZnZlEQ4E2HvFM832rWXb1GLmFX9FucFRjqNFG/cJRu+29YHfh+tPxnyNVv MIME-Version: 1.0 X-Received: by 10.112.47.135 with SMTP id d7mr23440400lbn.54.1422957761250; Tue, 03 Feb 2015 02:02:41 -0800 (PST) Sender: bjorn.smedman@anyfi.net Received: by 10.25.62.9 with HTTP; Tue, 3 Feb 2015 02:02:41 -0800 (PST) X-Originating-IP: [82.99.7.230] In-Reply-To: References: Date: Tue, 3 Feb 2015 11:02:41 +0100 X-Google-Sender-Auth: KnuVLGbDVd1ZxJt0fiGHeMYfSt4 Message-ID: From: =?UTF-8?Q?Bj=C3=B6rn_Smedman?= To: Avery Pennarun Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 12 Feb 2015 08:34:44 -0800 Cc: linux-wireless , "cerowrt-devel@lists.bufferbloat.net" , dstanley , Derrick Pallas Subject: Re: [Cerowrt-devel] Open Source RRM & Hand-Over Optimization (WAS: Throughput regression with `tcp: refine TSO autosizing`) X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 10:03:13 -0000 On Mon, Feb 2, 2015 at 11:53 PM, Avery Pennarun wrote= : > On Mon, Feb 2, 2015 at 11:44 AM, Bj=C3=B6rn Smedman wrote: >> On Mon, Feb 2, 2015 at 5:21 AM, Avery Pennarun wro= te: >>> 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/wavegui= de/ >> >> 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!).