Re: HTTP/3 DATA_WITH_OFFSET frame

[Dmitri Tikhonov <[e-mail]>]

On Thu, Feb 18, 2021 at 04:15:27PM +0000, Samuel Hurst wrote:
> On 18/02/2021 15:48, Dmitri Tikhonov wrote:
> 
> 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

By retransmission, do you mean dropping overlaps that were already passed
up to the HTTP layer?

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

OK, so the HTTP layer would then have to figure out where HTTP/3 frame
headers are.  To do so, it still needs to find the frames in order based
on stream offsets and HTTP/3 frame lengths.

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

Yes, I get it.

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

I don't know of a reason, either, but to me that does not mean that
this use must be forbidden.

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

One theoretical use-case that comes to mind is that of a log file that
is being appended to.  The receiver wants to display the latest data
while downloading the whole file.  A new write to the growing file is
sent with higher priority.

  - Dmitri.