Thanks for the reaction Martin. Amplification protection is unique to QUIC, DTLS. I don't think it could be addressed in TLS.
Regarding the kinitRTT=333, it comes (I think) from RFC6298's initial RTO of 1s. That RTO tries to be large to cover common network RTTs and small to allow for recovery. So, I could see the RTO being a TCP update issue, not so much a TLS issue. About the initial congestion window, I think that would be a TCP issue as well. Hard to do globally as it happened with the initcwnd=3 to initcwnd=12 jump. But I believe many CDNs already use large initcwnd's anyway, so this may be lower priority to do. In other words, I think amplification is still something to consider in QUIC. The other two are probably more suitable for TCP. ----- > During the development of QUIC we were aware of the possibility of having a > larger handshake and so most implementations are tested for compatibility. > > What we did not do is tune the handshake parameters (RTT and amplification > limit) to allow for higher performance under these conditions. The exact > sizes of messages was not knowable at the time and so we couldn't make firm > decisions. > > That all said, increasing amplification by a factor of 3-5 over our existing > value (3x) seems unwise. > > The TLS WG is probably the right place to continue this discussion as - while > QUIC might be able to adjust these parameters - the primary changes need to > occur in the TLS stack. I'm aware of several attempts to change TLS, each of > which might motivate a different adaptation in QUIC. _____________________________________________ From: Kampanakis, Panos Sent: Tuesday, December 19, 2023 11:11 PM To: '[email protected]' <[email protected]> Subject: Amplification window, initial congestion window, initial RTT and new post-quantum signature implications Hi all, I was wondering if there have been any discussion about new quantum-resistant algorithms and their impact on QUIC. Looking back in the list archive I could only find https://mailarchive.ietf.org/arch/msg/quic/cA_azemZvSQadc9FvWnMfN-malQ/ which brought up the initial congestion and the amplification window issues which could introduce an RTT each to the handshake due to the large "post-quantum auth data" from the server. I don't think that discussion converged to any actionable items. Recently published https://www.nccoe.nist.gov/sites/default/files/2023-12/pqc-migration-nist-sp-1800-38c-preliminary-draft.pdf (Section 7.3, Figure 5) also showed that packet pacing can introduce >RTT time to each handshake. kInitialRtt=333 is a "SHOULD" in RFC9002 so it could be adjusted, but I am not sure that should be left to the implementer. Tweaking the amplification window to 10-15x as the new signature algos would require, increases the amplification risk. Validation tokens could alleviate the issue especially for clients that keep coming to the same servers, but it is not a general solution. Increasing the initial congestion window is already done by CDNs, but I am not sure it is the norm for most QUIC uses. So, has the WG generally considered options to address these issues?
