Draft: draft-ietf-quic-applicability

Commentary: " Idle period " , " network idle timeout " , and " idle timeout " are distinct ; addresses a comment in . 
 in , 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 wo n't have much effect here because of the prevalence of 30s UDP network idle timeouts on middleboxes . So guidance here should  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 . 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 do n't do hanging GETs and our infrastructure is designed to correctly handle NAT rebinds . 
 addressed by
Paragraph (version A):
Because QUIC is encapsulated in UDP, applications using QUIC must
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.
Paragraph (version B):
Because QUIC is encapsulated in UDP, applications using QUIC must
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.
Paragraph (version A):
Either the server or the client in a QUIC application can send PING
frames as keep-alives, to prevent the connection and any on-path
state from timing out.  Recommendations for the use of keep-alives
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
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.
Paragraph (version B):
Either the server or the client in a QUIC application can send PING
frames as keep-alives, to prevent the connection and any on-path
state from timing out.  Recommendations for the use of keep-alives
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
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.
Paragraph (version A):
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.
Paragraph (version B):
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.