<font face="times new roman" size="2"><p style="margin:0;padding:0;">"Delays incurred by signal quality" needs some serious measurement work.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">While it's clear that 802.11 is degraded in both throughput and latency under signal quality variation, it's not at all clear what the effect looks like, and what it looks like actually matters.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">This depends a great deal on parameters that may be inaccessible or poorly set in the MAC layer of one or more nodes.  The following factors related to propagation environment are common in indoor environments:</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">1) What is the algorithm used to manage transmit power - in particular, how quickly does the automatic transmit power selectcut power or raise it?  And when it does, does it choose a different waveform or not?</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">2) what else radiates energy on the channel (since the protocol listens before talking for a good approximation of "radio silence" for 4 microseconds or so before any packet can be sent)? This has a different but significant effect from, say, hidden terminal problems.  Hidden 802.11 terminals only transmit occasionally, thus they don't degrade in the same way as a background "hum".</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">3) what kind of delays are caused by legacy 802.11g devices on 802.11n networks in 2.4 GHz?  They transmit slower, so occupy channel longer.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">4) What kind of delays are induced by accumulating frames into a single transmission, and where in the OS are frames merged - device firmware, device driver, or common layer 2 code in the OS?</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">Etc.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">The first order question should be:  how significant are such delays, in comparison to those involving overbuffering?</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">The second order question should be: can channel degradation affecting one pair of terminals cause starvation of another pair?</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">If these are small effects, focusing on them before implementing bufferbloat fixes and anti-starvation within one queue (fq in general does this), then I would suggest that we not proceed by *changing everything at once* without data that characterizes the problem vs. non-problem areas.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">There's lots of research already out there to draw on that started "imagine that wireless networks look like *this* (assumption X inserted here), what would be a great solution?" and then say "my cool XYZ algorithm optimizes [all? really, all of them?] wireless channels."    So it's not as if there are not a zillion PhD dissertations with approaches to pick from.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">But what we need to know is what the heck is going on - not in an imaginary ns2 simulation, but really in real, badly behaved but well-understood and otherwise problem-free networks.  (bufferbloat would hide such concerns really well, given multiple second queueing delays that arise under load.)</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">So, it doesn't matter what I *think* - it matters what the data tells us.  And we have very, very little data on propagation effects in 802.11.  Almost none.  That's not what the market focuses on.  The market measures highest speed in *perfect* propagation conditions.</p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;"> </p>
<p style="margin:0;padding:0;">-----Original Message-----<br />From: "Maciej Soltysiak" <maciej@soltysiak.com><br />Sent: Wednesday, January 9, 2013 8:52am<br />To: cerowrt-devel@lists.bufferbloat.net<br />Subject: [Cerowrt-devel] slightly OT: WMM<br /><br /></p>
<div id="SafeStyles1357742301">
<div>Hi,</div>
<div></div>
<div>Aside from reducing buffers and changing the queue management tactics, we're still interested in QoS and that's why we have tc filters, iptables MARKing, etc.</div>
<div></div>
<div>With regard to WLAN, what do you think about enabling or disabling WMM on WLAN NICs and ap/routers?</div>
<div></div>
<div>Supposing that applications or other mechanisms to proper DSCP or layer 2 tagging this should allow WMM to further do the prioritization on layer 1, however I've read a WMM-enabled station is like 4 stations competing for medium time. Is that analogy justified? Is that good or bad in terms of delays incurred by signal quality?</div>
<div></div>
<div>Regards,</div>
<div>Maciej</div>
<div></div>
</div></font>