From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E4AD43B25D; Thu, 28 Apr 2016 11:44:15 -0400 (EDT) Received: by mail-oi0-x232.google.com with SMTP id x19so87856789oix.2; Thu, 28 Apr 2016 08:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=vO28XDGsDW8EIS9z3b0SYx2k6jkgTfN4YaerQE44ONE=; b=hbJFvgJ0LL+RBYYtoSxt2vnEIDRr7ysTM/yv2lPIpBHRI9vAnSXylfBDP6ehsuaHph Ezgd7dmfXiogsi6x/ZPNdZADiWgLjRNeESJ7Vm6XjrcCnZCmiv8sPWgUGdCsJ2euEl57 vVaa/8KUxA3QwxLpF01lJxnNWVEipr88jRi0ORttDrEgqD4OHJ65ikokeoKcB7Q2EJdY oja4LFJPQJHZi62kNXNxNLtmheWNW4q7QPBSQxffj+tUn87Wlf1q1McrpSsmUD8h/vo0 2jOsLF0/jBBdySFmWKSZusCAY8dFjDlNR7HC8PG6LXzHUaPj85JvAZ1XOdM7hhaqjryu pMuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=vO28XDGsDW8EIS9z3b0SYx2k6jkgTfN4YaerQE44ONE=; b=Y/KzQ2Lh7xuu5ZiLH7F8sr6ksagDFXq5Ct9ZJ/jpPY/vLFcEqYBQGtPVk+ktW4/H/T wVr5Nz39bEtAjZlnIARYaek9jbBjsrCUdP2rwmbdt/DoZz7xaQKjajKHSSFCfbgSatl8 VedhD6Gru780eUnStm9990IxYJPvx1OB4HbHcTMAl+rpEtTdh1Kd7rEaTdTxFvVH6edo lfAH63PUC+X88bLE8m22TcbTJwTXtkFTQRDacYmUWPwBhSW4pGxAZ/6BU/r/aNrkkHYM oBzJNtYi8gjq8hXU5xyqzIVtG5Zcx05vVZQTGyfN5qpVIrcpNwKXUnOPOd/UH+awvD37 uohw== X-Gm-Message-State: AOPr4FXqeJk9Z7WkYRZRO09cBxCLGIJP4hZCCUXuoExbhWHnbljQMYyZ3sr0+qRoylZnr9S6K+u2/rW00JsmfA== MIME-Version: 1.0 X-Received: by 10.202.217.67 with SMTP id q64mr6871690oig.151.1461858255410; Thu, 28 Apr 2016 08:44:15 -0700 (PDT) Received: by 10.202.78.23 with HTTP; Thu, 28 Apr 2016 08:44:15 -0700 (PDT) In-Reply-To: <7ih9el3hjy.wl-jch@pps.univ-paris-diderot.fr> References: <1461849006.60252745@apps.rackspace.com> <87oa8tyhug.wl-jch@pps.univ-paris-diderot.fr> <878tzx4zno.fsf@toke.dk> <1461853008.891910506@apps.rackspace.com> <7ih9el3hjy.wl-jch@pps.univ-paris-diderot.fr> Date: Thu, 28 Apr 2016 08:44:15 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Cc: David Reed , make-wifi-fast@lists.bufferbloat.net, "babel-users@lists.alioth.debian.org" , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2016 15:44:16 -0000 On Thu, Apr 28, 2016 at 7:59 AM, Juliusz Chroboczek wrote: >> Discovery is a special case, that is not quite multicast. [...] So you >> don't need any facility to "reach all" in one message. > > Are we speaking of the IP Internet, or of some other network? Heh. Wifi is "some other network", at this point. Perhaps it always was. It was originally targetted at IPX/SPX. As wifi has evolved all sorts of packets below the conventional link layer that are invisible to IP (management frames in general), perhaps finding saner ways of exposing these packet types and their properties to the conventional IP stack - and the IP stack to the properties of the wifi frames - would be of help. For example, I just "ate" the entire 802.11-2012 and 802.11ac specifications, notably section 9 (Aggregation stuff mostly) and annex G - for those of you into a digestif, they are publicly available via: http://standards.ieee.org/about/get/802/802.11.html In my case I was mostly looking for properties of ampdus that could be better leveraged for congestion control. It turns out that you *can* mark certain MPDUs as QosNOACK, which means that they will not be block acknowledged. Nobody does this... and, while you could form some IP packets with this property there's no way to do it on the ath10k (except in raw mode), and no hook for it on the ath9k, and no way of the IP layer saying to the 802.11 layer, "it's totally ok you can lose this". Elsewhere in the stack I am seeing retries of 10 (ath9k) and 15 (Ath10k), and in the initial fq_codel implementation on ath10k, *ZERO* loss coming from the wifi layer on a string of traces. (I was leveraging codel's ecn marking abilities to "see" this ) The mac802.11 portion also has sw retries as a global config, not as something that is per-station. I am certain, out there, there is some wifi EE dancing at how perfect they've made the wireless layer appear and "transparent" to IP, but I look at the aircap packet traces I just got with something akin to horror, 10s of ms of retries on stuff, eating other people's air, that I'd just as soon throw away, which also shows up on the xplot.org tcptraces on a wire downstream as spikes in rtt. (there is also the needed cts random backoff in there, also, which makes it hard to distinguish between retries at various rates and needed backoff. I am sick of manually tearing apart aircaps....) Now, dpreed's position on how we do wireless wrong is a great starting point... I wish hd'd publish his 11 layer stack document somewhere... > A number of fundamental Internet protocols, such as ARP and ND, use > multicast for discovery (I see broadcast as a special case of multicast). > So if you want to implement the TCP/IP suite, your link layer needs to > support multicast. Some people have tried to work around that (see > RFC 2022, for example), with IMHO little success. Sure wish more wifi folk drank with more ietf folk, more often. Starting 2 decades back. > > What you seem to be arguing is that it would be possible to design > a protocol suite that uses anycast for discovery. While an interesting > research project, your suite would no longer be TCP/IP, good luck getting > it deployed. > > (So what's the solution? As Toke suggested, push the multicast > implementation to the link layer -- have the link layer convert multicast > to multiple unicasts in a way that's invisible to the network layer. > After all, that's what the link layer is for -- hiding the idiosyncrasies > of a given physical layer from the network layer.) 1) Well, I have suggested that IHU messages actually be unicast rather than bundled with the hello. That would help somewhat in this case. (and also fix cases where multicast works and unicast doesn't). multicast hello would become more of a discovery protocol and you could actually signal you can "take" a unicast hello (via a new tlv) and establish an ongoing multicast-free association that way. Given the currently "perfect" characteristics of the underlying unicast wireless link layer that would tend to eliminate packet loss as a viable metric of quality. :( 2) A protocol that needs "always listening" capability could signal the underlying stack to "make sure" these packets hit the air, and one that also wants "please be lossy" capabl I leave the actual implementation of that request to the fantasies of the authors - a new dscp codepoint or three? /me ducks 3) There are other stats from minstrel, station association, crypto state, etc, that could be leveraged. 4) And ya know - it might merely be a (sadly common) bug. Everybody's supposed to wake up for the multicast beacons and get a notification there's more data to come. > -- Juliusz > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast --=20 Dave T=C3=A4ht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org