Date: Thu, 24 Aug 2017 15:30:22 -0700
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab8a53e9fab68bfc0ca2a529278084334b66e3a3ea92cf0000000115b7157e92a169ce0edf94fd@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/c324774857@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_599f537e6664_1e53f3f8f6b64dc349836c";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/MCChfeRklV01nKoapn9qPNtViDQ>


----==_mimepart_599f537e6664_1e53f3f8f6b64dc349836c
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

If an endpoint receives an ACK for a CONNECTION_CLOSE, it still needs to handle more packets (it remains in its draining period) because of the chance that packets sent before the ACK are still in transit.  Thus, the shortcut isn't really that useful here.  Obviously the endpoint that acknowledges the CONNECTION_CLOSE won't send any more packets, but if its own packets are still in flight, then it might get a few more CONNECTION_CLOSE frames (as a result of packets sent before it acknowledged the CONNECTION_CLOSE). 

The only real trimming we might do is to have the endpoint that sends the CONNECTION_CLOSE stop sending more CONNECTION_CLOSE frames in response to receiving more packets.

-- 
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#issuecomment-324774857
----==_mimepart_599f537e6664_1e53f3f8f6b64dc349836c
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>If an endpoint receives an ACK for a CONNECTION_CLOSE, it still needs =
to handle more packets (it remains in its draining period) because of the=
 chance that packets sent before the ACK are still in transit.  Thus, the=
 shortcut isn't really that useful here.  Obviously the endpoint that ack=
nowledges the CONNECTION_CLOSE won't send any more packets, but if its ow=
n packets are still in flight, then it might get a few more CONNECTION_CL=
OSE frames (as a result of packets sent before it acknowledged the CONNEC=
TION_CLOSE).</p>
<p>The only real trimming we might do is to have the endpoint that sends =
the CONNECTION_CLOSE stop sending more CONNECTION_CLOSE frames in respons=
e to receiving more packets.</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/pull/721#issuecomment-324774857">view it on GitHub</a>, or=
 <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqxA_w4v=
CQjmBotaB2aPk_pPR24cAks5sbfl-gaJpZM4O0OWB">mute the thread</a>.<img alt=3D=
"" height=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq2q96f=
V_WqIyYwp9yPBZTzG1BuLrks5sbfl-gaJpZM4O0OWB.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewActi=
on">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/pu=
ll/721#issuecomment-324774857"></link>
  <meta itemprop=3D"name" content=3D"View Pull Request"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Pull Request on GitHu=
b"></meta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"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":"http=
s://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6=
-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubuserconte=
nt.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","=
action":{"name":"Open in GitHub","url":"https://github.com/quicwg/base-dr=
afts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@martinthomson=
 in #721: If an endpoint receives an ACK for a CONNECTION_CLOSE, it still=
 needs to handle more packets (it remains in its draining period) because=
 of the chance that packets sent before the ACK are still in transit.  Th=
us, the shortcut isn't really that useful here.  Obviously the endpoint t=
hat acknowledges the CONNECTION_CLOSE won't send any more packets, but if=
 its own packets are still in flight, then it might get a few more CONNEC=
TION_CLOSE frames (as a result of packets sent before it acknowledged the=
 CONNECTION_CLOSE). \r\n\r\nThe only real trimming we might do is to have=
 the endpoint that sends the CONNECTION_CLOSE stop sending more CONNECTIO=
N_CLOSE frames in response to receiving more packets."}],"action":{"name"=
:"View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/72=
1#issuecomment-324774857"}}}</script>=

----==_mimepart_599f537e6664_1e53f3f8f6b64dc349836c--