Talk about concurrency in H3 vs. H2 #3114
Conversation
MikeBishop
added
editorial
draft-ietf-quic-http.md
Outdated
| QUIC manages stream concurrency on behalf of HTTP/3. QUIC considers a stream | ||
| closed when all sent data and all acknowledgements for received data have been | ||
| acknowledged by the peer. HTTP/2 considers a stream closed when the frame | ||
| containing the END_STREAM bit has been committed to the transport. As a result, | ||
| the stream for an equivalent exchange will remain "active" for at least one | ||
| additional round trip. Implementations of HTTP/3 might choose to permit a | ||
| larger number of concurrent streams than in HTTP/2 to achieve equivalent | ||
| concurrency, depending on the expected usage patterns. |
There was a problem hiding this comment.
This looks good but if you're gonna pop the bonnet to fix something, I think we probably want to talk about the concurrency of request and push streams separately.
The text here is more focused on describing the behaviour of request streams. So I would be more specific and say that a HTTP/3 server might choose to permit a larger number of concurrent client-initiated bidirectional streams.
Then I would discuss considerations for push concurrency, highlighting the additional controls in the shape of push ID but identifying that push stream concurrency is competing against other unidirectional stream types (core or extensions) for the server-initiated unidirectional stream space.
draft-ietf-quic-http.md
Outdated
| @@ -1814,6 +1814,15 @@ considerations about exhaustion of stream identifier space apply, though the | |||
| space is significantly larger such that it is likely that other limits in QUIC | |||
| are reached first, such as the limit on the connection flow control window. | |||
|
|
|||
| QUIC manages stream concurrency on behalf of HTTP/3. QUIC considers a stream | |||
There was a problem hiding this comment.
I feel this "on behalf of HTTP/3" a bit confusing, because my mental model is that it is generally a responsibility of the transport to manage streams, and that HTTP/2 was the exception.
Maybe something like "In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC."
| @@ -1814,6 +1814,15 @@ considerations about exhaustion of stream identifier space apply, though the | |||
| space is significantly larger such that it is likely that other limits in QUIC | |||
| are reached first, such as the limit on the connection flow control window. | |||
|
|
|||
| QUIC manages stream concurrency on behalf of HTTP/3. QUIC considers a stream | |||
| closed when all sent data and all acknowledgements for received data have been | |||
| acknowledged by the peer. HTTP/2 considers a stream closed when the frame | |||
There was a problem hiding this comment.
I think this sentence is incorrect.
I think it should be: "QUIC considers a stream closed when all data have been received and all the sent data have been acknowledged."
There was a problem hiding this comment.
Or a reset has been sent and acknowledged.
draft-ietf-quic-http.md
Outdated
| acknowledged by the peer. HTTP/2 considers a stream closed when the frame | ||
| containing the END_STREAM bit has been committed to the transport. As a result, | ||
| the stream for an equivalent exchange will remain "active" for at least one | ||
| additional round trip. Implementations of HTTP/3 might choose to permit a |
There was a problem hiding this comment.
How about "will typically remain "active" for one additional roundtrip"?
The lifetime of a stream would be indifferent from HTTP/2 in the pathological case where the request-side of the stream is closed after the response-side is being closed.
MikeBishop
force-pushed
the
http/concurrency_differs
branch
from
8645d19
to
254f772
Compare
Co-Authored-By: Lucas Pardue <lucaspardue.24.7@gmail.com>
MikeBishop
force-pushed
the
http/concurrency_differs
branch
from
254f772
to
ca1c494
Compare
| the stream for an equivalent exchange will typically remain "active" for one | ||
| additional round trip. HTTP/3 servers might choose to permit a larger number of | ||
| concurrent client-initiated bidirectional streams to achieve equivalent | ||
| concurrency than were permitted in HTTP/2, depending on the expected usage |
There was a problem hiding this comment.
"permit a larger number...than were permitted" makes sense, but there are so many words between them that it's kind of hard to parse.
| the stream for an equivalent exchange will typically remain "active" for one | ||
| additional round trip. HTTP/3 servers might choose to permit a larger number of | ||
| concurrent client-initiated bidirectional streams to achieve equivalent | ||
| concurrency than were permitted in HTTP/2, depending on the expected usage |
There was a problem hiding this comment.
| concurrency than were permitted in HTTP/2, depending on the expected usage | |
| concurrency to HTTP/2, depending on the expected usage |
There was a problem hiding this comment.
I think that this isn't quite right. It makes an unstated assumption, namely that the transport maintains a fixed "active stream count" that it uses to increment the maximum stream ID. The decision to increase the maximum stream identifier could be made at the same point in HTTP/3 as it is in HTTP/2 if the transport+HTTP stacks were to decide that.
I think that we can stop by saying that the state machine is different and that this might result in HTTP/3 streams being regarded as closed later than in HTTP/2. This could reduce the effective stream concurrency if the number of streams is used in a similar way to decide the maximum stream ID.
Fixes #2787.