Summary

  • max_udp_payload_size is an authenticated unilateral declaration of the declaring endpoint's largest willing UDP payload, not a path measurement.
  • QUIC datagram-size accounting is the UDP payload, excluding IP and UDP headers; PMTU is the maximum complete IP-packet size the path can carry without fragmentation.
  • The maximum UDP payload is the applicable PMTU minus the IP and UDP headers, and the sender must also respect the peer ceiling and current PMTUD or DPLPMTUD evidence.

The operational mistake is easy to make. A dashboard receives a transport parameter during the cryptographic handshake, labels its value “MTU,” and turns a statement about one endpoint's receive capacity into a claim about the network between two endpoints. RFC 9000 does not support that interpretation.

QUIC's max_udp_payload_size is an endpoint property. The declaring endpoint says how large a UDP payload it is prepared to receive. The declaration is authenticated once the handshake makes it available and validates it, but authentication proves origin and integrity, not the condition of the intervening path. A peer may use the value as an additional constraint on sending; it is not path state, a safe send-size measurement, or a performance guarantee. Its default is 65527, the maximum permitted UDP payload. Values below 1200 are invalid and cause transport-parameter error handling.

The accounting must remain explicit. A QUIC datagram contains one or more complete QUIC packets. RFC 9000's datagram-size accounting includes the QUIC headers and protected payloads in the total UDP payload, but excludes the IP and UDP headers. PMTU is different: it is the maximum size of the complete IP packet that the path can carry without fragmentation under the relevant conditions. The corresponding maximum UDP payload is the applicable PMTU minus the IP header and UDP header. These quantities must not be used interchangeably.

PMTU depends on path characteristics, can change over time, and can differ for every local/remote address pair.

QUIC requires a path to support at least 1200 bytes of UDP payload. Without PMTUD or DPLPMTUD, endpoints should not send datagrams larger than 1200 bytes. UDP datagrams carrying QUIC must not be fragmented at the IP layer; for IPv4, the Don't Fragment bit must be set if possible. Before a peer value is known, sending above 1200 risks loss. The operational send ceiling is the tighter of the maximum UDP payload derived from current path evidence and the authenticated peer ceiling. Initial datagrams padded to at least 1200 establish only the protocol minimum, not a larger endpoint ceiling.

PMTUD uses ICMP feedback, but an ICMP Packet Too Big indication must be validated against addresses, ports and, where possible, the QUIC connection ID. An endpoint must not increase PMTU merely because an ICMP message claims a value. DPLPMTUD tests candidate sizes with acknowledged probe packets and tracks probe acknowledgment or loss for each local/remote address pair. Probe loss is not reliable evidence of congestion and should not itself trigger a congestion response, although probes consume congestion window.

The evidence ledger must separately record connection and observation time; local and remote addresses; declaring endpoint and authenticated max_udp_payload_size; when the value became available and whether a remembered value governed 0-RTT; current PMTU and derived maximum UDP payload; PMTUD or DPLPMTUD method, state, probe sizes and acknowledgments/losses; validated ICMP evidence; IP version, header assumptions and fragmentation policy; application payload, QUIC overhead and coalescing; and loss, congestion, throughput, latency, completion and business outcome.

Neither the parameter nor an acknowledged probe proves application success, receive-buffer availability or performance.

The distinction also prevents category errors elsewhere: HIST-008 covers the history of PMTUD evidence and control; TR-039 covers the three-times anti-amplification budget; TR-049 covers multiple QUIC packets coalesced in one datagram; TR-046 covers stream and connection flow-control permission; and TR-040 covers connection IDs and migration. None supplies path-size evidence for this address pair.