From: David Lang <david@lang.hm>
To: Michael Welzl <michawe@ifi.uio.no>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] sigcomm wifi
Date: Sun, 31 Aug 2014 15:35:26 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.02.1408311530150.23856@nftneq.ynat.uz> (raw)
In-Reply-To: <8C18A920-D0A8-4052-85EC-FF6D6039FD53@ifi.uio.no>
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
next prev parent reply other threads:[~2014-08-31 22:35 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 16:45 Dave Taht
2014-08-20 7:12 ` Eggert, Lars
2014-08-20 14:01 ` Dave Taht
2014-08-20 22:05 ` Jim Gettys
2014-08-21 6:52 ` Eggert, Lars
2014-08-21 7:11 ` Michael Welzl
2014-08-21 8:30 ` David Lang
2014-08-22 23:07 ` Michael Welzl
2014-08-22 23:50 ` David Lang
2014-08-23 19:26 ` Michael Welzl
2014-08-23 23:29 ` Jonathan Morton
2014-08-23 23:40 ` Steinar H. Gunderson
2014-08-23 23:49 ` Jonathan Morton
2014-08-24 1:33 ` David Lang
2014-08-24 2:29 ` Jonathan Morton
2014-08-24 5:12 ` David Lang
2014-08-24 6:26 ` Jonathan Morton
2014-08-24 8:24 ` David Lang
2014-08-24 9:20 ` Jonathan Morton
2014-08-25 7:25 ` Michael Welzl
2014-08-30 7:20 ` Jonathan Morton
2014-08-31 20:46 ` Simon Barber
2014-08-25 7:35 ` Michael Welzl
2014-08-24 1:09 ` David Lang
2014-08-25 8:01 ` Michael Welzl
2014-08-25 8:19 ` Sebastian Moeller
2014-08-25 8:33 ` Michael Welzl
2014-08-25 9:18 ` Alex Burr
2014-08-31 22:37 ` David Lang
2014-08-31 23:09 ` Simon Barber
2014-09-01 0:25 ` David Lang
2014-09-01 2:14 ` Simon Barber
2014-08-31 22:35 ` David Lang [this message]
2014-08-21 6:56 ` David Lang
2014-08-21 7:04 ` David Lang
2014-08-21 9:46 ` Jesper Dangaard Brouer
2014-08-21 19:49 ` David Lang
2014-08-21 19:57 ` Steinar H. Gunderson
2014-08-22 17:07 ` Jan Ceuleers
2014-08-22 18:27 ` Steinar H. Gunderson
2014-08-21 8:58 ` Steinar H. Gunderson
2014-08-22 23:34 ` David Lang
2014-08-22 23:41 ` Steinar H. Gunderson
2014-08-22 23:52 ` David Lang
2014-08-22 23:56 ` Steinar H. Gunderson
2014-08-23 0:03 ` Steinar H. Gunderson
2014-08-21 9:23 ` Mikael Abrahamsson
2014-08-21 9:30 ` Steinar H. Gunderson
2014-08-22 23:30 ` David Lang
2014-08-22 23:40 ` Steinar H. Gunderson
2014-08-20 8:30 ` Steinar H. Gunderson
2014-08-21 6:58 ` David Lang
2014-08-24 3:49 Hal Murray
2014-08-24 3:52 ` Jonathan Morton
2014-08-24 5:14 ` David Lang
2014-08-25 7:43 ` Michael Welzl
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.02.1408311530150.23856@nftneq.ynat.uz \
--to=david@lang.hm \
--cc=bloat@lists.bufferbloat.net \
--cc=michawe@ifi.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox