Subject: [quicwg/base-drafts] Specify RST-like behavior for CONNECTION_CLOSE. Fixes #330, #328 (#705)

From: ekr <[email-masked]>
Date: Thu, 27 Jul 2017 14:50:54 +0000 (UTC)

You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Specify RST-like behavior for CONNECTION_CLOSE. Fixes #330, #328

-- File Changes --

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

-- Patch Links --

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

---

From: ianswett <[email-masked]>
Date: Thu, 27 Jul 2017 07:57:28 -0700

ianswett approved this pull request.

Thanks, looks good to me.

-- 
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/705#pullrequestreview-52683499

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 27 Jul 2017 15:04:38 +0000 (UTC)

lgtm, maybe could use some guidance on how exactly the server could implement such a mechanism, however we can always add that later once we have more implementation experience.

-- 
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/705#issuecomment-318389845

---

From: MikkelFJ <[email-masked]>
Date: Thu, 27 Jul 2017 08:43:44 -0700

This is not entirely clear to me. If there is a requirement for backing off, but not requirement for replying to a connection close (is there?), then state will just be tied up for no good reason. If you have 100K connections per minute, and you need to hold a connection for 10 minutes to make sure you can back off, well ...

-- 
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/705#issuecomment-318401669

---

From: ekr <[email-masked]>
Date: Thu, 27 Jul 2017 08:49:00 -0700

See my email on this topic to the list where I lay out the tradeoffs.

-- 
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/705#issuecomment-318403249

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Jul 2017 16:15:05 -0700

martinthomson approved this pull request.

> @@ -1469,9 +1469,17 @@ of three ways:
    should send a Public Reset packet in return.  (TODO: articulate rules around
    when a public reset should be sent.)
 
-TODO: Connections that are terminated are added to a TIME_WAIT list at the
-server, so as to absorb any straggler packets in the network.  Discuss TIME_WAIT
-list.
+After receiving either a CONNECTION_CLOSE frame or a Public Reset, an
+endpoint MUST NOT send additional packets on that connection. After
+sending either a CONNECTION_CLOSE frame or a Public Reset packet,
+implementations MUST NOT send any non-closing packets on that connection. If
+additional packets are received after this time, implementations
+SHOULD respond to them by sending either a CONNECTION_CLOSE frame or a
+Public Reset packet, either of which may just be a duplicate of a

I recommend that you use CONNECTION_CLOSE here and instead note that an endpoint MAY send a Public Reset instead if it doesn't want to save the state necessary to generate CONNECTION_CLOSE.

There's a sliding scale here:

1. maintain full state and generate a new CONNECTION_CLOSE in a new packet
2. only keep the packet that holds CONNECTION_CLOSE and retransmit that unmodified
3. drop state and rely on Public/Stateless Reset

> @@ -1469,9 +1469,17 @@ of three ways:
    should send a Public Reset packet in return.  (TODO: articulate rules around
    when a public reset should be sent.)
 
-TODO: Connections that are terminated are added to a TIME_WAIT list at the
-server, so as to absorb any straggler packets in the network.  Discuss TIME_WAIT
-list.
+After receiving either a CONNECTION_CLOSE frame or a Public Reset, an
+endpoint MUST NOT send additional packets on that connection. After
+sending either a CONNECTION_CLOSE frame or a Public Reset packet,
+implementations MUST NOT send any non-closing packets on that connection. If
+additional packets are received after this time, implementations
+SHOULD respond to them by sending either a CONNECTION_CLOSE frame or a
+Public Reset packet, either of which may just be a duplicate of a
+previous packet. Implementations SHOULD throttle these responses, for
+instance by exponentially backing off the number of packets which must
+be received before sending a response.

s/must be/are

-- 
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/705#pullrequestreview-52810129

---

From: ekr <[email-masked]>
Date: Thu, 27 Jul 2017 16:16:22 -0700

ekr commented on this pull request.

I'm happy to revise this if that's the consensus. I was trying to be flexible.

-- 
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/705#discussion_r129981530

---

From: ianswett <[email-masked]>
Date: Thu, 27 Jul 2017 23:18:55 +0000 (UTC)

ianswett commented on this pull request.

I agree that 2 and 3 are a sliding scale and that's why SHOULD makes sense to me.  I haven't come up with any reasons why option 1 is preferable to 2, so I would not suggest it, but maybe there are some reasons I haven't come up with?

-- 
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/705#discussion_r129981855

---

From: janaiyengar <[email-masked]>
Date: Fri, 28 Jul 2017 00:43:10 +0000 (UTC)

janaiyengar commented on this pull request.

I agree with Ian that we don't need the endpoint to maintain complete state, so 2 and 3 make sense. I'd suggest that we add a suggestion about how long a peer resends CONNECTION_CLOSE after sending it once (basically how long state should be kept in option (2)), and I propose idle_timeout as a time period that makes sense.

-- 
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/705#discussion_r129991532

---

From: janaiyengar <[email-masked]>
Date: Thu, 27 Jul 2017 17:44:05 -0700

lgtm. I have a non-blocking suggestion in my inline comment.

-- 
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/705#issuecomment-318525129

---

From: janaiyengar <[email-masked]>
Date: Fri, 28 Jul 2017 00:44:17 +0000 (UTC)

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/705#pullrequestreview-52821780

---

From: Martin Thomson <[email-masked]>
Date: Thu, 27 Jul 2017 18:04:55 -0700

martinthomson commented on this pull request.

I think that we should allow all three, though gently discourage 3.

-- 
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/705#discussion_r129993709

---

From: ekr <[email-masked]>
Date: Fri, 28 Jul 2017 13:52:07 -0700

@ekr pushed 1 commit.

d38552f  Provide stronger guidance

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/705/files/035573cff2e813bbb61a1451c767f42110fbffc0..d38552f0bb63617557dce9db4c694bf3979323a8

---

From: ekr <[email-masked]>
Date: Fri, 28 Jul 2017 20:52:32 +0000 (UTC)

@ekr pushed 1 commit.

ee069a3  Wording

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/705/files/d38552f0bb63617557dce9db4c694bf3979323a8..ee069a3e771aa2a8aac387438a3f93fb25b77a94

---

From: ekr <[email-masked]>
Date: Fri, 28 Jul 2017 20:52:37 +0000 (UTC)

How's this look?

-- 
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/705#issuecomment-318759161

---

From: janaiyengar <[email-masked]>
Date: Fri, 28 Jul 2017 21:12:31 +0000 (UTC)

Whats the argument for allowing 1? 

-- 
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/705#discussion_r130187352

---

From: janaiyengar <[email-masked]>
Date: Fri, 28 Jul 2017 14:14:11 -0700

LGTM. Not a major issue, but the line breaks are at odd places. If you are able to, please format them to 80 cols.

-- 
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/705#issuecomment-318763468

---

From: ekr <[email-masked]>
Date: Fri, 28 Jul 2017 21:15:55 +0000 (UTC)

@ekr pushed 1 commit.

ac9a77a  Reformat

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/705/files/ee069a3e771aa2a8aac387438a3f93fb25b77a94..ac9a77afa7cbdfbe481da9540344971e177bbc93

---

From: janaiyengar <[email-masked]>
Date: Fri, 28 Jul 2017 21:36:07 +0000 (UTC)

I'd like to merge this. martinthomson@, if you think we should make the text more accommodating, let's do that separately.

-- 
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/705#issuecomment-318767472

---

From: janaiyengar <[email-masked]>
Date: Fri, 28 Jul 2017 14:48:22 -0700

Merged #705.

-- 
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/705#event-1184236459