General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: d@taht.net (Dave Täht)
To: Luca Dionisi <luca.dionisi@gmail.com>
Cc: bufferbloat list <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] The wireless problem in a nutshell
Date: Mon, 07 Feb 2011 04:31:45 -0700	[thread overview]
Message-ID: <8739o0f5cu.fsf@cruithne.co.teklibre.org> (raw)
In-Reply-To: <AANLkTi=1mfBk+ntqG5OSq-uw6KgLfjTNJUKC2sfMvi8V@mail.gmail.com> (Luca Dionisi's message of "Mon, 7 Feb 2011 09:56:43 +0100")

Luca Dionisi <luca.dionisi@gmail.com> writes:

> On Sun, Feb 6, 2011 at 6:41 PM, Dave Täht <d@taht.net> wrote:
>> I personally regard the wireless packet loss burst problem as completely
>> intractable for long TCP links without using proxies - or insane amounts
>> of buffering.
>
> Is this particular aspect going to be different once that nRED is complete?

I would love for nRED to compensate for both variable bandwidth and
bursty packet loss. 

I also would like the Easter bunny to visit this year, world peace be
achieved, and all four Beatles get back together.

I would love it if someone could pull this bunny out of the hat.I'd
settle for acceptable buffering at acceptable latencies with acceptable
packet loss under worst case conditions with good queue management - the
last nRED can solve, the rest requires hacking a lot of
over-optimistically designed device drivers.

> I mean, if you were in a mesh network, primarily made of wireless
> links, where the RTT becomes easily high, how could you make TCP links
> to behave right?

What I wrote about in the previous email was an in-home or final hop
wireless 802.11 network, and I tried to avoid the thorny issues of a
mesh network. I'll try, but I don't want my original point about "a
short RTT helps wireless TCP" to be lost. It's not well known.

You can apply all kinds of AQM (RED, etc) to either side of a one hop
wireless connection with a proxy to good effect. You can also apply
(some) level of buffering and/or remote acknowledgments to good
effect. (You have to anyway, I just tried to simplify out that part -
the various 802.11 standards about how/when/why 802.11 does retransmits
cover dozens of pages)

Moving on to mesh networks....

An encouraging thing about those is that you are carrying not one, but
dozens or hundreds of TCP streams. Assuming you are using some form of
weighted fair queuing, this means that a burst of lost packets
translates into a statistically small, random amount of packet loss
across many streams - which TCP can actually compensate for.

How long can the RTT get before TCP throughput drops? 

Good question.

That depends on your tolerance for latency and packet loss. You can
increase your RTT, and reduce packet drops, by using buffering at the
expense of latency. You can reduce your perceived latency for things
like DNS by locating caches throughout the network. You can/should put
proxies at certain average distances in the mesh (at one point I was
using BGP anycast, and later on I switched to DNS - I kind of regret
doing that - I wish babel did anycast)

A really negative thing about mesh networks is each hop is lossy. 

Anyway the discussion of bufferbloat has given me an idea regarding
using SACK more often that I'm dying to try out.


> --Luca

-- 
Dave Taht
http://nex-6.taht.net

  reply	other threads:[~2011-02-07 11:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-06 17:41 Dave Täht
2011-02-07  8:56 ` Luca Dionisi
2011-02-07 11:31   ` Dave Täht [this message]
2011-02-08 15:54     ` Justin McCann
2011-02-08 19:56 ` Juliusz Chroboczek
2011-02-08 21:54   ` Dave Täht
2011-02-10 18:39     ` Juliusz Chroboczek
2011-02-11 14:50     ` Dave Täht
2011-02-11 20:12       ` Stuart Cheshire

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=8739o0f5cu.fsf@cruithne.co.teklibre.org \
    --to=d@taht.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=luca.dionisi@gmail.com \
    /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