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 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://mailarchive.ietf.org/arch/msg/quic/3v2fwQJeWO8m7wYazBPxwRDWl88/>,
>>> 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
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-rosomakho-httpbis-h3-unbound-data/
>>> HTML:
>>> https://www.ietf.org/archive/id/draft-rosomakho-httpbis-h3-unbound-data-00.html
>>> HTMLized:
>>> https://datatracker.ietf.org/doc/html/draft-rosomakho-httpbis-h3-unbound-data
>>>
>>>
>>> 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