-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BCP56bis: Consider expanding scope of H2/H3 stream multiplexing discussion #1290
Comments
Can you suggest some text, or at least some bullet points to seed discussion? |
The server push section is a pretty good model for the type of text I had in mind. Some points off the top of my head and unfiltered for if they belong in this spec or not:
|
We already caution against requiring a specific version of the protocol because it's a hop-by-hop protocol, and already caution against making assumptions about the relationship between a message and the connection it's on. I'm not sure how much further we should go into the detail here. @martinthomson thoughts? |
I agree Mark. But OTOH the killer feature of H2 and H3 (in comparison to prior versions) is multiplexing. It seems strange to have such little text afforded to it. |
Good point. Please write some :) |
HTTP/1.1 multiplexes as well, just at a different layer. Expanding the text regarding assumptions about request-connection interactions to mention concurrency is probably a good idea. It doesn't need to be much text. A new subsection of Section 4 might be good "Making Multiple Requests". Move the text from Section 4.10 on connection-independence to that section. Then add a probably just two things:
|
@LPardue @martinthomson PTAL. |
I might have a suggestion for some awkward phrasing, but this is on point. |
The new text looks good, thanks. I made a comment about the request processing. |
The document makes 2 brief mentions of HTTP/2 multiplexing.
I think there is tacit knowledge about how stream multiplexing works in practice. We have experience from years of HTTP/2 deployments and interop. HTTP/3 changes things with it's removal of guaranteed ordering across streams. We also can't ignore the role that prioritization plays with multiplexing.
People wanting to use HTTP might not be with the above aspects of stream multiplexing. Through the course of discussion in #1274 it appeared to me that the designers of LL-HLS have a model for stream multiplexing usage to deliver video that may not be easily achievable with the protocol mechanics of H2 or H3, or the practical constraints that HTTP server operators apply to mitigate DoS etc. There could be emergent problems that damage their use case goals. I doubt that this is an isolated example.
So this ticket asks the question, is there benefit to the community to capture something about multiplexing in BCP56bis? Personally I think so.
The text was updated successfully, but these errors were encountered: