Re: [tcpm] TCP Tuning for HTTP - update

Joe Touch <> Thu, 18 August 2016 23:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8142912D511 for <>; Thu, 18 Aug 2016 16:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.168
X-Spam-Status: No, score=-8.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qc5grRWdxwWN for <>; Thu, 18 Aug 2016 16:09:30 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4145A12D18E for <>; Thu, 18 Aug 2016 16:09:30 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baWMy-0001xY-On for; Thu, 18 Aug 2016 23:05:04 +0000
Resent-Date: Thu, 18 Aug 2016 23:05:04 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baWMu-0000K0-0r for; Thu, 18 Aug 2016 23:05:00 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <>) id 1baWMs-000334-2s for; Thu, 18 Aug 2016 23:04:59 +0000
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u7IN3BkG029348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Aug 2016 16:03:11 -0700 (PDT)
To: Willy Tarreau <>
References: <> <> <> <> <> <> <> <> <> <> <>
Cc: Matthew Kerwin <>, Mark Nottingham <>,, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
From: Joe Touch <>
Message-ID: <>
Date: Thu, 18 Aug 2016 16:03:08 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: u7IN3BkG029348
X-ISI-4-69-MailScanner: Found to be clean
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1baWMs-000334-2s f7ad031b369641c4f9c7c895c29ec4e9
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32322
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi, Willy,

Yes - this is yet another example of TCP's "twisty maze of passages, all
alike" ;-)


On 8/18/2016 3:05 PM, Willy Tarreau wrote:
> On Thu, Aug 18, 2016 at 02:52:31PM -0700, Joe Touch wrote:
>> The PSH bit forces data not to be aggregated by the sending TCP (i.e.,
>> to gather multiple send() calls) and forces the receiver to do the same,
>> but I don't see anywhere that PSH forces ACK compression to be
>> circumvented.
> No that's not what I was saying, just that it was often avoiding the
> extra 200ms delay before sending the ACK for the odd segment number
> which further amplifies the ACK compression issue.
>> If you have a pointer that'd be useful (I'm speaking of an
>> RFC). I looked for "delayed ACK" (the term used in of RFC 1122)
>> and could not find any indication of a relation to PSH there, in fact
>> the delayed ACK discussion has no exceptions at all.
> On some systems you can force to have delayed ACKs even on PSH, I do it
> on linux (disable quick-ack). That's very useful to merge the response
> with the ACK for the request. But these are tricky must not be abused.
>> Additionally, that were true, setting the PSH bit constantly could cause
>> TCPs to open their slow-start windows much faster (2x per RTT, rather
>> than 1.5x as currently).
> I wasn't aware.
>>> But I've met some 3G networks
>>> where ACK compression was causing excessive retransmits from the
>>> sender, resulting in excess retransmits of ACKs in turn, maintaining
>>> the ACK link congested. It generally gets worse with many parallel
>>> connections than with a single one, and in this regard HTTP/2 has
>>> improved things a lot.
>> Most TCP variant assume that loss=congestion; that's often the wrong
>> interpretation for wireless.
>> (exceptions include TCP variants tuned for wireless)
> Yep definitely. And it's even worse with deep buffers at the intersection
> of fast and slow networks like the RAN for some mobile operators because
> the stacks here tend to be tuned to assume that a loss is a loss and cause
> fast retransmit which further fill the RAN's buffers. Sometimes the uplink
> is filled with ACKs and I even found it could be efficient to kill one every
> two ACKs in such a case. But I think this asymmetry is progressively going
> away in favor of more balanced links.
> Willy