<div dir="ltr">Hi David,<div><br></div><div>Thanks for the discussion and tolerating hearing what you already know. </div><div><br></div><div>Per Jaffe, TCP can't be optimized to achieve maximum network power (avg throughput / latency) because an end host (or TCP end) only has only local knowledge. I think that's why things like HULL are setting the CE bit and why we have so many TCP control loops none of which can determine the true "near congestion point." With wireless links, the STAs aren't limited to local knowledge because their PHYs are always listening to the medium. I think this helps chip fw towards the ability to detect the input rate as exceeding the possible service rate (as defined by "congestion" and/or "free spectrum" - whatever those terms mean as neither are related to physics. ;) If this is the case, the chip fw can determine, and may be able to predict, with STA state when the "queued traffic on LAN reached threshold."</div><div><br></div><div>Per 802.11ax the AP will need to have virtual output queues to work with downlink OFDMA. Those transmits are truly "in parallel" which requires the multiple queues on the AP. So I don't perceive the two queues feeding one queue "engineering phenomena" lasting forever.<br><br>I'm no mesh expert but it does seem suboptimal that a transmit from STA A to STA B needs to be forwarded by an AP if STA B received the energy from A at an SINR that it allows it to decode the packet. In this case, the ack could come from B to A directly and the AP could drop what it heard. No ack from the real destination, then the AP forwards.<br><br>Though with 802.11ax, it's all centered around the AP for scheduling , i.e. all transmits even on STAs are "triggered" and the AP sets the transmit powers so uplink OFDMA works. I'm not sure how well 802.11ax plays with mesh.<br><br>Just some more random thoughts and thanks again for the discussion.</div><div><br></div><div>Bob</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 11, 2019 at 8:17 PM David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="arial" size="3"><p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">Bob - I was focusing on the standard Listen-Before-Talk CSMA MAC approach in the current 802.11 through the ac variant. 802.11ax is, of course, a whole different MAC layer, and its queuing management issues for IP end-to-end congestion management will be different.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">It seems likely to me that by being more oriented around AP-centered scheduling it will behave more like a single shared queue without fairness at the IP flow level. Since bufferbloat is essentially caused by queuing below the IP layer without providing timely feedback to the IP endpoints, I don't think 802.11ax can fix bufferbloat by itself. Some kind of "queued traffic on LAN reached threshold" message needs to be made available to the IP forwarding mechanism in each MAC STA and AP in 802.11ax in order to mitigate lag under load. And IP flow-level fairness needs to be implementable by the IP forwarding layet (ideally collectively among all sharing the up channel, which AP scheduling of the uplink can achieve, maybe).</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">I was peripherally involved in the "self-cancellation" PHY research at MIT at one point, and I know of the other experiments out in the Bay Area. It does look promising, but the issue I was pointing out is still there: if STA A and STA B send to each other, the AP-STA links are still a shared queue that can transmit only one packet at a time. So while there is some simultaneity from the PHY level, there are still two uplink queues feeding into a single downlink queue in the paths between A and B when there is an AP involved as an intermediary. Thats what I was pointing out as the complex queue-dynamics issue.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">Glad to hear that full duplex is being explored for commercial use now. It will certainly double the capacity using the same airtime for twice as much. I won't spend time pointing out that there are even better opportunities that get more than 2x for an N-node WLAN, by going to physical level repeaters. (but that's still all theory, not reduced to practice in labs, except a little bit).</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">-----Original Message-----<br>From: "Bob McMahon" <<a href="mailto:bob.mcmahon@broadcom.com" target="_blank">bob.mcmahon@broadcom.com</a>><br>Sent: Sunday, February 10, 2019 9:18pm<br>To: "David P. Reed" <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>><br>Cc: "Jonathan Morton" <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>>, "Make-Wifi-fast" <<a href="mailto:make-wifi-fast@lists.bufferbloat.net" target="_blank">make-wifi-fast@lists.bufferbloat.net</a>><br>Subject: Re: [Make-wifi-fast] bloated ath10k<br><br></p>
<div id="gmail-m_3163149073501830285gmail-m_7221452533324421824SafeStyles1549895092">
<div dir="ltr">
<div dir="ltr">Just a reminder with 802.11ax uplink OFDMA that STA A and B transmits can be "concurrent." Also, there are companies working on full duplex per self cancellation. Kumu networks is one
<div><a href="http://kumunetworks.com/" target="_blank">http://kumunetworks.com/</a></div>
<div>Bob</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div class="gmail_attr" dir="ltr">On Mon, Feb 11, 2019 at 12:30 AM David P. Reed <<a href="mailto:dpreed@deepplum.com" target="_blank">dpreed@deepplum.com</a>> wrote:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">Side note: between two stations talking through an AP, it's not half duplex. It's kind-of quarter-duplex. Each packet between STA A and STA B cannot be concurrent with the subsequent packet from A to B, and both transmissions of a packet from B to A.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">That actually has a significant effect on "queue depth". Please don't call it "interference", because no packet corruption happens.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">This is why merely fixing the queueing discipline in the AP alone doesn't necessarily ameliorate bufferbloat. The queues in the STA's need to be managed, too.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">You guys know that implicitly, I know I'm not telling you anything you don't know. But this queueing needs to be managed in such a way that the backoff in TCP is signaled. That is, packets need to be dropped or marked. You can't fix this in the forwarding paths alone.</p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt"> </p>
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">-----Original Message-----<br>From: "Jonathan Morton" <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>><br>Sent: Sunday, February 10, 2019 7:38am<br>To: "Adrian Popescu" <<a href="mailto:adriannnpopescu@gmail.com" target="_blank">adriannnpopescu@gmail.com</a>><br>Cc: <a href="mailto:make-wifi-fast@lists.bufferbloat.net" target="_blank">make-wifi-fast@lists.bufferbloat.net</a><br>Subject: Re: [Make-wifi-fast] bloated ath10k<br><br></p>
<div id="gmail-m_3163149073501830285gmail-m_7221452533324421824gmail-m_-3728292119382946551SafeStyles1549824769">
<p style="margin:0px;padding:0px;font-family:arial;font-size:12pt">> On 10 Feb, 2019, at 2:24 pm, Adrian Popescu <<a href="mailto:adriannnpopescu@gmail.com" target="_blank">adriannnpopescu@gmail.com</a>> wrote:<br>> <br>> My attempts to use SQM and codel to reduce wifi bloat didn't seem to get me very far. 802.11ac seems more reliable and it seems to be more bloated. ath9k can go as low as 3-5 milliseconds. ath10k is usually in the 20-50 milliseconds range (or more, based on the number of stations). I usually test with a single client as I don't expect latency to improve with more clients.<br><br>Some things are unavoidable when you move to a shared, half-duplex, noisy medium like wifi versus a switched, full-duplex, error-free medium like Ethernet.<br><br>If you're getting 20-50ms under load, then I think things are working quite well with wifi. We can wish for better, but not long ago you could be looking at multiple seconds in bad cases. At the levels you're now seeing, ordinary interactive protocols like DNS and HTTP will work reliably and quickly, and even VoIP should be able to cope; you'll likely only really notice a problem with online games.<br><br>Ath9k has some advantages over ath10k in this area. Its MAC is managed at a lower level by the driver, so we have much more control over it when trying to debloat. I think we still have more control over ath10k than most of the alternatives.<br><br>If low latency is mission critical, though - just run a wire.<br><br> - Jonathan Morton<br><br>_______________________________________________<br>Make-wifi-fast mailing list<br><a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferbloat.net</a><br><a href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></p>
</div>
_______________________________________________<br> Make-wifi-fast mailing list<br><a href="mailto:Make-wifi-fast@lists.bufferbloat.net" target="_blank">Make-wifi-fast@lists.bufferbloat.net</a><br><a rel="noreferrer" href="https://lists.bufferbloat.net/listinfo/make-wifi-fast" target="_blank">https://lists.bufferbloat.net/listinfo/make-wifi-fast</a></blockquote>
</div>
</div></font></blockquote></div>