Re: [tcpm] TCP Tuning for HTTP - update

Joe Touch <> Thu, 18 August 2016 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D9F612D0C0 for <>; Wed, 17 Aug 2016 17:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.167
X-Spam-Status: No, score=-8.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 Ygd1268HNedb for <>; Wed, 17 Aug 2016 17:27:38 -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 6DCDC12B03F for <>; Wed, 17 Aug 2016 17:27:38 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baB7Y-0001FN-Kt for; Thu, 18 Aug 2016 00:23:44 +0000
Resent-Date: Thu, 18 Aug 2016 00:23:44 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baB7S-0001EF-8H for; Thu, 18 Aug 2016 00:23:38 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <>) id 1baB7M-0004fK-Ho for; Thu, 18 Aug 2016 00:23:34 +0000
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u7I0LNGJ015083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 17:21:24 -0700 (PDT)
To: Matthew Kerwin <>
References: <> <> <> <> <> <> <> <> <> <> <>
Cc: Willy Tarreau <>, Mark Nottingham <>,, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 17 Aug 2016 17:21:21 -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: multipart/alternative; boundary="------------F10D1AF5F07272054D777B16"
X-ISI-4-43-8-MailScanner: Found to be clean
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.4
X-W3C-Hub-Spam-Report: AWL=1.009, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1baB7M-0004fK-Ho 1c26841a759417762118fc0ac407bc64
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32299
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Popping up to the key point...

On 8/17/2016 4:35 PM, Matthew Kerwin wrote:
> Hi folks, I'm stepping in here on just a couple of points. I'll snip
> the bits I can't or won't talk to.
> Where we come from, how we find information to solve our problems, the
> way we view the IETF and its RFCs are all different. If this argument
> is just that this stuff doesn't belong in an RFC, that's a cultural
> issue and not one I think we can resolve in this one technical working
> group.

IMO, RFCs deal with *protocols* and protocol deployment issues.

Here that would mean for HTTP in specific
    - turn Nagle off
    - watch out for ACK compression effects (turn it off in favor of ABC
if you can)
    - deal with slow-start restart (there are a variety of approaches here)

You also want to be generally efficient with TCP, which isn't related to
HTTP but still good advice for all apps:
    - be generally efficient and robust (use SACK, ECN, good window
scaling, etc.)
    - watch out for resource overloads (use SYN cookies/fast open,
time-wait buildup, etc.)

That advice is useful for all TCP for transactions, too.

Here's what it definitely does not mean:
    - setting socket buffer sizes (that's an OS-ism, and may be useful
for app designers to know, but isn''t directly part of TCP or HTTP)
    - running an efficient server for small connections (that's a pure
implementation performance issue, and depends on OS support for things
like threads, process/thread pools, etc.)
I.e., OS-specific issues in running servers are not in scope IMO.

Keep in mind who reads RFCs - mostly protocol people. Managers take
training courses to get certification, and that's where they learn their
operational issues.