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... On Thu, Mar 30, 2023 at 3:59 PM Marcin Nawrocki < [email protected]> wrote: > Hi QUIC folks, > > > I just want to follow up on my presentation [1] today as we ran out of > time and I am super interested in hearing more about your experiences on > how TLS configurations influence the QUIC performance. > > Please use the mailing list or just catch me at the IETF 116. > > > Unfortunately, I ran out of time before presenting the third challenge: An > Initial containing both, the ACK and ServerHello, can skew the RTT > estimation of the client for some deployments (e.g., CDNs). This is because > the QUIC server can be separate from the process that has access to TLS > material, so there is a noticeable delay for fetching the required TLS > data. > > Opinions on how to deal with this? Some CDNs split the Initial ACK and > Initial ServerHello into two packets, leading to more padding bytes. > Please see my slides 15-21 [1] for more information. > > > Also, I am happy to receive more feedback on the other challenges! Thanks > again. > > > Cheers, > > Marcin > > > [1] > https://datatracker.ietf.org/meeting/116/materials/slides-116-quic-revisiting-quic-handshakes-and-tls-deployment-about-three-challenges-00.pdf >
