<html><head></head><body>Indeed - minimum transmission time is the right metric. For wireless cards where transmission speed is determined by the host this should work very well, queue will be tightly controlled. Wireless cards that put a lot of intelligence in the card, ie packet transmission speed selection, are harder to handle well. In these cards to get good results you really need to move all the queueing code into the card, which is not going to happen. You're basically screwed and can't do a good job.<br>
<br>
Simon<br><br><div class="gmail_quote">On August 31, 2014 5:25:05 PM PDT, David Lang <david@lang.hm> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On Sun, 31 Aug 2014, Simon Barber wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> The right concept for WiFi would be TQL, time queue limit. This is needed <br /> because in wifi there can be several orders of magnitude difference in the <br /> speed (transmission rate) that different packets are sent at. The purpose of <br /> the hardware queue is to cover for the interrupt latency, ie the time delay <br /> required to keep the queue filled. Thus accounting for the time it will take <br /> to transmit the packets is important. For wired interfaces with a fixed speed <br /> byte counting works fine. Byte counting does not work in a wireless <br /> environment where the same number of bytes can take 2 or 3 different orders of <br /> magnitude of time to transmit. Accounting for the expected minimum <br /> transmission time is critical.<br /></blockquote><br />given that
conditions can change while data is in the queue, I think the right <br />answer is to size the queue based on the fastest possible transmission time <br />(otherwise you will be running the risk of emptying the queue). Yes, it will <br />lead to over buffering when the speed drops, but that would still be an <br />improvement over the current situation.<br /><br />David Lang<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Simon<br /><br /> On August 31, 2014 3:37:07 PM PDT, David Lang <david@lang.hm> wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> On Mon, 25 Aug 2014, Sebastian Moeller wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> Hi Michael,<br /><br /> On Aug 25, 2014, at 10:01 , Michael Welzl <michawe@ifi.uio.no>
wrote:<br /> [...]<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> This is a case where a local proxy server can actually make a big<br /></blockquote></blockquote></blockquote> difference<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> to you. The connections between your mobile devices and the local<br /></blockquote></blockquote></blockquote> proxy<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left:
1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> server have a short RTT and so all timeouts can be nice and short,<br /></blockquote></blockquote></blockquote> and then<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"> the proxy deals with the long RTT connections out to the Internet.<br /></blockquote><br /> Adding a proxy to these considerations only complicates them: it's a<br /></blockquote></blockquote> hard<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex;
border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> enough trade-off when we just ask ourselves: how large should a<br /></blockquote></blockquote> buffer for<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> the sake of link layer retransmissions be? (which is closely<br /></blockquote></blockquote> related to the<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> question: how often should a link layer try to retransmit before<br /></blockquote></blockquote> giving up?)<br /><blockquote
class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> That's what my emails were about. I suspect that we don't have a<br /></blockquote></blockquote> good answer<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> to even these questions, and I suspect that we'd better off having<br /></blockquote></blockquote> something<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> dynamic than fixed default values.<br /></blockquote><br /> What
about framing the retransmissions not in number but rather in<br /></blockquote> time?<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> For example the maximum of either time to transmit a few (say 3?)<br /></blockquote> packet at<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> the current data rate (or maybe one rate lower than current to allow<br /> setoriating signal quality) or 20ms (pulled out of thin air, would<br /></blockquote> need some<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> research). The first should make sure we actually retransmit to<br /></blockquote> overcome<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> glitches, and the second should make sure that RTT does
not increase<br /></blockquote> to<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> dramatically. This basically assumes that for reasonable interactive<br /></blockquote> traffic<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"> we only have a given RTT budget and should make sure not to overspend<br /></blockquote> ;)<br /><br /> Yep, just like BQL helped a lot on the wired side, because it's a good<br /> stand-in<br /> for the time involved, we need to get the same concept through the wifi<br /> stack<br /> and drivers.<br /><br /> David Lang<br /><hr /><br /> Bloat mailing list<br /> Bloat@lists.bufferbloat.net<br /> <a href="https://lists.bufferbloat.net/listinfo/bloat">https://lists.bufferbloat.net/listinfo/bloat</a><br /></blockquote></blockquote><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>