Unfortunately, most flows with http/1 are short (and bursty) flows, so it
is incorrect to say that they have reached steady-state w.r.t. congestion
control. Many resource fetches complete in between one and three rtts, then
much of time the connection(s) sit idle for extended periods of time
(seconds to minutes).
I'm hoping Will will chime in here with data soon, but the distribution on
single connection cwnds as measured on traffic in the wild shows us that
using multiple connections puts more packets on the wire as a result of
init-cwnd (and thus not subject to congestion control, ouch) than a single
stable-state, heavily used and reused connection such as Spdy or HTTP/2
would allow.
This is happening now, the data is there now.
Multiple connections is worse, and it is the common case, and it is getting
to be even more of a problem month by month.
And I'm not even talking about how multiple http connections deal with loss
vs the one...
I agree that solving the problem for http/2 alone won't fix it for
everything. On the other hand, we also need to act swiftly to solve
problems on timescales that matter to users, and http is a fine venue for
that. The fact that http/2 could do this doesn't stop us from coming up
with an opaque blob that *any* latency sensitive application protocol
could use to communicate with the transport layer.
Really, all this is is an API which allows the transport layer to
communicate with a future instantiation of itself...
-=R
On Apr 16, 2013 8:00 AM, "Simpson, Robby (GE Energy Management)" <
robby.simpson@ge.com> wrote:
> It appears to me that the chief concern is in regards to HTTP/2's use of a
> single flow vs. HTTP/1's use of multiple flows. I fail to see how
> changing CWND is going to make a difference (except for a beginning,
> potentially nasty, burst) since, if the flows are sharing the same
> end-to-end paths, they will still be competing and will steady-state to
> "equal" CWND's.
>
>
> Further, this is not specific to HTTP/2. There are plenty of other
> applications out there using TCP that have suffered from HTTP/1's use of
> multiple simultaneous flows. I fail to see how HTTP/2 is in a better
> situation to correct that issue than any other application or, more
> importantly, than the appropriate layer (4) or the offender (HTTP/1).
>
> Am I missing something, or is the concern really that some folks are
> looking for a way to throttle or compete with HTTP/1 flows?
>
> - Robby
>
>