Howdy, there is a bunch of literature on this topic.. mostly what it boils down to is that fewer connections perform better unless you're experiencing very significant packet loss. (This threshold varies, but it tends to be on the order of > 2%). So the question becomes how often is that the case.. I find it kind of sad that a lot of the literature focuses on the impact of loss (which has always been known in the http community) without trying to answer the question of what loss rates are incurred in the wild.
unfortunately that kind of loss rate data is fairly closely held by ISPs and not something a client can effectively measure (especially a browser which does a lot more receiving than sending.. servers know a little better, which is where most of the data comes from, but even they have to use retransmission as a standin for loss). But I've collected a significant number of anecdotes and measurements that align with our peers at other places in the network - so I feel ok with the current strategy based on that. Using a very broad brush I'll say that I expect about 90% of connections are better off with a small set than h1-style-many-conns. Its also better from a traffic management (think bufferbloat responsiveness) and likely anti-traffic-analysis point of view. As importantly when multiplexing within a connection h2 style you can manage priority in a way that independent connections cannot effectively do. IETF QUIC ought to eliminate the remaining cases, but I think we're in the best place given our choices. (this ignores cases where parallel connections create a strictly local maximization by harming something else.. that was never an intention of h1 parallelism but was rather a necessary cost to deal with high latency environments) -P On Mon, Jul 17, 2017 at 6:32 PM, Anne van Kesteren <[email protected]> wrote: > From what I know we're quite good at reducing the number of > connections. I was wondering if we also know that to always be > beneficial. It seems that at least until QUIC, and maybe even then, > there's a tradeoff to be made. > > Thanks, > > > -- > https://annevankesteren.nl/ > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
