Re: [aqm] [tcpm] TCP ACK Suppression

Dave Taht <> Sat, 10 October 2015 23:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AD9451ACEF9; Sat, 10 Oct 2015 16:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id awMy6Jebpb4d; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA3C81A1B7F; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
Received: by oiar126 with SMTP id r126so21160626oia.0; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lSHgxMg8OkPHJwtYn6wJ2lVgFljJa6rpzInZDBVsBPk=; b=PJNsw97Jmqf0Sh7SbBcG138G+CTG7CqWfInl+hHRMcIYFPe6Et7vWr8dAw5Fmjs6jC 2hanL+dZbM426iLWAAacrVaaWW8J+l/DYNuPatDOYvTOPmY3anEjowdFBs/YDQZJOgln RgSBKo3FpJex0UjQfiDxF0hu/de02xElvo+OW902Bf9QHdoELmMOdvc6n16G9f5gHrSe 2VgUdSTND1ywiRYHxFGuWyky3v/v3KEE7PiBuc5VQrZFhb/SZEQjJn16S/ne4+YZ8FQi e77T4LdfLv5/V4jCku1tNsODx2ScouygKbvFY3JqBgLfDvNrZ4bjUggo5a/Iv0dTzR24 zlig==
MIME-Version: 1.0
X-Received: by with SMTP id 69mr11563498oil.110.1444518394055; Sat, 10 Oct 2015 16:06:34 -0700 (PDT)
Received: by with HTTP; Sat, 10 Oct 2015 16:06:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Sat, 10 Oct 2015 16:06:33 -0700
Message-ID: <>
From: Dave Taht <>
To: David Lang <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>, Joe Touch <>, "" <>, "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: Sat, 10 Oct 2015 23:06:36 -0000

I have been busy with other matters and unable to keep up on this thread.

I just wanted to say that I'm with dlang here... aggregated and
asymmetric transmits in wifi, cell, and cable, are here to stay. Deal
with it.

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.

On Fri, Oct 9, 2015 at 10:58 PM, David Lang <> wrote:
> On Fri, 9 Oct 2015, Joe Touch wrote:
>> On 10/9/2015 7:14 PM, David Lang wrote:
>>> The problem with proposals like that is just like RFC3449 says, the
>>> source can't know what the network looks like to decide if there is a
>>> benefit to reducing ACKs.
>> To understand your position, is your conclusion that if it benefits a
>> single place in the network, then that's enough of a view to know that
>> it's safe and beneficial throughout the network?
> No.
> But when something shows clear beneifts when deployed, clear problems need
> to be identified to counter those benefits, or alturnative methods of
> solveing the problem need to be shown.
> I didn't know about it initially (I was working from experience and logic),
> RFC3449 has explored many of the problems that cause and result from fewer
> than 1 ACK per 2 data packets, including worrying about the timing of the
> ACK packets.
> As much as you seem to want to make this discussion about cable modems and
> highly assymetric links, this discussiona ctually started  from the position
> of packets in a particular flow being sent in bursts due to non-endpoint
> related reasons. It started with AQM queues, but radio networks (Wifi and
> Cell) have similar behavior (packets queue until a transmit window is
> available, tehn a bunch are sent at once)
> Cable modems were introduced to the discussion to counter the thought that
> sending fewer ACKs would destroy the Intenet.
> RFC3449 doesn't completely address the current situation, but it provides a
> very good place to start, and it seems to me that the solitions it explores
> to address the conerns that it (and you) raise are actually being addressed
> pretty completely. There are still some areas to talk about (ECN interaction
> for example) and we wshould be talking about those issues rather than
> arguing that the proposal violates holy writ.
> you want a network where packets are just forwarded with no modification and
> no delays. Unfortunantly such a network does not match the real world any
> longer (and it only approximated the real world in the first place) Shared
> media networks have existed since the earliest networking days. What is
> changing is theratio between the data speed when transmittingand the time
> available to transmit. Given the same number of stations in an area, I'll
> bet that old thinnet ethernet at 10Mb/s spent a significantly higher
> percentage of the time transmitting data than current Gb/s and immediate
> future 10Gb/s wireless networks. Just like wired network speeds are climbing
> with the MTU staying the ame, wireless network data rates are climbing but
> the time available for a given station is remaining the same (or shrinking),
> so the number of packets that get delayed until the next transmit slot are
> only going to keep climbing, no matter what anyone wants.
> The asymmetrical nature of the networks is just addng insult to injury, not
> the cause of the issues.
> Wireless networks are gaining the ability to transmit to multiple stations
> at once. But the nature of usage patterns and the physical geometry of the
> wired vs mobile ends of the link make the reality that only the wired end
> can effectively make use of this capability. this makes the availble
> downstream bandwidth on a network fabric grow much faster than the available
> upstream bandwidth. To some extent this will put less stress on the upstream
> side of the wired network it's attached to, but it will mean that the demand
> for mobile station transmit slots is only going to multiply. Just reducing
> the number of timeslots the base station uses isn't the answer because that
> will add latency to all the data downloads.
> IIRC, I saw a story today where one of the contenders for 5G cell networks
> is already at a ratio of 24:1 or worse.
> David Lang
> _______________________________________________
> aqm mailing list

Dave Täht
Do you want faster, better, wifi?