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