Date: Sun, 04 Jun 2017 00:01:59 -0700
From: Subodh Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab00a91130ad0a3e40e31f4d1963e137168ac7f0d392cf00000001154b726792a169ce0de9a623@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/571@github.com>
Subject: [quicwg/base-drafts] Transition to half closed local should probably
 happen on FIN ack (#571)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5933b0671c4ef_7a7f3fdceaaddc3c37321";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/i8r6_WYIZl4EkQonp161IqsRB64>

----==_mimepart_5933b0671c4ef_7a7f3fdceaaddc3c37321
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

in 10.2.2.=20
" An endpoint sending an FIN flag causes the stream state to become =E2=80=
=9Chalf-closed (local)=E2=80=9D. An endpoint receiving a FIN flag causes th=
e stream state to become =E2=80=9Chalf-closed (remote)=E2=80=9D once all pr=
eceding data has arrived"

this seems to suggest that a sender will transition to half closed immediat=
ely after sending a FIN. Is that intentional?=20

It seems that it would be better for the sender to transition to FIN only a=
fter getting the ACK otherwise you'd get into a case where:

Sender sends FIN -> transitions to half closed local
Receiver races with a RST -> sender has sent the FIN, so doesn't send a RST=
 stream is response
Sender transitions to closed
FIN gets lost

However now that the sender is in closed it might still have to retransmit =
the FIN. Making the sender wait on FIN ack to transition to half closed loc=
al seems better, that way if the FIN is not ACKed, the sender could just go=
 into half closed remote like normal when it gets the RST.

I like the idea of closed state being a terminal state where no additional =
work is needed from the sender.


--=20
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/issues/571=

----==_mimepart_5933b0671c4ef_7a7f3fdceaaddc3c37321
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>in 10.2.2.<br>
" An endpoint sending an FIN flag causes the stream state to become =E2=80=
=9Chalf-closed (local)=E2=80=9D. An endpoint receiving a FIN flag causes th=
e stream state to become =E2=80=9Chalf-closed (remote)=E2=80=9D once all pr=
eceding data has arrived"</p>
<p>this seems to suggest that a sender will transition to half closed immed=
iately after sending a FIN. Is that intentional?</p>
<p>It seems that it would be better for the sender to transition to FIN onl=
y after getting the ACK otherwise you'd get into a case where:</p>
<p>Sender sends FIN -&gt; transitions to half closed local<br>
Receiver races with a RST -&gt; sender has sent the FIN, so doesn't send a =
RST stream is response<br>
Sender transitions to closed<br>
FIN gets lost</p>
<p>However now that the sender is in closed it might still have to retransm=
it the FIN. Making the sender wait on FIN ack to transition to half closed =
local seems better, that way if the FIN is not ACKed, the sender could just=
 go into half closed remote like normal when it gets the RST.</p>
<p>I like the idea of closed state being a terminal state where no addition=
al work is needed from the sender.</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/issues/571">view it on GitHub</a>, or <a href=3D"https://github.co=
m/notifications/unsubscribe-auth/AWbkq0985klpFFxHnNPhut03gEwhJQeUks5sAlZnga=
JpZM4NvS61">mute the thread</a>.<img alt=3D"" height=3D"1" src=3D"https://g=
ithub.com/notifications/beacon/AWbkq8Yrbjf9uqYs-5khH-DOFSFWDVmBks5sAlZngaJp=
ZM4NvS61.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/issu=
es/571"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue 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":"DESCRIPTION","message":"Transition to half closed l=
ocal should probably happen on FIN ack (#571)"}],"action":{"name":"View Iss=
ue","url":"https://github.com/quicwg/base-drafts/issues/571"}}}</script>=

----==_mimepart_5933b0671c4ef_7a7f3fdceaaddc3c37321--