Re: Unbound DATA frames in HTTP/3 proposal

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