Re: [tcpm] TCP Tuning for HTTP - update

Willy Tarreau <> Thu, 18 August 2016 22:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B2B0612D777 for <>; Thu, 18 Aug 2016 15:11:27 -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 I4DAN-UguCKN for <>; Thu, 18 Aug 2016 15:11:26 -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 9865612D73A for <>; Thu, 18 Aug 2016 15:11:26 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baVTJ-0005NO-8I for; Thu, 18 Aug 2016 22:07:33 +0000
Resent-Date: Thu, 18 Aug 2016 22:07:33 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baVTD-0005Lj-7V for; Thu, 18 Aug 2016 22:07:27 +0000
Received: from ([] by with esmtp (Exim 4.80) (envelope-from <>) id 1baVTB-00039K-Kz for; Thu, 18 Aug 2016 22:07:26 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id u7IM5vYE018100; Fri, 19 Aug 2016 00:05:57 +0200
Date: Fri, 19 Aug 2016 00:05:57 +0200
From: Willy Tarreau <>
To: Joe Touch <>
Cc: Matthew Kerwin <>, Mark Nottingham <>,, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.0 (2016-04-01)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.5
X-W3C-Hub-Spam-Report: AWL=-0.574, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1baVTB-00039K-Kz 784b38bfdff156b2dd4aa2d070cc2ff3
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32321
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.