Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <> Sun, 11 October 2015 04:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 465641ACE46 for <>; Sat, 10 Oct 2015 21:02:59 -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 np1YkMh35ah3 for <>; Sat, 10 Oct 2015 21:02:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5DD71ACE44 for <>; Sat, 10 Oct 2015 21:02:57 -0700 (PDT)
Received: from ( []) by (8.13.4/8.13.4/Debian-3) with ESMTP id t9B42uIG001211; Sat, 10 Oct 2015 21:02:56 -0700
Date: Sat, 10 Oct 2015 21:02:56 -0700 (PDT)
From: David Lang <>
To: Simon Barber <>
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: <>
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 04:02:59 -0000

full duplex RF communication is HARD, and completely incompatible with existing 
stuff. Full duplex also doesn't really help when the problem is more than two 
stations communicating. And with the mu-mimo mode of operation where the AP is 
transmitting to multiple receivers at once, 'full duplex' between all the 
stations is orders of magnatude harder.

The biggest problem with the latest standards is that the per transmit overhead 
is not shrinking at all. Even as the data bitrates skyrocket, the management 
bitrates, quiet time requirements, etc remain static.

There would actually be far more benefits from scrapping these timings and 
re-setting them to match current high-speed capabilities than in going to 
full-duplex with the current timings in place. Unfortuantly, unless the new 
systems are on a newly opened frequency band, legacy requirements (existing 
networks continuing to operate, not just legacy equipment talking to new 
networks) make this hard. The fact that Wifi networks are not on a dedicated, 
regulated band and are instead in the 'free for all' bands means that it's not 
even possible to outlaw old stuff to make room for new stuff.

David Lang

On Sat, 10 Oct 2015, Simon Barber wrote:

> The next generation of WiFi is likely to include full duplex - it's about the 
> only physical layer thing left!
> Simon
> On 10/10/2015 4:12 PM, 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.