Re: [tcpm] TCP Tuning for HTTP - update

[Joe Touch <[e-mail]>]

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" <[e-mail]>
>
>> 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
HTTP.

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.

Joe