Subject: [quicwg/base-drafts] Make keep-alive advice more generic (#3745)

From: Martin Thomson <[email-masked]>
Date: Mon, 08 Jun 2020 23:44:33 -0700

This moves it up under the idle timeout section.  As discussed on the
issue, the HTTP draft is basically good.

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

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

-- Commit Summary --

  * Make keep-alive advice more generic

-- File Changes --

    M draft-ietf-quic-http.md (12)
    M draft-ietf-quic-transport.md (54)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3745.patch
https://github.com/quicwg/base-drafts/pull/3745.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/3745

---

From: Mike Bishop <[email-masked]>
Date: Tue, 09 Jun 2020 06:37:37 -0700

@MikeBishop approved this pull request.

On the whole, this is good.  Might be worth having something a little stronger than "might provide"; that would be normative, but the old text already hinted fairly strongly that this was a capability that needed to be exposed to applications.

>  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

```suggestion
idle timeout.  This facility could be used when the application wishes to
```

>  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

I don't have a good suggestion here, but this trips up a first reading by being ambiguous about whether it's the state or the loss which is associated with the connection.  Maybe "application wishes to avoid losing the state associated with an open connection"?  Or "application wishes to avoid the connection timing out, but..."?

-- 
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/3745#pullrequestreview-427146973

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 09 Jun 2020 07:21:48 -0700

@LPardue commented on this pull request.

> +idle timeout is appropriate.  Uncoordinated or unnecessary sending of PING
+frames could have a detrimental effect on performance.

I'm finding it a little difficult to understand what coordination means in this paragraph. Previously, the mention of coordination followed some specific advice that has been axed.

-- 
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/3745#pullrequestreview-427202493

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 09 Jun 2020 15:17:31 -0700

@janaiyengar pushed 1 commit.

71a41f772f34776e880ec4e3561f767d4aff9415  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3745/files/992a2d77df2e424ff0ff7e42cf71287965072f90..71a41f772f34776e880ec4e3561f767d4aff9415

---

From: Martin Thomson <[email-masked]>
Date: Tue, 09 Jun 2020 15:41:06 -0700

@martinthomson pushed 1 commit.

2471d098303acc21638b387b5535b4bfbccc7df9  Editorial tweaking

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3745/files/71a41f772f34776e880ec4e3561f767d4aff9415..2471d098303acc21638b387b5535b4bfbccc7df9

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 09 Jun 2020 15:41:32 -0700

@LPardue approved this pull request.

-- 
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/3745#pullrequestreview-427594441

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 09 Jun 2020 15:44:09 -0700

@janaiyengar approved this pull request.

-- 
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/3745#pullrequestreview-427595504

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 09 Jun 2020 15:44:45 -0700

Merged #3745 into master.

-- 
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/3745#event-3427110684