Re: [tcpm] TCP Tuning for HTTP - update

"Adrien de Croy" <> Wed, 17 August 2016 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9255A12B02A for <>; Wed, 17 Aug 2016 16:22:23 -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 p3pnpe7S4V6a for <>; Wed, 17 Aug 2016 16:22:22 -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 4BBCC12B024 for <>; Wed, 17 Aug 2016 16:22:22 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1baA5o-0006k6-M9 for; Wed, 17 Aug 2016 23:17:52 +0000
Resent-Date: Wed, 17 Aug 2016 23:17:52 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1baA5i-0006jI-0G for; Wed, 17 Aug 2016 23:17:46 +0000
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <>) id 1baA5f-00086S-Sr for; Wed, 17 Aug 2016 23:17:45 +0000
Received: From [] (unverified []) by SMTP Server [] (WinGate SMTP Receiver v9.0.0 (Build 5855)) with SMTP id <>; Thu, 18 Aug 2016 11:17:13 +1200
From: Adrien de Croy <>
To: Joe Touch <>, Willy Tarreau <>
Cc: Mark Nottingham <>, "" <>, HTTP Working Group <>, Patrick McManus <>, Daniel Stenberg <>
Date: Wed, 17 Aug 2016 23:17:13 +0000
Message-Id: <ema6771211-5d5d-4106-b3f0-87616b83f9f6@bodybag>
In-Reply-To: <>
Reply-To: Adrien de Croy <>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.9
X-W3C-Hub-Spam-Report: AWL=-0.495, BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1baA5f-00086S-Sr 692754b005ea47222203ed366b190f4a
Subject: Re: [tcpm] TCP Tuning for HTTP - update
Archived-At: <>
X-Mailing-List: <> archive/latest/32294
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

------ Original Message ------
From: "Joe Touch" <>
To: "Adrien de Croy" <>; "Willy Tarreau" <>
Cc: "Mark Nottingham" <>; "" <>; 
"HTTP Working Group" <>; "Patrick McManus" 
<>; "Daniel Stenberg" <>
Sent: 18/08/2016 11:01:57 AM
Subject: Re: [tcpm] TCP Tuning for HTTP - update

>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 
>>>  of airtight logic by which TBL developed HTTP instead of using FTP 
>>>  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 
>>>  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 
>>  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 
>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
You still need to send another PORT/PASV and wait for the response 
before making another TCP connection for data, since you can't re-use 
this one.

So subsequent requests to the same server will be quicker, still at 
least 3 round-trips more than a subsequent http request on a persistent 

>Neither protocol matches exactly what is really needed for a true
>transaction-oriented protocol.
We are probably in agreement here.

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

Those all take more round trips to negotiate.  As for format 
conversion..... bad idea, never should have been the server's job.

We've seen a lot of server-side firewall problems with PASV as well.