General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Michael Welzl <michawe@ifi.uio.no>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] sigcomm wifi
Date: Mon, 25 Aug 2014 10:33:57 +0200	[thread overview]
Message-ID: <A46F4F5E-70D2-4398-9D1F-C94DD7CC84D1@ifi.uio.no> (raw)
In-Reply-To: <B5092C96-9556-4BF7-86CA-43F7E9D93C26@gmx.de>


On 25. aug. 2014, at 10:19, 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 ;)

That would be VERY good I think!!!!

As for the actual recommendations, I think we'll also need a lower minimum to avoid that a single random collision that has nothing to do with any real overload causes a TCP reaction. THAT number could be 3, for example.

Then, we typically have a default value of retransmissions in today's equipment - I think that number is usually something in the order of 10. So yes, that limit could be replaced with something like "min(10 retransmissions, 20ms)". I actually wonder what magnitude we can really reach in a practical system - e.g., is 20ms way beyond realistic in a super crowded network? Worth analyzing I guess.

Cheers,
Michael


  reply	other threads:[~2014-08-25  8:34 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 [this message]
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
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=A46F4F5E-70D2-4398-9D1F-C94DD7CC84D1@ifi.uio.no \
    --to=michawe@ifi.uio.no \
    --cc=bloat@lists.bufferbloat.net \
    --cc=moeller0@gmx.de \
    /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