Original text:
the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP.  The minimum congestion window is the smallest value the congestion window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size.

Reviewer comments:
Clarifies the impact of the anti-amplification factor on congestion control. Part of
When the client has a large first flight (post-quantum, or 0-RTT), it can send 10 packets at once. But that does not mean that the server can immediately send as much as 3x it receives in response, because that is above the INITCWND - the initial assumption about the network capacity. Things to be considered here are: Server cannot rely on CC until the client's address is validated, because an attacker might spoof Initial ACKs. At the very least, server needs to send one Initial in response to every client Initial packet not containing ACKs, otherwise the handshake might fail when there is heavy loss. Based on this observation, to me it seems that the easiest way of going forward would be to state that the amplification limit changes from 3x to 1x once the amount of data being sent by the server reaches INITCWND. Disclaimer: this issue popped up while trying to find out a response to NAME claim that quicly sends 3x that is above INITCWND, when the client sends a large amount of 0-RTT data. He's correct, and NAME and I think that this is a spec-issue.
Just to clarify, only an on-path attacker can do this, right?
I agree it should be limited to INITCWND. Here's how I read(and intended to write) the text: 1) Congestion control always applies, because I don't know of anywhere we say otherwise. 2) In addition, prior to address validation, the amplification limit of 3x also applies on the server side. Init CWND section: URL
NAME An off-path attacker can do that. An attacker can easily guess the packet number that the server uses, and spoof an ACK without actually receiving a packet from the server. Note also that there is no guarantee that there would be enough entropy in server-generated CID, even though a server can generate CIDs in such a manner. That's why we postpone the validation of the path until the server receives a Handshake packet. NAME I think I agree with you that the limit can be defined as .
Thanks NAME PTAL at PR and see if that clarifies this issue or if something else is necessary.
At the editor's meeting, we concluded that the pseudocode did not represent the current text about re-arming the PTO alarm. I merged the first PR because I think it's a nice clarification and I'll send out a PR for the pseudocode.
Thank you for the quick PR. I've stated my slight preference, but the text looks already :+1: to me.

Revised text:
the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. <ins> Prior to validating the client's address, the server can be further limited by the anti-amplification limit as specified in Section 8.1 of QUIC-TRANSPORT.  Though the anti-amplification limit can prevent the congestion window from being fully utilized and therefore slow down the increase in congestion window, it does not directly affect the congestion window. </ins> The minimum congestion window is the smallest value the congestion window can decrease to as a response to loss, ECN-CE, or persistent congestion.  The RECOMMENDED value is 2 * max_datagram_size.