Skip to content

Add RFC 9221 unreliable datagram support - #520

Open
aswanthk777 wants to merge 1 commit into
Tencent:developfrom
aswanthk777:pr-rfc9221
Open

Add RFC 9221 unreliable datagram support#520
aswanthk777 wants to merge 1 commit into
Tencent:developfrom
aswanthk777:pr-rfc9221

Conversation

@aswanthk777

Copy link
Copy Markdown

Implement QUIC DATAGRAM frames (types 0x30/0x31) end to end:

  • frame: encode/decode/wire_len/qlog for Frame::Datagram, with and
    without the explicit length field
  • transport params: max_datagram_frame_size (0x0020); 0 (default) keeps
    the extension disabled, matching RFC 9221 semantics
  • connection: bounded send/recv queues, public API (datagram_send,
    datagram_recv, datagram_recv_queue_len, datagram_max_send_size),
    DATAGRAM frames written into 1-RTT packets after stream frames,
    oversize datagrams dropped against the peer's advertised limit, and
    queued datagrams correctly trigger packet emission on an otherwise
    idle connection (send-path and path-unaware-frame checks include the
    datagram queue, so datagram-only workloads work under multipath
    scheduling too)
  • config: Config::set_max_datagram_frame_size
  • tests: frame codec round-trip, end-to-end delivery, peer-without-
    support drop behavior

Running in production as the transport of a TUN-over-QUIC multipath tunnel (~170 Mbps aggregated over two links in lab tests, per-path congestion control via the existing multipath scheduler).

🤖 Generated with Claude Code

https://claude.ai/code/session_01LqZK49rKWmBNsihzCrsbgD

Implement QUIC DATAGRAM frames (types 0x30/0x31) end to end:

- frame: encode/decode/wire_len/qlog for Frame::Datagram, with and
  without the explicit length field
- transport params: max_datagram_frame_size (0x0020); 0 (default) keeps
  the extension disabled, matching RFC 9221 semantics
- connection: bounded send/recv queues, public API (datagram_send,
  datagram_recv, datagram_recv_queue_len, datagram_max_send_size),
  DATAGRAM frames written into 1-RTT packets after stream frames,
  oversize datagrams dropped against the peer's advertised limit, and
  queued datagrams correctly trigger packet emission on an otherwise
  idle connection (send-path and path-unaware-frame checks include the
  datagram queue, so datagram-only workloads work under multipath
  scheduling too)
- config: Config::set_max_datagram_frame_size
- tests: frame codec round-trip, end-to-end delivery, peer-without-
  support drop behavior

(cherry picked from commit b40fd490e87e15659a489390b2cadc73e15cf362)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant