Re: [Make-wifi-fast] Diagram of the ath9k TX path

[Dave Taht <dave.taht@gmail.com>]

On Fri, May 13, 2016 at 12:20 PM, Aaron Wood <woody77@gmail.com> wrote:
> On Fri, May 13, 2016 at 11:57 AM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Fri, May 13, 2016 at 11:05 AM, Bob McMahon <bob.mcmahon@broadcom.com>
>> wrote:
>>>
>>>  don't have the data available for multiple flows at the moment.
>>
>>
>> The world is full of folk trying to make single tcp flows go at maximum
>> speed, with multiple alternatives to cubic.
>
>
> And most web traffic is multiple-flow, even with HTTP/2 and SPDY, due to
> domain/host sharding.  Many bursts of multi-flow traffic.  About the only
> thing that's single-flow is streaming-video (which isn't latency sensitive).

And usually, rate limited. It would be nice if that streaming video actually
fit into a single txop in many cases.

> The only local services that I know of that could use maximal-rate wifi are
> NAS systems using SMB, AFP, etc.

And many of these, until recently, were actually bound by the speed of
their hard disks and by inefficiencies in the protocol.

>
> -Aaron

A useful flent test for seeing the impact of good congestion control,
are tcp_2up_square and tcp_2up_dleay.

There are also other related tests like "reno_cubic_westwood_cdg"
which try one form of tcp against another. I really should sit down
and write a piece about these, to try to show that one flow grabbing
all the link hurts all successor flows.

Both could be better. I like what the teacup people are doing here,
using 3 staggered flows to show their results.



...

and I misspoke a bit earlier, meant to say txop where instead I'd said
ampdu. Multiple ampdus can fit into a txop, and so far as I know, be
block acked differently.

https://books.google.com/books?id=XsF5CgAAQBAJ&pg=PA32&lpg=PA32&dq=multiple+ampdus+in+a+txop&source=bl&ots=dRCYcD9rBc&sig=tVocMORuEXBOsfUlcmuSLTdM0Lw&hl=en&sa=X&ved=0ahUKEwiLxurP69fMAhVU5WMKHVejAlUQ6AEIHzAA#v=onepage&q=multiple%20ampdus%20in%20a%20txop&f=false

One thing I don't have a grip on is the airtime cost on packing
multiple ampdus into a txop, in terms of the block ack, also in
relation to using amdsus as per the 2015 paper referenced off the
"thoughts about airtime fairness thread" that the ath9k list was not
cc'd on.

https://lists.bufferbloat.net/pipermail/make-wifi-fast/2016-May/000661.html

 I note that some of my comments on that thread was due to the overly
EE and math oriented analysis of the "perfect" solution, but I'm over
that now. :) It was otherwise one of the best recent papers on wifi
I've read, and more should read:

 http://www.hindawi.com/journals/misy/2015/548109/

(and all the other cites in that thread were good, too. MIT had the
basics right back in 2003!)

One of my longer term dreams for better congestion control in wifi is
to pack one aggregate in a txop with stuff you care about deeply, and
a second, with stuff you don't (or vice versa).

As also per here, filling in my personal memory gap from 2004 or so
(when I thought block acks would only be used on critical traffic) and
where I started going back and reviewing the standard.

http://blog.cerowrt.org/post/selective_unprotect/

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