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

[grmocg <[e-mail]>]

In the 'partially reliable http' use-case, e.g. an interactive (VC-like) 'video protocol', **the co-mingling of the payload and metadata (header) address space on the QUIC stream prevent interpretation of payload data until all metadata has been received in cases which attempt to use the address space to assert framing** (e.g. I know that the data at any location where n % k == 0 is the start of a record). 

This method of framing is unavailable (until all headers have been received) with QUIC as it is today since the size of the metadata the client will receive is unknown (it might be encoded by a different compressor, e.g. via a reverse proxy) to either the client or sender, and since the address space of metadata and payload is co-mingled.

In other words, in cases where the client knows the relationship of the requests/responses (for instance with a server push response to a particular request) and so doesn't need the headers immediately, it is advantageous to have an address space for payload that starts with a known, constant value.

Consider the following:

1. A client requests video of a particular codec, size, bitrate, etc.
2. The server replies by sending a number of server push streams in response to that request., likely within a 'stream group' should such a thing come into existence in QUICv2.
3. For streams which arrive after the first server push'd stream, the type of the data is , and can be interpreted by the application immediately, even when received out-of-order and/or non-contiguously.

It would be expected in such a use-case to have a large number of server push'd 'responses' referring to byte-ranges of files on a server/proxy/cache. The client would likely establish a few requests to which the server would never directly respond (it would instead server push responses to those 'requests'), e.g. the client would request playback of a 5MB/s 264 bitstream, and the server would push byteranges of a file containing (at least) the elementary stream.

Note that the headers on the pushed streams will be useful upon receipt for applications running on a framework (e.g. a browser) which may wish to cache/store and which (likely for security reasons) doesn't offer the application the ability to assert the data should be stored with URL X/ETAG Y. 



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