Re: [aqm] [tcpm] TCP ACK Suppression

Joe Touch <> Fri, 09 October 2015 22:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11A661B4DBF; Fri, 9 Oct 2015 15:24:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7c2oLuxqBIf9; Fri, 9 Oct 2015 15:24:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5888D1B4DB7; Fri, 9 Oct 2015 15:24:40 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t99MOJYS006232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Oct 2015 15:24:19 -0700 (PDT)
To: David Lang <>
References: <> <> <> <> <>
From: Joe Touch <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Fri, 9 Oct 2015 15:24:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Archived-At: <>
Cc: "" <>,, "" <>, "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: Fri, 09 Oct 2015 22:24:42 -0000

On 10/9/2015 3:16 PM, David Lang wrote:
>> Wouldn't it have been cleaner with more appropriate network provisioning?
> "more appropriate network provisioning" is not always going to result in
> more bandwidth the way you want it to.
> If there is established infrastructure that can handle X in one
> direction and 100X in the other direction, but "appropriate network
> provisioning" requires that the ratio never be more than 3x, it's not
> going to magically increase bandwidth in one direction, all it can do is
> cap bandwidth in the other direction (throwing away capacity)

Sure, but we're dealing with a problem that arises when the ratio can't
support 40:1. That's quite an asymmetry except in extreme cases where we
already know extreme measures are required (e.g., satcom with telco

>> Why are you blaming TCP?
> first off, didn't you see the smiley?
> But treating your question as serious, it's because as RFC3449 shows,
> highly assymetric networks or networks with other traffic on them don't
> work with TCP the way you want it to work. So the option is to modify
> TCP or tinker with the packets to leverage less commonly used features
> of TCP (or features that are implicit in the design rather than explicit)

The former is always on the table - that's what TCPM is for.

The latter has always been problematic, exactly because it's subject to
tragedy-of-the-commons. TCP is a contract between the endpoints, and
whenever a middlebox starts modifying those packets, IMO it becomes a
party to that contract that needs to be taken very seriously (smiley
faces aside ;-)

>> A DOCSIS router ought to route. If it left the packets alone, IMO we'd
>> all be better off.
> So you would rather have people getting slower downloads than have
> network equipment modify packets?

I would rather people get slower downloads than break TCP in ways we
won't see for 5 years or inhibit the extension of TCP in new ways that
might be even more beneficial.

> Those are the real-world choices.

There were other cable modem companies that tried similar "tricks" in
the past and got in a lot of hot water for making a box that went a LOT
faster for *their* customers.

TCP works when everyone plays by the same conservative rules. There has
always been a choice to break those rules for individual gain, and there
has always been a reason we try very hard to avoid that.