Change:
"Idle period", "network idle timeout", and "idle timeout" are distinct; addresses a comment in .
in , NAME said: This probably needs its own discussion...
note that we use the words "idle timeout" two different ways in the applicability document: (1) the network idle timeout, which is the shortest state timeout of a device on a path between the endpoints (2) the endpoint idle timeout transport parameter, which is the point at which a connection will simply silently close. While addressing this question (which I interpret as "we present session resumption as a solution for clients, but what about servers?), we should also clear up the terminology.
Setting a QUIC endpoint idle timeout above 30 sec won't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes. So guidance here should max out at 30s. Given the variety of different ways VM live migration is implemented and the variety of network control planes that can be used to steer traffic in this situation, the guidance should also not be too low... so if there is guidance here I'd say it should be in the 10-30s range. NAME does this seem reasonable?
See also / reference RFC 4787 (for UDP) and RFC 7857 / 2663 (for TCP).
I'd suggest a min of 30 seconds as being sensible for the public internet, and longer may be preferable if the deployment can consistently survive NAT rebinds. We have applications with much longer(ie: 5 minute) timeouts in production, but they don't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds.
addressed by

Discussion:
3.3. Because QUIC is encapsulated in UDP, applications using QUIC must <del> deal with short idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry will be expired after just thirty seconds of inactivity. </del> <ins> deal with short network idle timeouts.  Deployed stateful middleboxes will generally establish state for UDP flows on the first packet state, and keep state for much shorter idle periods than for TCP. RFC5382 suggests a TCP idle period of at least 124 minutes, though there is not evidence of widespread implementation of this guideline in the literature.  Short network timeout for UDP, however, is well- documented.  According to a 2010 study (Hatonen10), UDP applications can assume that any NAT binding or other state entry can expire after just thirty seconds of inactivity.  Section 3.5 of RFC8085 further discusses keep-alive intervals for UDP: it requires a minimum value of 15 seconds, but recommends larger values, or omitting keepalive entirely. </ins> By using a Connection ID, QUIC is designed to be robust to NAT address rebinding after a timeout.  However, some QUIC connections

firewalls will often not admit server traffic for which it has not kept state for corresponding packets from the client. <del> A QUIC application has three strategies to deal with this issue: </del> <ins> A QUIC application has three strategies to deal with this issue by adjusting idle periods (noting that idle periods and the network idle timeout is distinct from the connection idle timeout, defined as the minimum of the idle timeout parameter in Section 10.1 of QUIC): </ins> Ignore it, if the application-layer protocol consists only of interactions with no or very short idle periods, or the protocol's

are application specific, mainly depending on the latency requirements and message frequency of the application.  In this case, the application mapping must specify whether the client or server is <del> responsible for keeping the application alive.  Note that sending PING frames more frequently than every 30 seconds over long idle periods may result in a too much unproductive traffic and power usage for some situations. </del> <ins> responsible for keeping the application alive.  While Hatonen10 suggests that 30 seconds might be a suitable value for the public Internet when a NAT is on path, larger values are preferable if the deployment can consistently survive NAT rebinding, or is known to be in a controlled environments like e.g.  data centres in order to lower network and computational load.  Sending PING frames more frequently than every 30 seconds over long idle periods may result in excessive unproductive traffic in some situations, and to unacceptable power usage for power-constrained (mobile) devices. Additionally, time-outs shorter than 30 seconds can make it harder to handle trasient network interruptions, such as VM migration or coverage loss during mobilty. </ins> Alternatively, the client (but not the server) can use session resumption instead of sending keepalive traffic.  In this case, a

8. <del> QUIC connections are closed either by expiration of an idle timeout or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. </del> <ins> QUIC connections are closed either by expiration of an idle timeout, as determined by transport parameters, or by an explicit indication of the application that a connection should be closed (immediate close).  While data could still be received after the immediate close has been initiated by one endpoint (for a limited time period), the expectation is that an immediate close was negotiated at the application layer and therefore no additional data is expected from both sides. </ins> An immidate close will emit an CONNECTION_CLOSE frame.  This frames has two sets of types: one for QUIC internal problems that might lead