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

From: Martin Thomson <[email-masked]>
Date: Tue, 22 Aug 2017 04:56:20 +0000 (UTC)

This removes the bad advice in PING about keeping connections alive and goes
for a more nuanced description.  The transport contains generic advice and a
recommendation that application protocols provide further guidance.  The HTTP
mapping specifies that the client is the one that performs keep-alives and that
it should only do so if it is waiting on responses from the server.

Closes #729.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/744

-- Commit Summary --

  * Keep-alive requirements

-- File Changes --

    M draft-ietf-quic-http.md (16)
    M draft-ietf-quic-transport.md (21)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/744.patch
https://github.com/quicwg/base-drafts/pull/744.diff

-- 
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

---

From: Nick Banks <[email-masked]>
Date: Tue, 22 Aug 2017 13:23:09 +0000 (UTC)

nibanks commented on this pull request.

> -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
+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 cause excessive number of
+packets and poor performance.
+
+A connection will time out if no packets are for a period longer than the time

I believe you meant to say something like `if no packets are sent or received for a period longer` or `if there are no packets for a period longer`.

-- 
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-57773325

---

From: Mike Bishop <[email-masked]>
Date: Tue, 22 Aug 2017 14:50:49 -0700

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Aug 2017 00:20:31 +0000 (UTC)

martinthomson commented on this pull request.

Whoops :)

-- 
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#discussion_r134632068

---

From: Martin Thomson <[email-masked]>
Date: Wed, 23 Aug 2017 00:24:35 +0000 (UTC)

@martinthomson pushed 1 commit.

6787231  Correct some pretty lame snafus

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/744/files/88080a484730da13f47d7e86579b3a80629b2588..678723180fb10d69c040dd60ef41d5f579dd3088

---

From: Martin Thomson <[email-masked]>
Date: Wed, 30 Aug 2017 01:35:14 +0000 (UTC)

Ugh, some old replies that got held up.  Damn this slow 'net.

+# Connection Management
+

Yes, operator error on my part.

+# Connection Management
+

0-RTT has the risk of replay.  You can't just use 0-RTT.  Having warm connections available at a gateway seems like a reasonable strategy to avoid problems with setup.  Also, you might want to avoid slow start in the case that you need to shove multiple requests down that pipe when many new clients arrive with 0-RTT requests.

-- 
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-57946121