From 992a2d77df2e424ff0ff7e42cf71287965072f90 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 9 Jun 2020 16:42:48 +1000 Subject: [PATCH 1/3] Make keep-alive advice more generic This moves it up under the idle timeout section. As discussed on the issue, the HTTP draft is basically good. Closes #3723. --- draft-ietf-quic-http.md | 12 ++++---- draft-ietf-quic-transport.md | 54 +++++++++++++++++++++++------------- 2 files changed, 40 insertions(+), 26 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index ec96f4a5b8..bb99d9b249 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -893,12 +893,12 @@ do so if approaching the idle timeout. HTTP clients are expected to request that the transport keep connections open while there are responses outstanding for requests or server pushes, as -described in Section 19.2 of {{QUIC-TRANSPORT}}. If the client is not expecting -a response from the server, allowing an idle connection to time out is preferred -over expending effort maintaining a connection that might not be needed. A -gateway MAY maintain connections in anticipation of need rather than incur the -latency cost of connection establishment to servers. Servers SHOULD NOT actively -keep connections open. +described in Section 10.2.2 of {{QUIC-TRANSPORT}}. If the client is not +expecting a response from the server, allowing an idle connection to time out is +preferred over expending effort maintaining a connection that might not be +needed. A gateway MAY maintain connections in anticipation of need rather than +incur the latency cost of connection establishment to servers. Servers SHOULD +NOT actively keep connections open. ## Connection Shutdown diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 35c5ac407b..3995fd47dd 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2666,17 +2666,42 @@ ack-eliciting packet if no other ack-eliciting packets have been sent since last receiving and processing a packet. Restarting this timer when sending a packet ensures that connections are not closed after new activity is initiated. + +### Liveness Testing + +An endpoint that sends packets close to the effective timeout risks having +them be discarded at the peer, since the peer might enter its draining state +before these packets arrive. + +An endpoint can send a PING or another ack-eliciting frame to test the +connection for liveness if the peer could time out soon, such as within a PTO; +see Section 6.2 of {{QUIC-RECOVERY}}. This is especially useful if any +available application data cannot be safely retried. Note that the application +determines what data is safe to retry. + + +### Deferring Idle Timeout {#defer-idle} + An endpoint might need to send ack-eliciting packets to avoid an idle timeout if it is expecting response data, but does not have or is unable to send application data. -An endpoint that sends packets close to the effective timeout risks having -them be discarded at the peer, since the peer might enter its draining state -before these packets arrive. An endpoint can send a PING or another -ack-eliciting frame to test the connection for liveness if the peer could -time out soon, such as within a PTO; see Section 6.2 of {{QUIC-RECOVERY}}. -This is especially useful if any available application data cannot be safely -retried. Note that the application determines what data is safe to retry. +An implementation of QUIC might provide applications with an option to defer an +idle timeout. This facility could be used when the application has wishes to +avoid the loss of state that is bound to an open connection, but does not expect +to exchange application data for some time. With this option, an endpoint could +send a PING frame periodically to defer an idle timeout; see {{frame-ping}}. + +Application protocols that use QUIC SHOULD provide guidance on when deferring an +idle timeout is appropriate. Uncoordinated or unnecessary sending of PING +frames could have a detrimental effect on performance. + +A connection will time out if no packets are sent or received for a period +longer than the time negotiated using the max_idle_timeout transport parameter; +see {{termination}}. However, state in middleboxes might time out earlier than +that. Though REQ-5 in {{?RFC4787}} recommends a 2 minute timeout interval, +experience shows that sending packets every 15 to 30 seconds is necessary to +prevent the majority of middleboxes from losing state for UDP flows. ## Immediate Close {#immediate-close} @@ -5018,19 +5043,8 @@ The receiver of a PING frame simply needs to acknowledge the packet containing this frame. The PING frame can be used to keep a connection alive when an application or -application protocol wishes to prevent the connection from timing out. An -application protocol SHOULD provide guidance about the conditions under which -generating a PING is recommended. This guidance SHOULD indicate whether it is -the client or the server that is expected to send the PING. Having both -endpoints send PING frames without coordination can produce an excessive number -of packets and poor performance. - -A connection will time out if no packets are sent or received for a period -longer than the time negotiated using the max_idle_timeout transport parameter; -see {{termination}}. However, state in middleboxes might time out earlier than -that. Though REQ-5 in {{?RFC4787}} recommends a 2 minute timeout interval, -experience shows that sending packets every 15 to 30 seconds is necessary to -prevent the majority of middleboxes from losing state for UDP flows. +application protocol wishes to prevent the connection from timing out; see +{{defer-idle}}. ## ACK Frames {#frame-ack} From 71a41f772f34776e880ec4e3561f767d4aff9415 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 9 Jun 2020 15:17:08 -0700 Subject: [PATCH 2/3] Update draft-ietf-quic-transport.md Co-authored-by: Mike Bishop --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 3995fd47dd..5525a86d1a 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2687,7 +2687,7 @@ if it is expecting response data, but does not have or is unable to send application data. An implementation of QUIC might provide applications with an option to defer an -idle timeout. This facility could be used when the application has wishes to +idle timeout. This facility could be used when the application wishes to avoid the loss of state that is bound to an open connection, but does not expect to exchange application data for some time. With this option, an endpoint could send a PING frame periodically to defer an idle timeout; see {{frame-ping}}. From 2471d098303acc21638b387b5535b4bfbccc7df9 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 10 Jun 2020 08:38:53 +1000 Subject: [PATCH 3/3] Editorial tweaking --- draft-ietf-quic-transport.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 5525a86d1a..82ebc23a69 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2687,14 +2687,15 @@ if it is expecting response data, but does not have or is unable to send application data. An implementation of QUIC might provide applications with an option to defer an -idle timeout. This facility could be used when the application wishes to -avoid the loss of state that is bound to an open connection, but does not expect -to exchange application data for some time. With this option, an endpoint could -send a PING frame periodically to defer an idle timeout; see {{frame-ping}}. +idle timeout. This facility could be used when the application wishes to avoid +losing state that has been associated with an open connection, but does not +expect to exchange application data for some time. With this option, an +endpoint could send a PING frame periodically to defer an idle timeout; see +{{frame-ping}}. Application protocols that use QUIC SHOULD provide guidance on when deferring an -idle timeout is appropriate. Uncoordinated or unnecessary sending of PING -frames could have a detrimental effect on performance. +idle timeout is appropriate. Unnecessary sending of PING frames could have a +detrimental effect on performance. A connection will time out if no packets are sent or received for a period longer than the time negotiated using the max_idle_timeout transport parameter;