Re: [tcpm] TCP Tuning for HTTP - update

Joe Touch <> Wed, 17 August 2016 23:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8826B12D0FD for <>; Wed, 17 Aug 2016 16:07:34 -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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id StnYWuvCYwtJ for <>; Wed, 17 Aug 2016 16:07:33 -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 515FF12B074 for <>; Wed, 17 Aug 2016 16:07:33 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ba9rs-0006Cq-9Z for; Wed, 17 Aug 2016 23:03:28 +0000
Resent-Date: Wed, 17 Aug 2016 23:03:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ba9rm-0006C5-Mw for; Wed, 17 Aug 2016 23:03:22 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA256:128) (Exim 4.80) (envelope-from <>) id 1ba9rl-00005q-Dc for; Wed, 17 Aug 2016 23:03:22 +0000
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u7HN1xAQ026629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 17 Aug 2016 16:02:00 -0700 (PDT)
To: Adrien de Croy <>, Willy Tarreau <>
References: <embe2271fe-c61d-4c7c-84fd-bac7efa56593@bodybag>
Cc: Mark Nottingham <>, "" <>, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
From: Joe Touch <>
Message-ID: <>
Date: Wed, 17 Aug 2016 16:01:57 -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: <embe2271fe-c61d-4c7c-84fd-bac7efa56593@bodybag>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.4
X-W3C-Hub-Spam-Report: AWL=0.000, BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ba9rl-00005q-Dc 1fdffbf233e7ca6645d36ba6e53d156b
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32293
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

This is a bit of a side track, but...

On 8/17/2016 3:51 PM, Adrien de Croy wrote:
> ------ Original Message ------
> From: "Joe Touch" <>
>> They want something different for a variety of reasons - the same kind
>> of airtight logic by which TBL developed HTTP instead of using FTP (he
>> said that you'd only typically need one file from a location, so why
>> open 2 connections? now we're stuck trying to mux control and data
>> rather than having a proper solution that already existed at the time -
>> it took nearly a decade for HTTP servers to catch up to the performance
>> of FTP).
> Whilst I've been finding this discussion very informative and
> interesting, I have to raise an objection on this point.
> FTP was never going to be suitable for the web, and a very simple RTT
> analysis shows that.
> Apart from initial 3 way TCP handshake and close, which is the same
> for both, with http you have a request and a response, whereas FTP
> requires you to wait for the server welcome, log in, negotiate another
> port, set up a data connection in addition to retrieving the file

That's only the first time you go somewhere new. You don't need to close
both ports so quickly; the control channel can stay open and you thus
avoid HOL blocking between data and control (and thus the need to
chunk-and-mux within persistent HTTP), which increases other delays for

Neither protocol matches exactly what is really needed for a true
transaction-oriented protocol.

> ...
> Then try adding all the firewall issues due to transmitting data
> connection endpoint information over the control connection and it's
> no surprise FTP is not favoured for downloads.

FTP had a passive mode even back then that avoids this issue. It also
had suspend/resume, compression, and format conversion.