Summary

  • PADDING is a one-byte frame with no content or semantic value; it increases packet size but carries no application, STREAM or CRYPTO data.
  • A padding-only packet is in flight and consumes congestion-window capacity without eliciting the acknowledgments that open it; RFC 9000 says the sender SHOULD periodically add other ack-eliciting frames.
  • A client MUST expand every UDP datagram carrying Initial to at least 1200 bytes, while a server MUST do so for a datagram carrying an ack-eliciting Initial packet; neither rule proves progress.

An operator sees a 1200-byte UDP datagram and records useful Initial work. A second panel shows bytes in flight rising, so the event is marked as forward motion. That conclusion combines evidence that must remain separate: UDP datagram length; QUIC packet boundaries and packet type; PADDING byte count; presence of acknowledgment-triggering content; bytes in flight; congestion-window use; acknowledgment; handshake state; and application outcome.

A QUIC PADDING frame has type 0x00 and consists only of its identifying byte. It has no content and no semantic value. It can enlarge a packet, help reach the Initial minimum, and reduce some information available to traffic analysis. It does not carry application data, STREAM data or CRYPTO data. It does not constitute a receipt, result or completion signal. PADDING therefore cannot by itself prove useful peer processing, handshake advancement or application delivery.

A datagram may contain an Initial with PADDING beside other frames, or several coalesced QUIC packets. Length alone cannot show which constituent bytes advanced the handshake. An authorized endpoint must distinguish packet boundaries and protected frame structure before assigning meaning to the bytes. A packet containing PADDING may also contain an ack-eliciting frame and may then be acknowledged. That ACK is bounded evidence of packet processing; it does not turn PADDING into semantic content.

RFC 9000 excludes ACK, PADDING and CONNECTION_CLOSE from ack-eliciting content. PADDING alone therefore does not cause the receiver to send an ACK. A packet containing PADDING is nevertheless in flight for congestion control. A padding-only packet consumes congestion-window capacity without generating acknowledgments that open it, so the sender SHOULD periodically add other ack-eliciting frames. Rising bytes in flight are not equivalent to useful transport progress.

The 1200-byte rule is precise. A client MUST expand every UDP datagram carrying an Initial packet to at least 1200 bytes through PADDING or packet coalescing. A server MUST do so for a UDP datagram carrying an ack-eliciting Initial packet. The rule tests support for a reasonable path maximum transmission unit; client expansion also reduces amplification available to a server responding toward an unvalidated address. It does not require 1200 bytes of handshake content, and not every Initial uses PADDING.

Before address validation, all UDP payload bytes uniquely attributable to the connection count in the server’s three-times anti-amplification ledger, including PADDING bytes. Non-semantic does not mean cost-free. PADDING can change observable sizes and reduce some traffic-analysis information, but it does not guarantee privacy or hide timing, direction, packet count or all length information. Privacy-safe evidence retention and this ledger are editorial guidance, not RFC requirements.