- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 22 Apr 2014 08:17:00 -0700
- To: Daniel Stenberg <daniel@haxx.se>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Apr 22, 2014, at 4:26 AM, Daniel Stenberg wrote: > 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. Er, no, that wasn't the point -- SSH the protocol was designed for flexibility of application. SSH the implementation made some implementation decisions that assumed certain application characteristics, leading to poor performance outside those characteristics. HPN-SSH is an example of how applications try to push the boundaries of protocols. If SSH the protocol had required limitations similar to those of the implementation, everyone would be stuck with those limitations until the next major version of SSH. So, making limitations on what the protocol can do just for the sake of one use case (browsers talking to a walled garden over a multiplexed TLS session) is a bad idea, unless the protocol you happen to be working on is TLS+ (not HTTP/2). ....Roy
Received on Tuesday, 22 April 2014 15:17:26 UTC