Re: [quicwg/base-drafts] Possible HoL blocking due to co-mingling payload and metadata (header) address space. (#1606)

[grmocg <[e-mail]>]

@martinthomson 

HTTP's headers are important for caching, but may not be important for the initial streaming. This is still interesting for broadcasts-to-millions, since any hiccup on ingestion of the stream causes a hiccup for any follower/viewer of the stream.

I'm assuming we'd likely also be using a stream-group (i.e. a grouping of a bunch of HTTP requests/responses together). Within that stream-group (which is really better discussed in that issue), we can know that we're sending multiple responses for a particular request (for the playback side). Depending on the eventual interaction with stream-group and headers, a great many assumptions may be possible for the *requesting client*.

Any other client would not be able (unless there is some non-HTTP logic on the server) to make such similar assumptions, and would need more data in headers.


There are certainly a few ways to play with this:
1) assume that the headers are below offset X. Start payload at offset X.
2) Transmit a new frame-type which specifies the offset of the headers data until the receiver ack's t has received it.
3) Use different streams for each (this interacts in fun ways with flow-control/max streams). If you assume one of the bits was used to indicate metadata vs payload , that could be sufficient.
... and more.

-- 
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/issues/1606#issuecomment-408248199