There are two different thresholds, amplification and congestion control.
1) If the server flight is larger than 3.6KB, the server will request
and acknowledgment before it continues.
2) The acknowledgement will act as a validation check for the IP
address. (There are details, but in most cases it will.) After that
point, the amplification limit is lifted. The limiting factor is now
congestion control, for which the recommended value would be the initial
window (IW). IW is typically 10 packets, which means the server can send
another 12KB before having to pause for an ACK. As long as the server
flight is shorter than 3.6+12 = 15.6 KB, the server hello will require 2RTT.
3) if the server flight is larger than 15.6 K, the server will have to
pause for an ACK, and the exchange will require 3 RTT, or maybe even more.
As Paul point out, if the client knows that the MTU of the path is
larger than 1200 bytes, it could send a larger initial packet. If the
initial packet is 8KB, the threshold above become 24KB and 104KB.
Of course, the client does not really "know" that the MTU is 8KB, and
the 8KB packet may be dropped by the network, causing retransmission and
further delay. But that's fixable. The client could send a 1200 bytes
initial, immediately followed by an 8KB initial MTU Probe. If the probe
arrives, the server gets extra anti-amplification credits and the
exchange completes quickly. In fact, even sending a 1500 bytes MTU probe
would provide 4.5KB of extra credits, allowing one-RTT completion if
server flight is less than 8.1KB.
Looks like a neat trick, which does not require any change in the standard.
-- Christian Huitema
On 3/31/2023 4:53 AM, Paul Vixie wrote:
all indications are that post-quantum crypto will make signatures much
larger than today's RSA does. we may need a larger initial window size,
and we may someday want MTU's larger than the one the internet inherited
from the 1983 10Mbit/sec ethernet standard. but use of ECDSA should help
avoid the size problem until well after QUIC's ubiquitous deployment, in
case we prefer to let the next generation grapple with this instead of
us here/now.
vixie
re:
Luke Curley wrote on 2023-03-31 04:45:
I briefly mentioned an issue in chat.
I was trying to debug why the QUIC handshake was taking 2-RTTs. Well
it turns out that our production certificates are laaarge; the RSA
cert and some intermediates added up to over 5.5kB.
So the client would send a ClientHello padded to 1.2kB. The server
would only be able to send 3.6kB before hitting the
amplification limit, and would have to wait for an acknowledgement
(padded again to 1.2kB) before it could send the next 3.6kB.
Fortunately we didn't need a 3rd round trip. The easy fix is to use an
ECDSA certificate but somehow they weren't supported internally...
