> On 1. Apr 2023, at 01:59, Christian Huitema <[email protected]> wrote: > > 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. Hi Christian,
just wondering: Using IW = min(10*MSS, max(2*MSS, 14600)) from https://www.rfc-editor.org/rfc/rfc6928.html#section-2 for TCP, which also seems to apply for QUIC according to https://www.rfc-editor.org/rfc/rfc9002.html#section-7.2 allows you to send 10 packets of 8KB? Wouldn't the second term limit you to 2 packets in case of the MTU of 8KB? Best regards Michael > > 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... >
