Change:
the amplitude of amplification attacks caused by server responses toward an unverified client address; see address-validation. <ins> Enforcement of the max_udp_payload_size transport parameter (transport-parameter-definitions) might act as an additional limit on packet size.  Exceeding this limit can be avoided once the value is known.  However, prior to learning the value of the transport parameter, endpoints risk datagrams being lost if they send packets larger than 1200 bytes. </ins> Datagrams containing Initial packets MAY exceed 1200 bytes if the <del> client believes that the Path Maximum Transmission Unit (PMTU) supports the size that it chooses. </del> <ins> client believes that the network path and peer both support the size that it chooses. </ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. A server MUST discard an Initial packet that is carried in a UDP <del> datagram that is smaller than 1200 bytes.  A server MAY also immediately close the connection by sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION; see immediate-close-hs. </del> <ins> datagram with a payload that is less than 1200 bytes.  A server MAY also immediately close the connection by sending a CONNECTION_CLOSE frame with an error code of PROTOCOL_VIOLATION; see immediate-close- hs. </ins> The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation. 14.1. <del> The PMTU is the maximum size of the entire IP packet including the IP header, UDP header, and UDP payload.  The UDP payload includes the QUIC packet header, protected payload, and any authentication fields. The PMTU can depend upon the current path characteristics. Therefore, the current largest UDP payload an implementation will send is referred to as the QUIC maximum packet size. </del> <ins> The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP payload.  The UDP payload includes the QUIC packet header, protected payload, and any authentication fields.  The PMTU can depend on path characteristics, and can therefore change over time.  The largest UDP payload an endpoint sends at any given time is referred to as the endpoint's maximum packet size. </ins> QUIC depends on a PMTU of at least 1280 bytes.  This is the IPv6 minimum size RFC8200 and is also supported by most modern IPv4

Discussion:
This isn't a complete dissertation on how clients might choose to use larger packet sizes. In particular, it doesn't capture the whole discussion about starting at a higher size being a way to raise the 1280 to something higher, with the requisite cost being that you might have failures. Deciding to put that in would be much harder. What this does is just say that the transport parameter acts as a further limit on packet size and that you won't know that prior to knowing. That means that you are guessing about the network path AND your peer when you decide to send >1200 (to be fair, the former really only applies for IPv4, and it's not much of a guess).
The transport parameter (formerly known as ) instructs the receiving endpoint that it should try to avoid sending packets bigger than that number. However, some packets are sent before the transport parameters are received. Should the draft contain some guidance about what value to use during the handshake? Our implementation currently uses a default value of 1350 until the transport parameters have been received, and I wonder if that may lead to interop issues if some Web servers implement QUIC but drop packets larger than 1300 for example. One could consider using the minimum possible value (1200) during the handshake but I fear that this would negatively impact performance.
This is a good issue. If we are to provide guidance, my preference goes to stating that an endpoint should not send datagrams that are larger than its first flight, unless that endpoint implements PMTUD. The rationale is that we should avoid packets starting to get dropped mid-connection. First flights getting dropped is fine, because clients can do happy-eyeballing. Even if they only use QUIC, not starting a transaction is much better than a transaction inflight getting lost.
I'm with NAME here. As a client, if you send at 1350 and those are all dropped, that reduces to "the path doesn't support UDP". The real risk is if you send at 1200 and then increase that later without first probing. I'm happy to take this as editorial, but would prefer to confirm that no one wants a substantive change.
I agree with NAME : I'm happy with clarifying that this will look like an MTU issue.
One suggestion, but LGTM otherwise.Thanks for updating the adjacent text, this LGTM