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

[grmocg <[e-mail]>]

@LPardue 
Yup. 

I think/hope that we can come up with a cheap and standard way of representing the end of the initial headers to enable these usecases.
And example was to have a new frame type (at the 'http' layer) which allows us to say the offset of the metadata for a few RTTs until we know a packet containing it has been received. 

 I'm not worried about in-line metadata, since that is arguably 'payload' in a world where we can do stream-groups and multiple response streams (which would be arguably more flexible than a single response with multiple metadata segments for header-size-ish metadata).

@MikeBishop 

In my estimation, this isn't just a 'server push' issue, as one would really want to do the same thing on ingestion (uploading), not just playback (downloading). It becomes an HTTP mapping issue (whether for quicv1 or quicv2) since it impacts not just push, but also GET/PUT, and should fit into whatever prioritization stuff is happening as well. 

Consider that one of the bigger issues with video playback (and rebuffers), especially on browsers (but also on android/ios apps), is "application" self-contention. A page/application/domain makes requests for HTTP objects but, due to the lack of coordination (today) between the video uploading/downloading stuff (most often not HTTP today for low-latency stuff) and the non-video HTTP stuff, the bandwidth estimate becomes incorrect, the buffer drains prematurely, and you have the video transfer (which expects at least a certain bitrate over short time periods), much to user chagrin.

Anyway that is part of the thought process!

-- 
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-408531743