Visual RFC.
ALL RFCs / RFC 9221
Read the RFC ↗
RFC 9221 / UNRELIABLE QUIC DATAGRAMS

Fit the whole frame without fragmentation

03

A large peer receive limit does not guarantee that much payload fits on a path. The sender also has to fit the frame inside a QUIC packet subject to UDP size, path MTU and other packet contents.

RFC 9221 · § 5EXAMPLE
3 / 3
Fit the whole frame without fragmentationThe first worked budget includes the one-byte frame type, two-byte encoded length44ad and1197-byte payload, totaling1200 frame bytes. A tighter1000-byte remaining packet-space budget uses length43e5 and997 data bytes. The final1198-byte payload would need1201 frame bytes and stops before sending under the peer1200 limit, with no automatic fragmentation. Payload blocks are schematic and not expanded full messages; packet overhead is outside the stated remaining frame-space budget.Payload must fit after frame overheadRequested payload: 1198 bytes1 + 2 + 1198 = 1201 frame bytesSenderPeer limit 1200too large · do not sendDATAGRAM cannot be fragmented
03
Stop an oversized message without automatic fragmentation.

A1198-byte payload would make1201 frame bytes. The sender must not send it beyond the peer limit, and DATAGRAM provides no fragmentation/reassembly.

Source for this drawing: RFC 9221 · Read RFC section 5 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
MTU
The maximum transmission size supported by a network path.
Frame overhead
The encoded type and optional length bytes in addition to application data.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

DATAGRAM frames cannot be fragmented. The peer’s full-frame limit can be further reduced by max_udp_payload_size and the path MTU, so applications must handle a smaller usable size.

  • DATAGRAM frames cannot be fragmented. The peer’s full-frame limit can be further reduced by max_udp_payload_size and the path MTU, so applications must handle a smaller usable size.
  • With peer limit 1200 and a 0x31 frame, a 1197-byte payload uses one byte for Type and two for Length:1+2+1197=1200. This assumes that much frame space is otherwise available in the packet.
  • If only1000 bytes remain for this frame after packet overhead and other contents, the payload can be997 bytes with the same one-byte type and two-byte length:1+2+997=1000.
  • A1198-byte payload needs1201 full-frame bytes and exceeds the chosen1200 receive limit. Do not send it as one frame or assume this extension will split and reassemble it.
  • These figures are examples, not a universal QUIC datagram payload size. An application can choose smaller messages or define its own appropriate handling when an intended message does not fit.
DETAILS

The packet-space budget is explicitly the remaining space for this frame, not a claim that a 1000-byte UDP datagram satisfies every QUIC packet rule. Length 1197 and997 each use a two-byte QUIC varint. Limits concern encoded frame size, while packet headers, authentication tags and other frames consume additional outer space.

Read the RFC section ↗

All chapters in RFC 9221

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗