HTTP/3 DATA_WITH_OFFSET frame

[Samuel Hurst <[e-mail]>]

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