Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <> Sun, 11 October 2015 03:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 49F891A8844; Sat, 10 Oct 2015 20:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vyBcpjsejv8G; Sat, 10 Oct 2015 20:55:20 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1080A1A88C4; Sat, 10 Oct 2015 20:55:20 -0700 (PDT)
Received: from ( []) by (8.13.4/8.13.4/Debian-3) with ESMTP id t9B3tEbQ001138; Sat, 10 Oct 2015 20:55:14 -0700
Date: Sat, 10 Oct 2015 20:55:14 -0700 (PDT)
From: David Lang <>
To: Jonathan Morton <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <>
Cc: "" <>, Joe Touch <>, Dave Taht <>, "" <>, "LAUTENSCHLAEGER, Wolfram \(Wolfram\)" <>, Greg White <>, "" <>
Subject: Re: [aqm] [tcpm] TCP ACK Suppression
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion list for active queue management and flow isolation." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 11 Oct 2015 03:55:21 -0000

On Sun, 11 Oct 2015, Jonathan Morton wrote:

>> On 11 Oct, 2015, at 02:06, Dave Taht <> wrote:
>> I would certainly have preferred a wifi world that instead of all
>> stations and APs highly contending for bursty access to a single
>> 320mhz channel, we had 160 dedicated, low latency, 5mhz channels, but
>> that is not what the IEEE has handed us.
> Dual radios would be a useful compromise - one 20-40 MHz channel to the AP, 
> one from it.  Stations would still need to negotiate for the channel in the 
> uplink direction, but the AP would be able to transmit on the downlink more 
> freely.

That helps less than you would think because there isn't just one AP in the 
area. There are multiple APs around on the same channel. Even in the best 
managed and coordinated wifi networks there are only so many channels and you 
_are_ going to end up re-using a channel in such a way that stations are going 
to hear more than one AP.

I run the wireless network for the Scale conference in Los Angeles, and I do a 
really good job with it (It's not just me bragging, see for a segment from the Linux 
Action Show from this years conference where they outright rant about how good 
things were compared to other places they've been). But even with RF sanity 
being my primary focus, and using 5GHz equipment, there is still going to be 
overlapping coverage. And on 2.4GHz, especially outside a carefully engineered 
environment, it's horrific.

The focus of thte IEEE and engineers on per-station speed in an isolated 
evironment is pushing things in the wrong direction. With 802.11ac (and cell 
LTE networks) we are gaining the ability for the fixed stations to transmit to 
more than one mobile station at the same time on a single channel, but that only 
adds to the bandwidth distortion and means that there will be even more acks 
being generated in response to a single AP txop.

David Lang