Just to clarify, managing queueing in a single access point WiFi network is
only a small part of the problem of fixing the rapidly degrading performance of
WiFi based systems. Similarly, mesh routing is only a small part of the
problem with the scalability of cooperative meshes based on the WiFi MAC.
So I don't disagree with work on queue management (which is not good in any
commercial product).
But Dave T has done some great talks on "fixing WiFi" that don't have to do
with queueing very much at all.
For example, rate selection for various packets is terrible. When you have
nearly 1000:1 ratios of transmission rates and codes that are not backward
compatible, there's a huge opportunity for improvement. Similarly, choice of
frequency bandwidth and center frequency at each station offers huge
opportunities for practical scalability of systems. Also, as we noted earlier,
"handoff" from one next hop to another is a huge problem with performance in
practical deployments (a factor of 10x at least, just in that).
Propagation information is not used at all when 802.11 systems share a channel,
even in single AP deployments, yet all stations can measure propagation quite
accurately in their hardware.
Finally, Listen-before-talk is highly wasteful for two reasons: 1) any random
radio noise from other sources unnecessarily degrades communications (and in
the 5.8 MHz band, the rule about "radar avoidance" requires treating very low
level noise as a "signal to shut the net down by law", but there is a loophole
if you can tell that it's not actually "radar" (the technique requires two or
more stations to measure the same noise event, and if the power is
significantly different - more than a few dB - then it can't possibly be due to
a distant transmitter, and therefore can be ignored). 2) the transmitter cannot
tell when the intended receiver will be perfectly able to decode the signal
without interference with the station it hears (this second point is actually
proven in theory in a paper by Jon Peha that argued against trivial
"etiquettes" as a mechanism for sharing among uncooperative and
non-interoperable stations).
Dave T has discussed more, as have I in other venues.
The reason no one is making progress on any of these particular issues is that
there is no coordination at the "systems level" around creating rising tides
that lift all boats in the WiFi-ish space. It's all about ripping the
competition by creating stuff that can sell better than the other guys' stuff,
and avoiding cooperation at all costs.
I agree that, to the extent that managing queues in a single box or a single
operating system doesn't require cooperation, it's much easier to get such
things into the market. That's why CeroWRT has been as effective as it has
been. But has Microsoft done anything at all about it? Do the better ECN
signals that can arise from good queue management get used by the TCP
endpoints, or for that matter UDP-based protocol endpoints?
But the big wins in making WiFi better are going begging. As WiFi becomes more
closed, as it will as the major Internet Access Providers and Gadget builders
(Google, Apple) start excluding innovators in wireless from the market by
closed, proprietary solutions, the problem WILL get worse. You won't be able
to fix those problems at all. If you have a solution you will have to convince
the oligopoly to even bother trying it.
So, let me reiterate. The problem is not just "getting Minstrel adopted",
though I have nothing against that as a subgoal. The problem is to find good
systems-level answers, and to find a strategy to deliver those answers to a
WiFi ecology that spans the planet, and where the marketing value-story focuses
on things one can measure between two stations in a Faraday cage, and never on
any systems-level issues.
I personally think that things like promoting semi-closed, essentially
proprietary ESSID-based bridged distribution systems as "good ideas" are
counterproductive to this goal. But that's perhaps too radical for this crowd.
It reminds me of Cisco's attempt to create a proprietary Internet technology
with IOS, which fortunately was not the success Cisco hoped for, or Juniper
would not have existed. Maybe IOS would have been a fine standard, but it would
have killed the evolution of the Internet as we know it.
On Sunday, February 1, 2015 5:47am, "Jonathan Morton" <chromati...@gmail.com>
said:
Since this is going to be a big job, it's worth prioritising parts of it
appropriately.
Minstrel is probably already the single best feature of the Linux Wi-Fi stack.
AFAIK it still outperforms any other rate selector we know about. So I don't
consider improving it further to be a high priority, although that trick of
using it as a sneaky random packet loss inducer is intriguing.
Much more important and urgent is getting some form of functioning SQM closer
to the hardware, where the information is. I don't think we need to get super
fancy here to do some real good, in the same way that PIE is a major
improvement over drop-tail. I'd settle for a variant of fq_codel that gets and
uses information about whether the current packet request might be aggregated
with the previous packet provided, and adjusts its choice of packet accordingly.
At the same time, models would undoubtedly be useful to help test and
repeatably demonstrate the advantages of both simple and more sophisticated
solutions. Ns3 allows laying out a reasonably complex radio environment, which
is great for this. To counter the prevalence of one-station Faraday cage tests
in the industry, the simulated environments should represent realistic,
challenging use cases:
1) the family home, with half a dozen client devices competing with several
interference sources (Bluetooth, RC toys, microwave oven, etc). This is a
relatively easy environment, representing the expected environment for consumer
equipment.
2) the apartment block, with fewer clients per AP but lots of APs distributed
throughout a large building. Walls and floors may provide valuable attenuation
here - unless you're in Japan, where they can be notoriously thin.
3) the railway carriage, consisting of eighty passengers in a 20x3 m space, and
roughly the same number of client devices. The uplink is 3G based and has some
inherent latency. Add some Bluetooth for flavour, stir gently. This one is
rather challenging, but there is scope to optimise AP antenna placement, and to
scale the test down slightly by reducing seat occupancy.
4) the jumbo jet, consisting of several hundred passengers crammed in like
sardines. The uplink has satellite latencies built in. Good luck.
5) the business hotel. Multiple APs will be needed to provide adequate coverage
for this environment, which should encompass the rooms as well as lounge,
conference and dining areas. Some visitors may bring their own APs, and the
system must be able to cope with this without seriously degrading performance.
6) the trade conference. A large arena filled with thousands of people.
Multiple APs required. Good luck.
I also feel that ultimately we're going to have to get industry on board. Not
just passively letting us play around as with ath9k, but actively taking note
of our findings and implementing at least a few of our ideas themselves. Of
course, tools, models and real-world results are likely to make that easier.
- Jonathan Morton
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
