On Sun, 31 Aug 2014, Simon Barber wrote:
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.
given that
conditions can change while data is in the queue, I think the right
answer is to size the queue based on the fastest possible transmission time
(otherwise you will be running the risk of emptying the queue). Yes, it will
lead to over buffering when the speed drops, but that would still be an
improvement over the current situation.
David Lang
Simon
On August 31, 2014 3:37:07 PM PDT, David Lang <david@lang.hm> wrote:
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
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat