- From: Samuel Hurst <samuelh@rd.bbc.co.uk>
- Date: Thu, 18 Feb 2021 15:09:54 +0000
- To: IETF QUIC WG <quic@ietf.org>, ietf-http-wg@w3.org
- Message-ID: <5c96284e-ea35-0454-3c03-225e9bb5efd9@rd.bbc.co.uk>
Hello to both the QUIC and HTTP working groups, ****** TL;DR: I've made a new extension frame (with I-D [1]) to support binary framing of multipart range requests in HTTP/3. ****** A long time ago we started an effort to adapt the QUIC wire protocol to be able to efficiently deliver HTTP resources to many receivers using multicast [2]. We have been using this in our experiments with delivery of segmented live media for some time now [3], using multipart range requests to fill gaps from packet loss. As part of these experiments, we discovered issues with maintaining synchronisation between senders and receivers using HTTP/3 DATA frames carried on an unreliable transport. In order to help mitigate this issue, I have come up with a new DATA_WITH_OFFSET extension frame [1] which is based on the H3 DATA frame but carries a HTTP representation offset in the header. Outside of the multicast work, I discovered that such a frame could be more generally useful in terms of supporting multipart range requests in HTTP/3. My current understanding is that a HTTP/3 endpoint that supports range requests will perform single range requests fine, but I would imagine that performing a multipart range request with HTTP/3 would require both endpoints to use the existing multipart/byteranges media type in the body response. This means that endpoints aren't able to take advantage of features such as binary framing and header compression that HTTP/3 and QPACK give. I've put together a short internet draft as a starting point. Section 3 describes the extension frame itself, and section 4 describes how it is used with multipart range responses. As part of this, I've modified the syntax of the Content-Range response header to make it an explicit list-based field as the current HTTP/3 spec doesn't allow you to use more HEADERS frames between DATA frames. This extra functionality is dependent on endpoints negotiating support with a HTTP/3 settings parameter. Any comments or feedback are welcomed. Best Regards, Sam [1]: https://datatracker.ietf.org/doc/draft-hurst-quic-http-data-offset-frame/ [2]: https://datatracker.ietf.org/doc/draft-pardue-quic-http-mcast/ [3]: https://www.bbc.co.uk/rd/projects/dynamic-adaptive-streaming-ip-multicast-dasm
Received on Thursday, 18 February 2021 15:12:04 UTC