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

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.

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)