W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Transfer-codings, mandatory content-coding support and intermediaries

From: Daniel Stenberg <daniel@haxx.se>
Date: Tue, 22 Apr 2014 13:26:59 +0200 (CEST)
To: "Roy T. Fielding" <fielding@gbiv.com>
cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <alpine.DEB.2.00.1404220935050.1948@tvnag.unkk.fr>
On Mon, 21 Apr 2014, Roy T. Fielding wrote:

> Likewise, restricting packet sizes to a small length in order to prevent 
> fools from HOL blocking their own multiplexed channels makes some sense, for 
> browser developers.  However, it actively harms applications of HTTP that 
> are not interested in multiplexing because they only want to transmit a 
> single large data stream. [E.g., for SSH, we have 
> "http://www.psc.edu/index.php/hpn-ssh".]

TL;DR: I don't think the SSH lesson tells us that small frame sizes are 
necessarily bad.

The longer version:

I've spent some time implementing SSH based protocols and I've analyzed SCP 
and SFTP performance (within the realms of the libssh2 project).

I think you misrepresent the problem hpn-ssh addresses slightly. It is about 
"SSH buffer sizes", and specifically about the ones used by OpenSSH. It is not 
a problem with SSH (the protocol) packet sizes.

SSH has a stream and flow control concept very similar to http2 so yes, 
clients that want maximum throughput for large contents may find themselves 
wanting to announce a (very) large window to the peer.

The big problem with packet sizes within the SSH family, I would say, is for 
sub protocols such as SFTP which suffers greatly from RTT and forces 
implementations to do crazy "pipelining" attempts to overcome that. But that's 
even more off-topic here!

-- 

  / daniel.haxx.se
Received on Tuesday, 22 April 2014 11:27:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC