Re: [quicwg/base-drafts] Talk about concurrency in H3 vs. H2 (#3114)

[Lucas Pardue <[e-mail]>]

LPardue commented on this pull request.



> +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.

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 type (core or extensions) for the server-initiated unidirectional stream space.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3114#pullrequestreview-303456374