Re: HTTP/3 DATA_WITH_OFFSET frame

On 18/02/2021 15:48, Dmitri Tikhonov wrote:
> Hello Sam,
> 
> An interesting draft!

Thank you!

> 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 have not implemented the latter yet, mostly because of a lack of time.
This has primarily come out of our unreliable transport work around
multicast, but it just so happens that with my familiarity with using
multipart range request I figured that it could benefit there too.

In terms of actually implementing the multirange support, my personal
approach would be to have the stream manage the retransmission and then
pass this to a HTTP layer within whatever library I'm using (as that was
my previous experience of playing with libraries like ngtcp2/nghttp3).
The DATA_WITH_OFFSET offset header would then just replace whatever
internal data counter I would have been using to synchronise the
position in the HTTP representation with the position in the stream.
This would then naturally skip ahead between ranges.

With the inclusion of the offset field, a potential optimisation could
be to not block the delivery of subsequent ranges while waiting for a
retransmission on a previous range? Which I think might tie into your
next point...

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

I couldn't immediately think of any particular reason why an
implementation would want to send data out-of-order, and the existing H3
DATA frame must send in-order as it is tied to the stream frame to
derive the offset within the given HTTP representation being
transferred. However, if there are realistic use cases in this regard
then I'm more than happy to remove this proscription in a future version
of the draft.

-Sam