Date: Wed, 23 Aug 2017 06:36:00 -0700
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab7770771609b2b6b328d939ac4d44f4144c45097592cf0000000115b546c092a169ce0edf94fd@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/721/review/58080446@github.com>
In-Reply-To: <quicwg/base-drafts/pull/721@github.com>
References: <quicwg/base-drafts/pull/721@github.com>
Subject: Re: [quicwg/base-drafts] Refactor the section on connection
 termination (#721)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_599d84c095d76_1b8143fb9da6afc38158696";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/pMnAezTABhv13sJmsqQup5CAL7s>


----==_mimepart_599d84c095d76_1b8143fb9da6afc38158696
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

nibanks commented on this pull request.



> +connection state if they have neither sent nor received a packet for this time.
+
+The time at which an idle timeout takes effect won't be perfectly synchronized
+on peers.  A connection enters the draining period when the idle timeout
+expires.  During this time, an endpoint that receives new packets MAY choose to
+restore the connection.  Alternatively, an endpoint that receives packets MAY
+signal the timeout using an immediate close.
+
+
+### Immediate Close
+
+An endpoint sends a CONNECTION_CLOSE frame to terminate the connection
+immediately.  A CONNECTION_CLOSE causes all open streams to immediately become
+closed; open streams can be assumed to be implicitly reset.  After receiving a
+CONNECTION_CLOSE frame, endpoints MUST NOT send additional packets on that
+connection.

What would be the harm in allowing the endpoint to ACK a CONNECTION_CLOSE frame/packet? It would allow for the side that initiated the close to safely, immediately end its draining period. The ACK wouldn't be required, but a useful signal if used.

-- 
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/721#pullrequestreview-58080446
----==_mimepart_599d84c095d76_1b8143fb9da6afc38158696
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><b>@nibanks</b> commented on this pull request.</p>

<hr>

<p>In <a href="https://github.com/quicwg/base-drafts/pull/721#discussion_r134752472">draft-ietf-quic-transport.md</a>:</p>
<pre style='color:#555'>&gt; +connection state if they have neither sent nor received a packet for this time.
+
+The time at which an idle timeout takes effect won&#39;t be perfectly synchronized
+on peers.  A connection enters the draining period when the idle timeout
+expires.  During this time, an endpoint that receives new packets MAY choose to
+restore the connection.  Alternatively, an endpoint that receives packets MAY
+signal the timeout using an immediate close.
+
+
+### Immediate Close
+
+An endpoint sends a CONNECTION_CLOSE frame to terminate the connection
+immediately.  A CONNECTION_CLOSE causes all open streams to immediately become
+closed; open streams can be assumed to be implicitly reset.  After receiving a
+CONNECTION_CLOSE frame, endpoints MUST NOT send additional packets on that
+connection.
</pre>
<p>What would be the harm in allowing the endpoint to ACK a CONNECTION_CLOSE frame/packet? It would allow for the side that initiated the close to safely, immediately end its draining period. The ACK wouldn't be required, but a useful signal if used.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/pull/721#pullrequestreview-58080446">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AWbkq9C7fIP6Gms-yVQbcRNc1Hl3php6ks5sbCrAgaJpZM4O0OWB">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AWbkq5uejjVXTo6kVsl1IZ-7A9C_H3KOks5sbCrAgaJpZM4O0OWB.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/quicwg/base-drafts/pull/721#pullrequestreview-58080446"></link>
  <meta itemprop="name" content="View Pull Request"></meta>
</div>
<meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@nibanks commented on #721"}],"action":{"name":"View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/721#pullrequestreview-58080446"}}}</script>
----==_mimepart_599d84c095d76_1b8143fb9da6afc38158696--