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

2025年10月8日(水) 2:14 David Schinazi <dschinazi.ietf@gmail.com>:

> The intent of the capsule protocol was to carry information mostly
> untouched through intermediaries. For that reason, we landed on a design
> that just uses the data stream - a concept that's defined for all versions
> of HTTP [1] - and works if intermediaries just shovel bytes like they do
> for unextended CONNECT.
>

I agree that it was the correct choice to design the capsule protocol on
top of HTTP.

At the same time, that does not preclude the HTTP layer from providing ways
to carry capsules in optimized ways. Depending on how you view it, we have
made such an optimization already: H3 datagrams is a H3-specific
optimization for carrying datagram capsules.


>
> I don't think we should move capsules to a separate frame or a separate
> stream, because that significantly complicates things.
>

When comparing the complexity added by UNBOUND_DATA, I'm not entirely
convinced. It likely depends on the specifics of each implementation.

In the following paragraphs, I will respond to each point and then explain
how I perceive the complexity of the H3 CAPSULE frame approach.

Now you can encode them in multiple ways,
>

This issue exists with UNBOUND_DATA as well. Omitting a layer is itself a
form of alternative encoding or decoding,  and in practice, this makes the
plumbing within the software stack more complicated.

and receivers have to deal with ordering if you receive them on both (or
> erroring out if that's not allowed)
>

This is true, although handling this by erroring out is straightforward.


> , and hit all the pitfalls of asynchronous signalling.
>

That's true for the separate streams approach, but not when using H3
CAPSULE frames.

So, how complex would it be to implement the H3 CAPSULE frame, compared to
UNBOUND_DATA?

On the sending side, I would argue that implementing the CAPSULE frame
might actually be simpler, as the logic for sending a capsule over a DATA
frame versus a CAPSULE frame can be almost identical.

When sending a capsule using a DATA frame, the sender prepends the capsule
header (i.e., the capsule type and the length), then the DATA frame header
(i.e., the DATA frame type and the length).

When sending a capsule using a CAPSULE frame, the sender prepends only the
capsule type (omitting the length), then the CAPSULE frame header (i.e.,
the frame type and the length).

As can be seen, the only differences are: (1) omitting the capsule length
field, and (2) useing a different H3 frame type. It may well be easier to
make these two adjustments than to modify the plumbing to skip the H3
framing layer entirely.

On the receiving side, the situation is similar. Instead of skipping the H3
framing layer, the H3 stack will expose the frame length to the upper
layer, allowing the capsule decoder to read it directly. If that length is
unavailable, the decoder would instead determine the capsule length by
parsing the payload received from the H3 stack. a way to communicate the
length of a frame (as well as the length is available to the upper layer),
and the capsule decoder would read the capsule length from the H3 stack.

To conclude, in my view, the two approaches (UNBOUND_DATA vs. H3 CAPSULE
frame) introduce complexity in different parts of the stack.. I do not
think we can claim that one is universally better, it likely depends on the
architecture of each implementation.stack.

And the benefit of the H3 CAPSULE frame approach is that it does not
interfere with the core design of H3, as noted in the other response [1].

[1] https://lists.w3.org/Archives/Public/ietf-http-wg/2025OctDec/0030.html


> The goal of UNBOUND_DATA was to be the simplest possible solution to the
> issue of repeatedly making chunks when the semantic you want is "keep
> going until I'm done". And if we combine this with a similar solution at
> the capsule layer [2] then you can run connect-tcp directly on raw QUIC
> STREAM frames.
>
> Thanks Mike for finding the 2018 discussion on this topic, I had vague
> memories of those conversations but had forgotten most of the details. I
> still don't quite understand the strong opposition here - I absolutely
> agree that there exist many cases where using UNBOUND_DATA is not suitable,
> but in those cases just don't use it. 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.
>

> David
>
> [1] https://www.rfc-editor.org/rfc/rfc9297#section-3.1
> [2]
> https://github.com/DavidSchinazi/draft-schinazi-masque-9297bis/issues/4
>
> On Tue, Oct 7, 2025 at 6:36 AM Ben Schwartz <bemasc@meta.com> wrote:
>
>> UNBOUNDED_DATA achieves reduced framing overhead at the cost of a
>> semantic constraint: it is no longer possible to send other frame types on
>> this request.  This means that UNBOUNDED_DATA is not purely an
>> optimization; it "leaks" up through the HTTP abstract interface.  As a
>> result, it cannot be used transparently by an HTTP engine on arbitrary
>> requests, because the HTTP engine doesn't know if the application may
>> require other frame types later.
>>
>> Some of the comments from 2018 hint at an alternative approach that is
>> closer to transparent.  For example, imagine a frame like:
>>
>> DELEGATE_DATA {
>>   Type (i)
>>   Length (i)
>>   Stream ID (i)
>> }
>>
>> This means "all future DATA frame contents on this stream are delegated
>> to the indicated, unframed, unidirectional stream".  The original request
>> stream can continue to carry frame types other than DATA.
>>
>> The ordering of the other frame types relative to the data stream is
>> lost, but this is acceptable.  There are currently two other frame types in
>> use on request streams: HEADERS and PRIORITY_UPDATE.  HEADERS are defined
>> to occur only at the beginning or end of the stream, so their relative
>> position is unambiguous.  PRIORITY_UPDATE is not sensitive to the ordering
>> relative to the data stream.
>>
>> --Ben
>>
>> ------------------------------
>> *From:* Kazuho Oku <kazuhooku@gmail.com>
>> *Sent:* Tuesday, October 7, 2025 2:54 AM
>> *To:* Yaroslav Rosomakho <yrosomakho@zscaler.com>
>> *Cc:* Mike Bishop <mbishop@evequefou.be>; ietf-http-wg@w3.org <
>> ietf-http-wg@w3.org>; David Schinazi <dschinazi.ietf@gmail.com>
>> *Subject:* Re: [External⚠️] Re: Unbound DATA frames in HTTP/3 proposal
>>
>> 2025年10月7日(火) 14: 43 Yaroslav Rosomakho <yrosomakho@ zscaler. com>: I
>> think there's an important distinction here between an optional capability
>> that endpoints can negotiate for potential performance improvements and
>> what’s defined as
>>
>>
>> 2025年10月7日(火) 14:43 Yaroslav Rosomakho <yrosomakho@zscaler.com>:
>>
>> I think there's an important distinction here between an optional
>> capability that endpoints can negotiate for potential performance
>> improvements and what’s defined as part of the base protocol. The earlier
>> "zero-length DATA means unbounded" proposal would have changed the core
>> framing semantics for all HTTP/3 traffic; in contrast, UNBOUND_DATA is a
>> negotiated extension that endpoints can explicitly opt into.
>>
>> While a dedicated CAPSULE frame type could indeed simplify capsule-based
>> protocols, the motivation for UNBOUND_DATA goes beyond Capsules. The
>> immediate driver for me is the standard CONNECT method where the data is
>> already opaque, and the additional HTTP/3 DATA framing layer introduces
>> unnecessary per-frame overhead and can, in some implementations, trigger an
>> extra memory copy.
>>
>>
>> I see, thank you for the clarification.
>>
>> I'm not sure if we want to spend time optimizing traditional CONNECT when
>> we are developing an improved version: draft-ietf-httpbis-connect-tcp.
>>
>> And FWIW, draft-ietf-httpbis-connect-tcp does depend on Capsules. IIRC,
>> we discussed if the dependency should be optional due to performance
>> concerns, and agreed that it is acceptable.
>>
>> To paraphrase, there has been a consensus that having a new layer of TLV
>> encoding is fine. So the question is, now that there is a proposal to
>> eliminate one layer of TLV encoding, do we need to redo the discussion?
>>
>> Maybe that is a long way to state that it might be more productive to
>> spend time optimizing how Capsules are conveyed.
>>
>>
>> The goal here is not to change generic HTTP semantics, but to provide an
>> optional optimisation for cases where framing boundaries have no semantic
>> value. It can also be used unidirectionally: an endpoint can advertise
>> support for receiving unbound data without ever sending it itself.
>>
>>
>> Yeah I get the argument, but outside of new tunneling mechanisms, I'm not
>> sure how much new information we have to reconsider.
>>
>>
>> Best Regards,
>> Yaroslav
>>
>> On Tue, Oct 7, 2025 at 2:00 AM Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>>
>>
>> 2025年10月5日(日) 12:48 Mike Bishop <mbishop@evequefou.be>:
>>
>> It's been a while and I didn't recall details, so I did a bit of
>> spelunking for the history. There was a proposal
>> <https://github.com/quicwg/base-drafts/pull/2098> to allow DATA frames
>> with length==0 to behave this way, extending to the end of the data stream,
>> for all the reasons you cite.  It was merged, but then Martin observed that
>> all the discussion of it had been on GitHub, rather than the list, so
>> deciding that there had been consensus to merge was improper. We did
>> discuss it on the list
>> <https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/quic/3v2fwQJeWO8m7wYazBPxwRDWl88/__;!!Bt8RZUm9aw!6K3UbM5hk54HvWsHdiCCqKVJUTgtx2g0qLmAARnOERmZEwws6AthNcGWdyCLQgAGz2cAddFBIWJi-g$>,
>> and subsequently reverted it.
>>
>> This isn't an argument for or against your extension, but do page in the
>> history before re-attempting something we decided against previously.
>>
>>
>> IMO, the arguments against stands today too, for generic HTTP.
>>
>> At the same time, I share the pain of Yaroslav and David. Because
>> Capsules is a TLV format nested on top of HTTP, when using Capsules, we
>> have three layers of TLV now, i.e., QUIC STREAM frames, HTTP/3 DATA frames,
>> and Capsules.
>>
>> The complexity does not necessarily come from that they are layered, but
>> from the fact that the TLV structures do not share the same boundary. An
>> HTTP/3 DATA frame might extend beyond a QUIC STREAM frames and end in the
>> middle of the next STREAM frame. Similarly, a Capsule might extend beyond a
>> HTTP/3 DATA frame and end in the middle of the next DATA frame.
>>
>> This disagreement of boundary leads to buffering in each layer,
>> speculative or incremental decoding, that are either heavyweight and/or
>> complex.
>>
>> Considering these aspects, I wonder if the middle ground would be to
>> specify a HTTP/3 CAPSULE frame that carries one capsule.
>>
>> It can look like below.
>>
>> CAPSULE Frame {
>>   Type (i) = 0xTBD, // this is HTTP/3 frame type
>>   Capsule Type (i), // the type of the capsule
>>   Length (i),
>>   Data (..),
>> }
>>
>> Admittedly there will be one byte overhead (or one quicint overhead)
>> compared to the original proposal, but the benefit is that the design is
>> consistent with generic HTTP/3 and therefore would not be a disruptive
>> change.
>>
>> WDYT?
>>
>>
>> ------------------------------
>> *From:* Yaroslav Rosomakho <yrosomakho@zscaler.com>
>> *Sent:* Friday, October 3, 2025 4:42 PM
>> *To:* ietf-http-wg@w3.org <ietf-http-wg@w3.org>
>> *Cc:* David Schinazi <dschinazi.ietf@gmail.com>
>> *Subject:* Unbound DATA frames in HTTP/3 proposal
>>
>> Dear HTTP Working Group,
>>
>> While HTTP/3 streams are very efficient for long-term connections such as
>> CONNECT, WebSockets and WebTransport, the requirement to encapsulate
>> everything into finite-length DATA frames reduces potential performance and
>> flexibility. Best case scenario it introduces few extra unnecessary bytes
>> on the wire, worst case scenario it can cause an extra memory copy.
>>
>> David and I would like to propose an optional extension, UNBOUND_DATA
>> frame. This frame indicates that the remainder of the stream is data. This
>> reduces framing overhead and simplifies transmission of long-lived or
>> indeterminate-length payloads.
>>
>> Feedback and suggestions are very welcome.
>>
>> Best Regards,
>> Yaroslav
>>
>> ---------- Forwarded message ---------
>> A new version of Internet-Draft
>> draft-rosomakho-httpbis-h3-unbound-data-00.txt
>> has been successfully submitted by Yaroslav Rosomakho and posted to the
>> IETF repository.
>>
>> Name:     draft-rosomakho-httpbis-h3-unbound-data
>> Revision: 00
>> Title:    Unbound DATA Frames in HTTP/3
>> Date:     2025-10-03
>> Group:    Individual Submission
>> Pages:    8
>> URL:
>> https://www.ietf.org/archive/id/draft-rosomakho-httpbis-h3-unbound-data-00.txt
>> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-rosomakho-httpbis-h3-unbound-data-00.txt__;!!Bt8RZUm9aw!6K3UbM5hk54HvWsHdiCCqKVJUTgtx2g0qLmAARnOERmZEwws6AthNcGWdyCLQgAGz2cAddHZJIE5og$>
>> Status:
>> https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-h3-unbound-data/
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-h3-unbound-data/__;!!Bt8RZUm9aw!6K3UbM5hk54HvWsHdiCCqKVJUTgtx2g0qLmAARnOERmZEwws6AthNcGWdyCLQgAGz2cAddFNhSZBwQ$>
>> HTML:
>> https://www.ietf.org/archive/id/draft-rosomakho-httpbis-h3-unbound-data-00.html
>> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-rosomakho-httpbis-h3-unbound-data-00.html__;!!Bt8RZUm9aw!6K3UbM5hk54HvWsHdiCCqKVJUTgtx2g0qLmAARnOERmZEwws6AthNcGWdyCLQgAGz2cAddETma0iFQ$>
>> HTMLized:
>> https://datatracker.ietf.org/doc/html/draft-rosomakho-httpbis-h3-unbound-data
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-rosomakho-httpbis-h3-unbound-data__;!!Bt8RZUm9aw!6K3UbM5hk54HvWsHdiCCqKVJUTgtx2g0qLmAARnOERmZEwws6AthNcGWdyCLQgAGz2cAddHGhRWbCg$>
>>
>>
>> Abstract:
>>
>>    This document defines a new HTTP/3 frame type, UNBOUND_DATA, and a
>>    corresponding SETTINGS parameter that enables endpoints to negotiate
>>    its use.  When an endpoint sends an UNBOUND_DATA frame on a request
>>    or response stream, it indicates that all subsequent octets on that
>>    stream are interpreted as data.  This applies both to message body
>>    data and to octets transmitted after CONNECT or extended CONNECT.
>>    The use of UNBOUND_DATA removes the need to encapsulate each portion
>>    of the data in DATA frames, reducing framing overhead and simplifying
>>    transmission of long-lived or indeterminate-length payloads.
>>
>>
>>
>> The IETF Secretariat
>>
>>
>> This communication (including any attachments) is intended for the sole
>> use of the intended recipient and may contain confidential, non-public,
>> and/or privileged material. Use, distribution, or reproduction of this communication
>> by unintended recipients is not authorized. If you received this
>> communication in error, please immediately notify the sender and then delete
>> all copies of this communication from your system.
>>
>>
>>
>> --
>> Kazuho Oku
>>
>>
>>
>> This communication (including any attachments) is intended for the sole
>> use of the intended recipient and may contain confidential, non-public,
>> and/or privileged material. Use, distribution, or reproduction of this communication
>> by unintended recipients is not authorized. If you received this
>> communication in error, please immediately notify the sender and then delete
>> all copies of this communication from your system.
>>
>>
>>
>> --
>> Kazuho Oku
>>
>

-- 
Kazuho Oku