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

[Dave Taht]

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.


> -- Juliusz
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast



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