Re: Unbound DATA frames in HTTP/3 proposal

I agree with Martin that this can be implemented without buffering, this
proposal is more about the overhead in terms of framing bytes and CPU costs
of accounting.

I disagree however with Amos and Kazuho about interleaving. If your origin
is sending DATA frames of length 4 GB, and the intermediary is forwarding
the h3 frames unmodified, then the intermediary has absolutely no way to
interleave METADATA or other extensions. That's already the case with
unextended h3. Interleaving is only a property of h3 if the sender chooses
to use it. If an intermediary cares about interleaving, it already needs to
fragment DATA frames from the upstream sender. That intermediary can
equally fragment UNBOUND_DATA, or even simpler it just doesn't implement
this extension.

David

On Thu, Oct 9, 2025 at 9:56 AM Martin Thomson <mt@lowentropy.net> wrote:

> On Thu, Oct 9, 2025, at 17:33, Watson Ladd wrote:
> > It depends on what the layers give to each other. If the expectation
> > on the HTTP/3 layer is that the application visible stream comes from
> > the QUIC layer as bunch of DATA frames that are each complete, vs.
> > dealing with each byte as it comes in from a partial one, than an
> > additional buffer is required. However I imagine that this is a) rare
> > and b) can be structured so the buffer is most of the time not used
> > (as most sensible implementations will throw the DATA frame on a
> > STREAM frame into a packet as soon as they can, so the receiver
> > doesn't buffer at all if they notice this has happened).
>
> No buffering is needed.  Each of these layers is length-prefixed.  So a
> reader will have to track remaining lengths at each layer, but they do not
> need to buffer any bytes specially.  This is something I've implemented for
> chunked oblivious HTTP and it works cleanly.
>
> You say a lack of alignment is potentially rare.  My experience is that
> while it is conceivable that framing is aligned to write sizes, that can
> get out of step.  So no guarantees.  But also no problem.
>