Draft: draft-ietf-quic-applicability

Commentary: One concern I have with short idle timeout is impact on VM live migration . The current guidance with TCP default timeouts allows LM to have a blackout period of under 9 seconds . Do we need any guidance here to not use very low default timeouts ? 
 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 
 This is related to quicwg / base - drafts and depends on the outcome there . 
 PR now indicated that the idle timeout could be exposed to the application . However , we should probably say a bit more what to do with it . I guess the minimum would be to say that the keep - alive frequency needs to be clearly smaller than the idle timeout , e.g. half the timeout . Is there anything more we could say ? any thoughts ? Or text you can provide ? 
 PR provides some more guidance now but it still does n't discuss suitable value or ranges . What values are used in current implementations ? Should we say more ? 
 This is reasonable advice . A little redundant with the advice in the spec , but not overly so , I think .
Paragraph (version A):
Alternatively, a QUIC connection will be silently closed by each
endpoint separately after an idle timeout.  The idle timeout is
announce for each endpoint during connection established and should
be accessible by the application.  If an application desires to keep
the connection open for longer than the announced timeout, it can
send keep-alives messages.  See {#resumption-v-keepalive} for further
guidance.
Paragraph (version B):
Alternatively, a QUIC connection can be silently closed by each
endpoint separately after an idle timeout.  If enabled as indicated
by a transport parameter in the handshake, the idle timeout is
announced for each endpoint during connection establishment and the
effective value for this connection is the minimum of the two
advertised values.  An application therefore should be able to
configure its own maximum value as well as have access to the
computed minimum value for this connection.  An application may
adjust the maximum idle timeout based on the number of open or
expected connections as shorter timeout values may free-up memory
more quickly.  If an application desires to keep the connection open
for longer than the announced timeout, it can send keep-alives
messages, or a QUIC implementation may provide an option to defer the
time-out to avoid unnecessary load, as specified in Section 10.2.2 of
QUIC.  See resumption-v-keepalive for further guidance on keep-
alives.