Change:
with a Retry packet (see validate-retry) or in a previous connection using the NEW_TOKEN frame (see validate-future). <ins> In addition to sending limits imposed prior to address validation, servers are also constrained in what they can send by the limits set by the congestion controller.  Clients are only constrained by the congestion controller. </ins> 8.1.1. Upon receiving the client's Initial packet, the server can request

Discussion:
Clarifies how we prohibit a server from sending too many packets to a client prior to validating the address.
NAME That's definitely true. Addressed in f7b0187.
I'm not sure if this is correct. If a packet is declared lost, it can be retransmitted, so in that case the amount of data sent is larger than initial cwnd.
NAME That's a good point. Does changing the text to refer to "congestion avoidance algorithm" instead of "initial congestion window" resolve the concern?
This looks fine, but I have a new concern: this makes it appear as though the congestion window doesn't apply to the server. It does. Would this be better?
NAME Thanks. Applied in 5522bd5.
Thanks everyone. This looks nothing like what it did when it started, but it's much clearer as a result.
To avoid it being used as a DDoS attack vector, we forbid the server from sending more than three datagrams before the path is validated during the handshake. Do we need similar safeguard for the number of datagrams that a client may emit before it sees a packet from the server? IMO, it might be worth considering, due to the following reasons: The attack vector exists. For example, an attacker can inject a DNS response for a huge website to a DNS server. Then, clients would start sending 0-RTT packets to the victim. The number of packets that the client can send prior to path being validated was one for TCP. The QUIC transport draft is silent about the limit (though INITCWND would practically become in play here).
We limit amount of bytes now, not number of packets, no? If we limit the client, it would need to be a rate limit, otherwise it would never be able to connect again later when network conditions improve. I'm not sure it makes sense to have a MUST limit on client, as there can be many deployments types with different attack vectors. DNS might not be in the equation. However, obviously a client should not saturate a link on connection retries.
That's a good point. This is not a reflection attack (unlike the server's packets) and therefore it makes more sense to define a limit using number of bytes. IMO it can be a fixed number of bytes that can be transmitted in one RTO.

For example, "a client SHOULD NOT send more than 3 * MTU bytes per every retransmission timeout, until it receives a packet from a server."
My thinking was that the initial CWND was a sufficient limit.
NAME If that's the consensus, I am happy to accept it (I do not have a strong opinion here).
That's what I remember us arriving at before. But I'm happy to have it explicitly stated if it's not.
NAME I don't see anyone objecting to that approach, is there some text you'd like added to one of the drafts?
I was thinking: The client creates a valid connection. Then initiates a migration to a new path that it does not own for the sole purpose of DoS'ing some other poor individual. While there is a setup cost, the migration can be repeated for the same or different targets until the peer decides it is enough and closes. How is the initial CWND sufficient protection against that?
NAME Malicious clients can always send an unlimited number of packets anywhere. QUIC doesn't change that.
NAME I mean that the client causes the peer to respond to a fake migration attempt and coerces the peer into sending packets elsewhere. I'm not sure if that can amplify, e.g. via PMTU probe.
I think we had a similar discussion twice, getting some text, and later removed. But I don't recall anymore.
There's a section on address validation which should prevent reflection attacks: URL This issue is about what the client can send.
NAME thanks, that covers it.
NAME Filed . I do not have a strong opinion on whether this needs to be clarified, therefore I would not oppose if the PR gets refused.
Thanks for the PR. I'm not against clarification, I'm just not sure what to write and I'd like to close this before Tokyo if we can. Taking a look at the PR now.
I think that you have this backwards. The point here is that the client is limited by INITCWND. The server has to abide by the x3 rule.