Re: [External⚠] Re: Unbound DATA frames in HTTP/3 proposal

2025年10月9日(木) 18:07 Demi Marie Obenour <demiobenour@gmail.com>:

> On 10/8/25 22:57, Kazuho Oku wrote:
> > 2025年10月9日(木) 11:42 Amos Jeffries <squid3@treenet.co.nz>:
> >
> >> On 08/10/2025 06:14, David Schinazi wrote:
> >>>  I could see not wanting
> >>> this feature in the base protocol because the base protocol was
> intended
> >>> to be as general purpose as possible, and that change would
> >>> have required all receivers to implement it, but this is an extension
> >>> that not every implementation needs to support.
> >>
> >>
> >> BUT this is a stream level mechanism. That means even one implementation
> >> along one chain of HTTP agents not supporting it "Breaks the Internet"
> >> for either the client or the application trying to use it.
> >>
> >> Having both client and application use unbounded **optionally** means
> >> they have already mandatory support for not using it. And can cope
> >> without it just fine already - ergo no need for the extension to exist.
> >>
> >>
> >> Consider a "blind" intermediary relaying at full bandwidth capacity a
> >> single stream. Along comes a second stream with a high priority
> >> transaction.
> >>
> >>   The DATA frames allow this intermediary to immediately drop
> >> PRIORITY_UPDATE on the stream #1 sender while that urgent transaction
> >> completes. Then restore to full service.
> >>   The UNBOUNDED_DATA frames would continue to flow into UDP/QUIC buffer
> >> and force their handling at topmost priority. Leaving the actual high
> >> priority traffic in the region of potentially dropped packets.
> >>
> >> In todays network intermediaries have the situation where online streams
> >> video traffic compete with admin managing virtual servers. Priority
> >> management over streams has become a critical ability. So yeah there is
> >> some "pushback" on anything being unbounded.
> >>
> >
> > Right. Even though PRIORITY_UPDATE would not be affected by UNBOUND_DATA
> > because it is actually sent on the control stream rather than on a
> request
> > stream, the concern with UNBOUND_DATA is that it is incompatible with one
> > of the key design principles of H2 and H3; i.e., send frames so that data
> > and metadata can be interleaved.
> >
> > Standard features like trailers and PUSH_PROMISE depend on the
> > ubiquitousness of length-delimited frames. I do not think there is an
> IETF
> > extension that sends frames on the request stream, but we have METADATA
> > registered.
> >
> > For extended CONNECT specifically, one might argue that the features
> > provided by these frames (as well as the capability to extend) might not
> be
> > important. But regardless, UNBOUND_DATA is essentially a proposal that
> > turns one key design aspect of HTTP/3 into something not always
> available.
>
> It doesn't always _need_ to be available.
>

That is not the case, because it is about ossification, as Victor correctly
summarized.

In the past, we have seen extension points of HTTP becoming inexercisable
due to buggy implementations. People often implement their stacks based on
what they observe and care about, without paying enough attention to how
the protocol might be used in the future.

The concern specifically for UNBOUND_DATA is the fear of HTTP/3 going down
that pitfall again, once popular implementations start using the frame.


> If you need a feature that UNBOUND_DATA disables, just don't use it.  It's
> just an optimization, but from what the OP wrote, it seems to be an
> effective one.  I would like to see proper benchmarks, though.
>
> Whether or not to use UNBOUND_DATA is a hop-by-hop decision, so proxies
> can choose to convert it into normal DATA frames if they wish.
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)



-- 
Kazuho Oku