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
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
