[Bloat] sigcomm wifi

[Simon Barber]

The right concept for WiFi would be TQL, time queue limit. This is needed because in wifi there can be several orders of magnitude difference in the speed (transmission rate) that different packets are sent at. The purpose of the hardware queue is to cover for the interrupt latency, ie the time delay required to keep the queue filled. Thus accounting for the time it will take to transmit the packets is important. For wired interfaces with a fixed speed byte counting works fine. Byte counting does not work in a wireless environment where the same number of bytes can take 2 or 3 different orders of magnitude of time to transmit. Accounting for the expected minimum transmission time is critical.

Simon

On August 31, 2014 3:37:07 PM PDT, David Lang <david at lang.hm> wrote:
>On Mon, 25 Aug 2014, Sebastian Moeller wrote:
>
>> Hi Michael,
>>
>> On Aug 25, 2014, at 10:01 , Michael Welzl <michawe at ifi.uio.no> wrote:
>> [...]
>>>
>>>> This is a case where a local proxy server can actually make a big
>difference 
>>>> to you. The connections between your mobile devices and the local
>proxy 
>>>> server have a short RTT and so all timeouts can be nice and short,
>and then 
>>>> the proxy deals with the long RTT connections out to the Internet.
>>>
>>> Adding a proxy to these considerations only complicates them: it's a
>hard 
>>> enough trade-off when we just ask ourselves: how large should a
>buffer for 
>>> the sake of link layer retransmissions be?  (which is closely
>related to the 
>>> question: how often should a link layer try to retransmit before
>giving up?) 
>>> That's what my emails were about. I suspect that we don't have a
>good answer 
>>> to even these questions, and I suspect that we'd better off having
>something 
>>> dynamic than fixed default values.
>>
>> 	What about framing the retransmissions not in number but rather in
>time? 
>> For example the maximum of either time to transmit a few (say 3?)
>packet at 
>> the current data rate (or maybe one rate lower than current to allow 
>> setoriating signal quality) or 20ms (pulled out of thin air, would
>need some 
>> research). The first should make sure we actually retransmit to
>overcome 
>> glitches, and the second should make sure that RTT does not increase
>to 
>> dramatically. This basically assumes that for reasonable interactive
>traffic 
>> we only have a given RTT budget and should make sure not to overspend
>;)
>
>Yep, just like BQL helped a lot on the wired side, because it's a good
>stand-in 
>for the time involved, we need to get the same concept through the wifi
>stack 
>and drivers.
>
>David Lang
>_______________________________________________
>Bloat mailing list
>Bloat at lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20140831/7892cd32/attachment-0002.html>