Re: [Make-wifi-fast] [bbr-dev] WiFi aggregation

Re: [Make-wifi-fast] [bbr-dev] WiFi aggregation

[Dave Taht]

On Tue, Oct 18, 2016 at 5:12 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 19 Oct, 2016, at 02:24, 'Simon Barber' via BBR Development <bbr-dev@googlegroups.com> wrote:
>>
>> To maintain high efficiency filling the aggregates is required. To maintain low latency a fq_codel like approach can be used, where mice get scheduled first.
>
> But that behaviour will obviously lead to the high variation in RTT which was mentioned earlier in this thread, in the context of BBR having to cope with it.
>
> When BBR probes for minRTT, it will intentionally become a sparse flow and, if it is the only flow on that station, the resultant preferential airtime scheduling will yield a considerably lower latency than the optimal-throughput steady state.  Depending on the overall RTT ratio, BBR may then be unable to discover the true maximum bandwidth before the RTT climbs above its threshold.
>
> This high variation in RTT is also likely to affect conventional TCPs’ RTO calculations, since unlike a wired link, the acks will come in bursts each corresponding to one MAC grant.
>
> It also means that latency of a genuinely sparse, latency-sensitive flow is strongly affected by the presence of a bulk flow on the same station, even if flow isolation within stations is in effect.
>
> These are all effects peculiar to aggregation (which is itself a reaction to wifi’s extremely high MAC overhead), and are not present on a well-behaved wired link.  In the latter case, doling out one packet per host per cycle still results in good throughput and the best possible latency.
>
> All of this leads back to airtime as the correct measure of per-station fairness - but how much airtime per station?
>
> From a pure throughput perspective, the answer is “the airtime of a max-size aggregate to the fastest station”, with slower stations getting either correspondingly smaller aggregates, or proportionally fewer TXOPs, or a combination of the two.  (This assumes we don’t starve slower stations entirely in the holy name of global throughput.)
>
> But I (and Dave) firmly believe you have to consider latency in the equation as well, as the world is not all about bulk TCP transfers (any more than it’s all about UDP floods, which are often used in PMPO-style benchmarks).  Latency is also a measure of airtime, but it’s airtime *not* given to a station which has data ready for it, and there must be a maximum acceptable value which the granted airtime per station must be dynamically tuned to fit.
>
> In the limit, global optimisation for latency results in one packet sent per TXOP.  At high SNR, this will give much lower throughput than large aggregates, but networks have an annoying habit of continuing to function at low throughput and low latencies, in a way they just don’t at high throughput but unacceptable latencies.  With Cake, I can still have a well-functioning Internet connection at 64Kbps symmetric, with the exception of essentially CBR services like YouTube.
>
> There is of course a middle ground.  Let’s find it.
>
> A good starting point might be to aim for 50% airtime efficiency, rather than 100%.  That is, aggregates are allowed to grow until they occupy as much airtime as the MAC overhead.  Discuss.

Well, I think the issues a small number of people are having with
fixing wifi and BBR's potential impact on it probably belongs more to
the make-wifi-fast list.

The BBR community is focused on fixing a portion of the internet as it
is today. Merely getting a cubic replacement out there is a big job...

I could see one day trying to write a roadmap document about what else
is still needed in BBR and elsewhere, for a better internet. FQ at the
ISP would remain one of them. Getting ISP buffering *universally* down
to no more than 100ms would be nice also. Unless that breaks Africa.
Converging on the right way to do ECN could be another, but I'm not
looking forward to all the nicotine patches that would take. Maybe
someone at google already has got that roadmap? (Matt?)

I've enjoyed thinking about BBR, as the first TCP designed with big
data, actual application behavior, and the user experience in mind,
it's reset my thinking in multiple ways, but I have to admit my own
foci for the next while are, on my last fumes of funding, finishing a
talk for linuxplumbers nov 3, and trying to find and fix the latest
"last bugs" in the fq-wifi-mac code, and get that successfully
upstream, while making a bit of progress on the airtime fair code.

Merely having BBR around to check against is an enormous help in
thinking about futures, but I'm not sure if any insights will emerge
with mere discussion. I've got tons more data to collect and think
about, and a couple tweaks here and there, and overall I think I'm
marching in a better direction.

I hopefully succeeded in demolishing the "always fill a full txop even
with tons of stations" argument earlier in this thread.

I'm compelled to point out that the numbers I used throughout that
post were pretty bogus (I can try to refine the argument for a wider
audience), and that in the real world, when a station pops up for a 2
second transaction, the actual bandwidth available to it tends to vary
massively as the rate controller (minstrel in that case) struggles to
find the right wifi rate.

I like this new math floating about, I hope to get spare brain cells
to think about the minstrel part of the problem... after some more
stuff gets off my plate!

as for aiming for 50% airtime usage, I think that's too narrow a goal.
My own at the moment is merely to keep ripping out all the excess
latency and jitter in wifi and to find more ways to resist putting any
back in except where absolutely necessary. I generally think that the
more we do that, the better TCPs and most applications will behave.
Although we are getting great aggregation results now, I also tend to
think of aggregation as a "shock absorber" all it's own.




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