On 3/30/2023 12:37 AM, Martin Thomson wrote:
On Thu, Mar 30, 2023, at 15:57, Marcin Nawrocki wrote:
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.
Yes, this will affect RTT estimates, but the effect will wash out over time.
The net effect is an inflated RTT estimate.
You can maybe correct for this using ACK Delay.
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.
I believe that some people already do this split, yes. I would prefer that
servers use subcerts for this:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts
There is another issue. It is a bit risky for the server to send the ACK
Initial before the client IP is validated. If the server ACKs the
client's initial packets, the client does not need to send any further
traffic until it has received the server hello. If the server hello is
lost, the server will have to resend it, and it will have to do so
within the amplification budget -- which in some cases may not be possible.
There are potential workarounds of course. For example, the server could
bundle a PING with the ACK, to force the client to send more initial
packets and thus complete address validation.
We may also lift the requirement that all server initial packets be
padded to 1200 bytes, which would allow for better use of the
amplification budget. But that's for QUIC v3...
-- Christian Huitema
