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

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.


>
>
> HTH
> Amos
>
>
>

-- 
Kazuho Oku