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. The description of the experiment does not say whether the successive connection attempts used the same IP address. For Picoquic at least that's important, because Picoquic retrieves the handshake context using the combination of Initial DCID and client IP + port. Multiple connection attempts using the same Initial DCID and different IP addresses will be treated as independent connections. This was one of the suggestion in https://tools.ietf.org/html/draft-kazuho-quic-authenticated-handshake-01. -- Christian Huitema
