Re: [quicwg/base-drafts] Fix handling of Retry in recovery (#3148)

[Jana Iyengar <[e-mail]>]

janaiyengar commented on this pull request.



> +## Handling Retry Packets
+
+A Retry packet causes a client to send another Initial packet, effectively
+restarting the connection process.  A Retry packet indicates that the Initial
+was received, but not processed.  A Retry packet cannot be treated as an
+acknowledgment.
+
+Clients that receive a Retry packet reset congestion control and loss recovery
+state, including resetting any pending timers.  Other connection state, in
+particular cryptographic handshake messages, is retained; see Section 17.2.5 of
+{{QUIC-TRANSPORT}}.
+
+The client MAY compute an RTT estimate to the server as the time period from
+when the first Initial was sent to when a Retry or a Version Negotiation packet
+is received.  The client MAY use this value in place of its default for the
+initial RTT estimate.

@mikkelfj's point, IIUC, is that connection ID based routing within your server infrastructure could route your new Initial to a server that is far off. I think this is a legitimate use case, but using this sample as the initial RTT value is fine I'd argue, even if it is wrong some times. It is not expected to be the common case, and you replace it in the RTT estimate with the first actual measured value anyways.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3148#discussion_r340383833