Hardware people tend to think about queues way too much in general. Queues should be almost never occupied. That causes the highest throughput possible. And getting there is simple: push queueing back to the source. The average queue length into a shared medium should be as close to zero as possible, and the variance should be as close to zero as possible. This is why smaller packets are generally better (modulo switching overhead). The ideal network is a network that maintains what I call a "ballistic" phase. (like a perfect metallic phase in a conductive material). It's easy to prove (as Kleinrock recently did with a student) that a network working optimally will have an average queue length everywhere that is less than 1 packet. I think that is achievable, *even if there is a WiFi network in the middle*, by thinking about the fact that the shared airwaves in a WiFi network behaves like a single link, so all the queues on individual stations are really *one queue*, and that the optimal behavior of that link will be achieved if there is at most one packet queued at a time. The problem with hardware folks and link folks is that they conflate the link with the network - two very different things. The priority (if there is any) should be resolved by pushing back at the source, NOT by queueing low priority traffic inside the network!
If you think deeply about this, it amounts to a distributed priority-managed source-endpoint-located queuing strategy. That is not actually hard to think about - when packets are dropped/ECN'd, the node that does the dropping knows a lot about the other competing traffic - in particular, it implicitly reflects some information about the existence of competing traffic to the source/dest pair (and in ECN, that can be rich information, like "the stated urgency of the competing traffic"). Then the decision about retransmitting can be pushed to the sources, with a lot of information about what's competing in the congested situation. This is *far* better than leaving a lot of low priority stuff clogging the intermediate nodes. So ignore the hardware folks who can't think about the fact that their link is embedded in a context that the link doesn't understand at all! Don't let them convince you to queue things, especially lower priority things.... instead push congestion back to the source!!! I know it is really, really productive of *research papers* to try to make a DSCP-based switching decision inside the network. But it is totally ass-backwards in the big picture of an Internet. On Thursday, July 30, 2015 11:27pm, "Sebastian Moeller" <moell...@gmx.de> said: > Hi Jonathan, > > > On July 30, 2015 11:56:23 PM GMT+02:00, Jonathan Morton > <chromati...@gmail.com> wrote: > >Hardware people tend to think in terms of simple priority queues, much > >like > >old fashioned military communications (see the original IP precedence > >spec). Higher priority thus gets higher throughput as well as lower > >latency. > > > >I note also that in 802.11e, leftover space in a TXOP can't be (or at > >least > >generally isn't) used opportunistically for traffic from another class, > >because the four queues are so rigidly separated. > > > >I think the hardware people are shortsighted in this respect. It's so > >easy > >to game simple priority queues when there's no filter on the field > >controlling it. That's why cake's Diffserv layer works the way it does. > >And > >if I ever get the chance to do a Wi-Fi specific version, I'll avoid > >both of > >the above problems. > > > >- Jonathan Morton > > Thanks for the insight. Now I Start to realize why my jome network behaves AS > it > does. When I run RRUL locally from my macbook over WiFi with cerowrt as AP > (which > if I recall correctly only uses AC_BE) the macbook's send starves the AP and > hence > the macbook's receive tanks. Since macos seems to exercise the AC_v[I|o] > queues, > it hogs airtime and and all systems using lower AC classes see less airtime, > less > bandwidth and higher latency. I guess my gut feeling would be to run the AP > always > at AC_VO so it does not get starved. But really calling such a system where > any > station can inflict that much pain/badness on others 'quality of service' > makes me > wonder. Then again it certainly affects quality of service just not > deterministic > or overall positive ;) > > Best Regards > Sebastian > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel >
_______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
