[Cerowrt-devel] [Make-wifi-fast] [Babel-users] perverse powersave bug with sta/ap mode

[Dave Taht]

On Thu, Apr 28, 2016 at 8:44 AM, Dave Taht <dave.taht at gmail.com> wrote:
> On Thu, Apr 28, 2016 at 7:59 AM, Juliusz Chroboczek
> <jch at pps.univ-paris-diderot.fr> 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.

5) be powersave aware.

turn powersave off on aps and stations with stable power sources.

Mobile units on battery then would generally not be considered as
viable routing candidates unless they were very active, and doing
unicast to them to verify they were still alive would be a "keepalive"
meshanism...



-- 
Dave Täht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org