Coalescing vs head of line blocking

[Anne van Kesteren]

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

[Patrick McManus]

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

> _______________________________________________
> dev-tech-network mailing list
> dev-tech...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-network
>
>