Re: HTTP/3 DATA_WITH_OFFSET frame

[Dmitri Tikhonov <[e-mail]>]

Hello Sam,

An interesting draft!

On Thu, Feb 18, 2021 at 03:09:54PM +0000, Samuel Hurst wrote:
> 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.

These are two different use cases: multicast over unreliable transport
and multipart range requests.  Have you implemented the latter?  As an
implementer, I would be curious to see how a receiver can take advantage
of such framing.  I imagine that several read cursors would have to be
maintained in case of missing STREAM frames and adjusted as more data
comes in.  Then there is the matter of potentially overlapping STREAM
frames due to retransmit.  Not that any of that can't be done, of
course, but it would be an undertaking...

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

>From Section 3:

 " The purpose of the "DATA_WITH_OFFSET" frame is only to assist in
 " locating a particular slice of data carried as part of an HTTP
 " message payload, and not as a means to send data out of order.
 " Senders MUST send data in order, i.e. with increasing values in the
 " Offset field.

Why proscribe such use?  This may be an avenue for innovation or
optimization.

  - Dmitri.