Re: [aqm] [tcpm] TCP ACK Suppression

David Lang <> Sat, 10 October 2015 00:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3E4E1B29FC; Fri, 9 Oct 2015 17:22:45 -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 0EZCvbYePVSd; Fri, 9 Oct 2015 17:22:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D2B661B29F7; Fri, 9 Oct 2015 17:22:43 -0700 (PDT)
Received: from ( []) by (8.13.4/8.13.4/Debian-3) with ESMTP id t9A0Mdae025729; Fri, 9 Oct 2015 17:22:39 -0700
Date: Fri, 9 Oct 2015 17:22:39 -0700 (PDT)
From: David Lang <>
To: Joe Touch <>
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: "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 00:22:45 -0000

accusing people of discussing in bad faith because of their business model, 
short sightedness, or other failing is not a good approach to take.

This discussion started from AQM and the smart things that can be done on the 
data in the queues. If TCP is to remain purely "end to end" as you want it to 
be, AQM should not exist, because it re-orders packets.

You don't want to acknowlege it, but TCP is broken in the face of excessive 
buffering. TCPM isn't fixing that, grassroots efforts are developing the fixes 
and AQM is formalizing the results.

TCP is also broken in the face of current and within-the-next-year future wifi 
technologies. AQM helps some here, and there is again outside efforts to address 
the problem. TCPM hasn't done anything that I've heard of other than possibly 
say that the network technology is broken and shouldn't be used.

Guess what, all existing Wifi and Cell networks are not going to be scrapped 
just because you don't like them. Especially when people are demonstrating ways 
to significantly improve performance there.

David Lang

On Fri, 9 Oct 2015, Joe Touch wrote:

> FWIW, I'm using "you" metaphorically, both here and in other posts.
> I.e., whomever is pushing this solution is supporting a business model
> that's broken. I don't much care whether the proponents are employed by
> that business or not.
> There is always tension between commercial interests (and proponents)
> and the model of the Internet. The Internet presents a dangerous
> opportunity for incredible gain without responsibility.
> The tragedy of the commons is very real, and this is a good example of
> it. It doesn't matter whether the solutions are being pushed by those
> profiting or by those who see only the local, short-term benefit rather
> then the potential long term impact.
> As has been discussed on TCPM, there may be ways to reduce the impact of
> ACKs on the net without having an intermediate device interfere. Let's
> have that discussion there and work together on a solution that benefits
> everyone - avoiding unnecessary load on the net AND preserving the E2E
> semantics of TCP so it can continue to evolve for future capabilities.
> Joe
> On 10/9/2015 4:31 PM, David Lang wrote:
>> On Fri, 9 Oct 2015, Joe Touch wrote:
>>>> If you have one person trying to watch streaming video while another
>>>> person is uploading pictures to facebook, you can run into trouble at
>>>> much more even ratios.
>>> Restated, you run into trouble because you sold a service you didn't
>>> provision for ;-)
>>> (or, more to the point, you took a gamble that you could sell a useful
>>> service with a particular assumption about traffic ratios, and that
>>> assumption no longer holds)
>>> Again, IMO TCP isn't to be tampered with merely to support a business
>>> model, and that's all I see so far.
>> Where did you get the idea that I work for an ISP, let alone a cable ISP
>> or had any influence in designing or building such networks. I don't.
>> You are assigning motives here that are clearly false.
>> As I keep re-stating, this is not a cable/DOCSIS issue, it applies to
>> all sorts of things, with Wifi and Cellular being the newest (and
>> arguably biggest) sources of the network flow getting quantomized.
>> David Lang