Re: [Bloat] sigcomm wifi

[David Lang <david@lang.hm>]

On Mon, 25 Aug 2014, Sebastian Moeller wrote:

> Hi Michael,
>
> On Aug 25, 2014, at 10:01 , Michael Welzl <michawe@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