Re: [tcpm] TCP Tuning for HTTP - update

Joe Touch <> Thu, 18 August 2016 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F2D012D689 for <>; Thu, 18 Aug 2016 14:59:01 -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 vAcX_J4iSux5 for <>; Thu, 18 Aug 2016 14:59:00 -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 3C2E512D0B6 for <>; Thu, 18 Aug 2016 14:58:59 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baVGm-0003YB-Tr for; Thu, 18 Aug 2016 21:54:36 +0000
Resent-Date: Thu, 18 Aug 2016 21:54:36 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baVGi-0003XX-B3 for; Thu, 18 Aug 2016 21:54:32 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <>) id 1baVGh-0007IQ-0y for; Thu, 18 Aug 2016 21:54:31 +0000
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u7ILqX0N018654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 18 Aug 2016 14:52:34 -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 14:52:31 -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: u7ILqX0N018654
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: 1baVGh-0007IQ-0y 1111f10b534688e5792fd35155c7d508
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32320
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 8/18/2016 12:59 PM, Willy Tarreau wrote:
> On Thu, Aug 18, 2016 at 10:50:52AM -0700, Joe Touch wrote:
>> Hi, Willy,
>> On the issue of ACK compression effects:
>> On 8/17/2016 10:38 PM, Willy Tarreau wrote:
>>>>     - watch out for ACK compression effects (turn it off in favor of ABC
>>>>> if you can)
>>> It does not happen that much with HTTP. Many connections on the server side
>>> see only one, sometimes two requests, and most responses are small (about
>>> 20kB on average, with favicon fitting in a single segment). Note, I'm talking
>>> about observations on average web sites.
>> The effect is more pronounced for smaller responses, for any response
>> using an odd number of packets. The last odd packet will be stalled
>> because the client needs to timeout before it will send an ACK for a
>> single segment (it's waiting for the second segment).
> With short keep-alive responses yes but not short-lived connections
> since the server sends the FIN immediately afterwards, which hints
> the client not to wait for anything else and to ACK immediately.
If you have connection-per-transfer, but not if you have persistent
connections (the server wouldn't issue a close()).

>> It doesn't matter how many requests you have, but the impact can be
>> complicated on persistent connections.
> Yes I agree. Please note that usually the last segment of a message
> carries a push which precisely speeds up delivery to the application
> and acking (as most OSes ack on push but apparently not all), so it
> is not often emphasized that much.
PSH is optional.

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. 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.

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).

> 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)