Change:
10.2. <del> 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. </del> <ins> 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). </ins> Each endpoint advertises its own idle timeout to its peer.  An enpdpoint restarts any timer it maintains when a packet from its peer

Discussion:
Changes are: define idle timeout as skip draining period when idle timeout expires
NAME -- 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.
Don't we want to specify a minimum value now?
No, I don'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 NAME 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 cannot 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. NAME 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.