[Bloat] sigcomm wifi

[David Lang]

On Mon, 25 Aug 2014, Michael Welzl wrote:

>> But this cache of recently sent packets is separate from a queue of packets waiting to be sent.
>>
>> the size of the buffer used to track what's been sent isn't a problem. the 
>> bufferbloat problem is aroudn the size of the queue for packet waiting to be 
>> sent.
>
> This confuses me. Why do you even need a cache of recently sent packets?

so that you can re-send them.

if you are the originator of the packet, you need to have this.

If your are relaying packets over some media that has link-level acks you need 
this for all packets you relay as well

> Anyway, what I am talking about *is* the size of the queue for packets waiting 
> to be sent - and not only due to aggregation but also link layer retransmits. 
> Per device, at the link layer, packets (frames, really) are sent in sequence 
> AFAIK, and so any frame that has been sent but not yet acknowledged and then 
> has to be resent if it isn't acknowledged holds up all other frames to that 
> same destination.
>
>
>
>>>> If people are retrying when they really don't need to, that cuts down on the avialable airtime.
>>>
>>> Yes
>>>
>>>
>>>> But if you have continual transmissions taking place, so you have a hard time getting a chance to send your traffic, then you really do have congestion and should be dropping packets to let the sender know that it shouldn't try to generate as much.
>>>
>>> Yes; but the complexity that I was pointing at (but maybe it's a simple parameter, more like a 0 or 1 situation in practice?) lies in the word "continual". How long do you try before you decide that the sending TCP should really think it *is* congestion?  To really optimize the behavior, that would have to depend on the RTT, which you can't easily know.
>>
>> Again, I think you are mixing two different issues here.
>
> No, I think you misunderstand me -
>
>
>> 1. waiting for a pause in everyone else's transmissions so that you can 
>> transmit wihtout _knowing_ that you are going to clobber someone
>>
>>  Even this can get tricky, is that station you are hearing faintly trying to 
>> transmit to a AP near you so you should be quiet? or is it transmitting to a 
>> station enough further away from you so you can go ahead and transmit your 
>> packet to your AP without interfering with it?
>
> You mean the normal CSMA/CA procedure ( + RTS/CTS)? Sure that's tricky in 
> itself but I wasn't talking about that.
>
>
>> 2. your transmission gettng clobbered so the packet doesn't get through, 
>> where you need to wait 'long enough' to decide that it's not going to be 
>> acknowledged and try again.
>
> I was always only talking about that second bit. I'm sure I wasn't clear 
> enough in writing and I'm sorry for that.
>
>
>>  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.

A proxy should simplify this, because the total connection RTT now is client <-> 
AP <-> proxy, not client <-> AP <-> Internet <-> server.

if you can _know_ that the endpoint of the connection is a local proxy that's 
only 10ms away, you don't need to have timeouts long enough to handle a 
multi-second connection to a server on the other side of the world with you both 
using satellite links

David Lang