General list for discussing Bufferbloat
 help / color / mirror / Atom feed
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

  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