[Bloat] The wireless problem in a nutshell

[Dave Täht]

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

> On Sun, Feb 6, 2011 at 6:41 PM, Dave Täht <d at 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