Date: Wed, 23 Aug 2017 04:21:42 +0000 (UTC)
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab7cdbf41fbb88b3733b0e3a8c51bf53827fa39dda92cf0000000115b4c4d592a169ce0edf94fd@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/c324217020@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_599d02d5f13d9_478e3fd509ea3c3895f3";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/RfVphzz0wJdJeztBjbtCXlDfd58>

----==_mimepart_599d02d5f13d9_478e3fd509ea3c3895f3
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

I've introduced the notion of a "draining period" after close.  This is like the TCP TIME_WAIT period, but what happens depends on how the connection was closed.  On Jana's advice, I've used 3*max(MIN_RTO, RTT), recognizing that this is probably just a starting point and we can refine the exact value later.

During the draining period, the baseline here is that the endpoint generates ACK frames, but nothing else.  That's all we need for an application close (the success case).  For an idle timeout, the text permits reviving of the connection if new packets are received.  In immediate close, the text requires that the CONNECTION_CLOSE be sent, and permits re-sending the last packet to save on state space.

@janaiyengar, can you check to see that I've captured the intent well-enough here?

-- 
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-324217020
----==_mimepart_599d02d5f13d9_478e3fd509ea3c3895f3
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>I've introduced the notion of a "draining period" after close.  This is =
like the TCP TIME_WAIT period, but what happens depends on how the connecti=
on was closed.  On Jana's advice, I've used 3*max(MIN_RTO, RTT), recognizin=
g that this is probably just a starting point and we can refine the exact v=
alue later.</p>
<p>During the draining period, the baseline here is that the endpoint gener=
ates ACK frames, but nothing else.  That's all we need for an application c=
lose (the success case).  For an idle timeout, the text permits reviving of=
 the connection if new packets are received.  In immediate close, the text =
requires that the CONNECTION_CLOSE be sent, and permits re-sending the last=
 packet to save on state space.</p>
<p><a href=3D"https://github.com/janaiyengar" class=3D"user-mention">@janai=
yengar</a>, can you check to see that I've captured the intent well-enough =
here?</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&mda=
sh;<br />You are receiving this because you are subscribed to this thread.<=
br />Reply to this email directly, <a href=3D"https://github.com/quicwg/bas=
e-drafts/pull/721#issuecomment-324217020">view it on GitHub</a>, or <a href=
=3D"https://github.com/notifications/unsubscribe-auth/AWbkq7E-WfpMY--ZgDXcy=
OIqbEOzniszks5sa6jVgaJpZM4O0OWB">mute the thread</a>.<img alt=3D"" height=
=3D"1" src=3D"https://github.com/notifications/beacon/AWbkqxtat6Bi3dlMJHzjv=
PVsHeGCPQ-gks5sa6jVgaJpZM4O0OWB.gif" width=3D"1" /></p>
<div itemscope itemtype=3D"http://schema.org/EmailMessage">
<div itemprop=3D"action" itemscope itemtype=3D"http://schema.org/ViewAction=
">
  <link itemprop=3D"url" href=3D"https://github.com/quicwg/base-drafts/pull=
/721#issuecomment-324217020"></link>
  <meta itemprop=3D"name" content=3D"View Pull Request"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Pull Request on GitHub"=
></meta>
</div>

<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_version"=
:"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"Gi=
tHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"quicwg=
/base-drafts","subtitle":"GitHub repository","main_image_url":"https://clou=
d.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290=
892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/asset=
s/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":"@martinthomson in #721: I've int=
roduced the notion of a \"draining period\" after close.  This is like the =
TCP TIME_WAIT period, but what happens depends on how the connection was cl=
osed.  On Jana's advice, I've used 3*max(MIN_RTO, RTT), recognizing that th=
is is probably just a starting point and we can refine the exact value late=
r.\r\n\r\nDuring the draining period, the baseline here is that the endpoin=
t generates ACK frames, but nothing else.  That's all we need for an applic=
ation close (the success case).  For an idle timeout, the text permits revi=
ving of the connection if new packets are received.  In immediate close, th=
e text requires that the CONNECTION_CLOSE be sent, and permits re-sending t=
he last packet to save on state space.\r\n\r\n@janaiyengar, can you check t=
o see that I've captured the intent well-enough here?"}],"action":{"name":"=
View Pull Request","url":"https://github.com/quicwg/base-drafts/pull/721#is=
suecomment-324217020"}}}</script>=

----==_mimepart_599d02d5f13d9_478e3fd509ea3c3895f3--