On Thu, Nov 12, 2020 at 03:23:08PM -0800, Christian Huitema wrote: > On 11/12/2020 2:15 PM, Martin Thomson wrote: > > > On Fri, Nov 13, 2020, at 05:15, Dmitri Tikhonov wrote: > >> My question would be: Why aren't connections in the other 11 > >> implementations > >> enter the Draining State? > > Neqo should. (I'm not sure that I have a test against our command-line > > server though, that is almost certainly doing bad things.) > > The description of the experiment says "*To conduct the experiment, I > had the client open and hold a QUIC connection with source CID 1 and > destination CID 2 for a maximum of 10s with the server, and then close > it. We then idle for 10s and repeat the steps a second time." Should the > draining period be longer than 10 seconds? Section 10.2 of the transport > spec says: "*The closing and draining connection states exist to ensure > that connections close cleanly and that delayed or reordered packets are > properly discarded. These states SHOULD persist for at least three times > the current Probe Timeout (PTO) interval as defined in [QUIC-RECOVERY > <https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#QUIC-RECOVERY>]." > That's what picoquic implements, and that's typically way less than 10 > seconds.
I ran some experiments myself and I realized that my original guess was incorrect. lsquic server retires the Initial DCID a short time after handshake succeeds. When a CID is retired, all incoming packets bearing it are dropped. lsquic keeps CIDs retired for at least 30 seconds and at most forever (old entries are purged opportunistically when new entries are added.) I looked for guidance in the Transport Draft for how long a CID is to stay retired (both Initial DCID and those retired via the RETIRE_CONNECTION_ID frame), but found none. - Dmitri.
