Re: [quicwg/base-drafts] Keep-alive requirements (#744)

[Mike Bishop <[e-mail]>]

MikeBishop approved this pull request.

LGTM, modulo what I hope is an extra negation rather than a real disagreement.

> @@ -841,6 +841,22 @@ A server MUST treat a MAX_PUSH_ID frame payload that is other than 4 octets in
 length as a connection error of type HTTP_MALFORMED_MAX_PUSH_ID.
 
 
+# Connection Management
+
+QUIC connections are persistent.  All of the considerations in Section 9.1 of
+{{?RFC7540}} apply to the management of QUIC connections.
+
+HTTP clients are expected to use QUIC PING frames to keep connections open.
+Servers SHOULD NOT use PING frames to keep a connection open.  A client SHOULD
+NOT use PING frames for this purpose unless there are no responses outstanding

I think you have one more negative here than you meant.  A client SHOULD NOT use PING frames for this purpose when there are no responses outstanding.  If you're waiting on a server response, that's exactly when it's critical to keep the connection alive and the NAT bindings fresh, so that you're sure you can get the server response when it finally arrives.  If you're not waiting on anything, that's when it's fine to let the connection idle and potentially close.

> @@ -841,6 +841,22 @@ A server MUST treat a MAX_PUSH_ID frame payload that is other than 4 octets in
 length as a connection error of type HTTP_MALFORMED_MAX_PUSH_ID.
 
 
+# Connection Management
+
+QUIC connections are persistent.  All of the considerations in Section 9.1 of
+{{?RFC7540}} apply to the management of QUIC connections.
+
+HTTP clients are expected to use QUIC PING frames to keep connections open.
+Servers SHOULD NOT use PING frames to keep a connection open.  A client SHOULD
+NOT use PING frames for this purpose unless there are no responses outstanding
+for requests or server pushes.  If the client is not expecting a response from
+the server, allowing an idle connection to time out (based on the idle_timeout
+transport parameter) is preferred over expending effort maintaining a connection
+that might not be needed.  A gateway MAY use PING to maintain connections in
+anticipation of need rather than incur the latency cost of connection
+establishment to servers.

Why does the 0-RTT argument not apply to gateways?  Why does the logic that applies to gateways not apply to clients?  I'd just generically say that letting the connection idle out is preferred, but you MAY keep a connection open if you think you'll need it again soon.

> @@ -1786,9 +1786,24 @@ than it has sent, unless this is a result of a change in the initial limits (see
 Endpoints can use PING frames (type=0x07) to verify that their peers are still
 alive or to check reachability to the peer. The PING frame contains no
 additional fields. The receiver of a PING frame simply needs to acknowledge the
-packet containing this frame. The PING frame SHOULD be used to keep a connection
-alive when a stream is open. The default is to send a PING frame after 15
-seconds of quiescence. A PING frame has no additional fields.
+packet containing this frame.
+
+A PING frame has no additional fields.
+
+The PING frame can be used to keep a connection alive when an application or
+application protocol wishes to avoid the connection from timing out.  An

Possible dialect difference:  "avoid ... from" doesn't sound right to me.  I'd have expected to see "keep ... from" or "prevent a connection time-out."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/744#pullrequestreview-57921897