Draft: draft-ietf-quic-transport

Commentary: Changes are : define idle timeout as skip draining period when idle timeout expires 
 -- yup , I realized it after , so discussed on slack ( you 're on the thread ) 
 Currently , the t is in units of seconds . This seems to be too restrictive and not very future proof . Additionally , from an API perspective , most other timers are settable on the millisecond scale , so it creates a kind of ugly discrepancy between all the different timers settable by the app if just one of them has units of seconds . I propose we change the units from seconds to milliseconds . The change both for implementations and spec should be minimal , and it makes things ( timers ) a little more consistent . 
 This seems sensible to me both for consistency and I can imagine cases when one would want to specify a fraction(ie : 1/2 of a second ) . 
 Agreed . A second is an eternity for a intra - datacenter connection for example . For future proofing all time units should be at least msec IMO . 
 Do n't we want to specify a minimum value now ? 
 No , I do n't think so . Even before , if you had a greater than 1 sec RTT ( somehow ... ) if you set an idle timeout of 1 second it would cause you problems . I think bottom line you be smart about your idle timeout values . If you set too small a value you can unnecessarily kill your own connection . 
 As says , actual idle timeout depends on RTT , and that ’s what we have adopted in . 
 This SGTM . 
 I support this 
 I think this has rough consensus . Tagging as such and reassigning . 
 IIUC , the primary reason of having STATELESS_RESET is to let the client notice that the connection is dead immediately , so that it can retransmit the request using a new connection . However , when a server receives a request immediately after it 's idle close timer has expired , it can not send any packet in response , because it is in the draining period . Is this the expected behavior ? IMO , we should always allow a server to respond whenever it receives a packet after the idle timeout has expired . One way of allowing that is to let an endpoint immediately discard the connection state when the idle close timer expires . 
 As long as the idle timeout is longer than the draining period would be , I think that this is right . The text was there to allow for the case where a peer attempted to restart use of the connection near the end of the idle timeout period , but was unsuccessful . On balance , a stateless reset is better in that case . 
 Just checking what my code does : at the end of the idle period , the server just gets rid of the connection . No message , no draining period . Maybe this is a bug , but it felt right ... 
 Tokyo conclusion : Forbidding the server from responding in this window is not great . We will drop the closing / draining period after an idle timeout and have the endpoint just drop state . suggested that you could send the CONNECTION_CLOSE that you might have otherwise sent , but it is easier to just shortcut the closing period . 
 Amendment based on discussion : suggest setting the idle timeout to to avoid pathological cases .
Paragraph (version A):
If the idle timeout is enabled, a connection that remains idle for
longer than the advertised idle timeout (see transport-parameter-
definitions) is closed.  A connection enters the draining state when
the idle timeout expires.
Paragraph (version B):
If the idle timeout is enabled, a connection is silently closed and
the state is discarded when it remains idle for longer than both the
advertised idle timeout (see transport-parameter-definitions) and
three times the current Probe Timeout (PTO).