Original text:
the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP.  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

Reviewer comments:
by specifying that IW should be updated if the max packet size decreases in order to complete the handshake.
Broken off from Gorry's comments in per NAME request
Recovery says "QUIC begins every connection in slow start with the congestion window set to an initial value." There's no mention of updating the initial congestion window, so at the beginning of the connection is currently the only time it's set. QUIC advises setting do not fragment, and UDP typically gets dropped instead of fragmented in my experience even without the flag set, so I believe that simplifies the situation. Given that, along the lines of (iii), I can imagine one potential issue is if the initial window is set to a large value based on some past information and then the MTU is decreased in order to allow the handshake to complete. Currently there's nothing saying that the IW should be re-calculated if the max packet size decreases during the handshake, and adding one would be along the lines of your second suggested option. But I'm also fine with removing the twice max datagram size clause, but that seems like a larger departure from existing RFCs, which makes me hesitant. URL
I think that - as a recommendation - this is fine. Like everything else we recommend in this draft, it is almost certainly not congruent with what implementations will do and that is OK. My suggestion is that those who want to look into this further do so and document their results in a draft that will be pursued independent of QUIC. At some point we have to say no to further refinement and that point has passed.
QUIC seems to me to propose the first IETF CC that with a larger IW for datagrams,. If people in future do happen to use jumbo Ethernet frames, the case Ian describes is sufficiently gross that QUIC needs to suggest/require a remedy. I think I'd be happy with either of Iain's 2 simple proposals.
Gorry you wrote "Retransmission with a more appropiate PMTU does not change the IW, which then sends too many segments/packets." However, if you retransmit because you have experienced loss in the initial round, don't you anyway have to decrease your congestion window? About this RFC6928 says: "Furthermore, to limit any negative effect that a larger initial window may have on links with limited bandwidth or buffer space, implementations SHOULD fall back to RFC 3390 for the restart window (RW) if any packet loss is detected during either the initial window or a restart window, and more than 4 KB of data is sent." So understanding would be that you are actually already supposed to kind or "reset" the initial window, no?
FWIW, I don't have a strong opinion on what to do here, and I'm personally fine with doing nothing as well, but I wrote up the PR that seems most inline with existing RFCs from my reading.
I agree with Mirja on what TCP should do, and that such paths are recommended to reset IW to RW. That seems safe. My point was slightly different, we could consider for QUIC that the reduction might allow IW (cwnd) to be recomputed based on the actual PMTU. The PR seems to be heading this direction.

Revised text:
the byte limit to account for the smaller 8 byte overhead of UDP compared to the 20 byte overhead for TCP. <ins> If the maximum datagram size changes during the connection, the initial congestion window SHOULD be recalculated with the new size. If the maximum datagram size is decreased in order to complete the handshake, the congestion window SHOULD be set to the new initial congestion window. </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