Date: Tue, 22 Aug 2017 21:55:35 +0000 (UTC)
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab9847cc4e4903680d797f4db8fb921bc2d8ffef1192cf0000000115b46a5692a169ce0f025d79@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/743/324162922@github.com>
In-Reply-To: <quicwg/base-drafts/issues/743@github.com>
References: <quicwg/base-drafts/issues/743@github.com>
Subject: Re: [quicwg/base-drafts] Stream closed state and acknowledgments
 (#743)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_599ca8562ec1c_3c7c3f8dae81bc3c5048e";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/LQv56AZW0o69LmEAAHvHfG9Udac>

----==_mimepart_599ca8562ec1c_3c7c3f8dae81bc3c5048e
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

Thinking modularly, I'd argue that it should happen when the frames are submitted for transmission; the stream state machine shouldn't be dependent on ACKs and retransmissions.  The receiver is necessarily going to lag a little bit due to those things, but the situation of there being a lag is not remedied by making the lagging party be the sender instead.  This also mirrors flow control, where the window is consumed as soon as the frames are submitted, even if they haven't been sent yet.

As you note, the reason we considered switching the lag was to make the sender more conservative about which streams are in which state to avoid accidentally violating max_concurrent_streams.  That's no longer an issue, since the receiver is the one controlling that now.

-- 
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/743#issuecomment-324162922
----==_mimepart_599ca8562ec1c_3c7c3f8dae81bc3c5048e
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Thinking modularly, I'd argue that it should happen when the frames are =
submitted for transmission; the stream state machine shouldn't be dependent=
 on ACKs and retransmissions.  The receiver is necessarily going to lag a l=
ittle bit due to those things, but the situation of there being a lag is no=
t remedied by making the lagging party be the sender instead.  This also mi=
rrors flow control, where the window is consumed as soon as the frames are =
submitted, even if they haven't been sent yet.</p>
<p>As you note, the reason we considered switching the lag was to make the =
sender more conservative about which streams are in which state to avoid ac=
cidentally violating max_concurrent_streams.  That's no longer an issue, si=
nce the receiver is the one controlling that now.</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/743#issuecomment-324162922">view it on GitHub</a>, or <a hr=
ef=3D"https://github.com/notifications/unsubscribe-auth/AWbkq9i_k_6-KB5ed-N=
toC893qA_oCH5ks5sa05WgaJpZM4O-AeX">mute the thread</a>.<img alt=3D"" height=
=3D"1" src=3D"https://github.com/notifications/beacon/AWbkq2pGk3v_qgHp37qlx=
C9jcJuikOfOks5sa05WgaJpZM4O-AeX.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/743#issuecomment-324162922"></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":"PERSON","message":"@MikeBishop in #743: Thinking mo=
dularly, I'd argue that it should happen when the frames are submitted for =
transmission; the stream state machine shouldn't be dependent on ACKs and r=
etransmissions.  The receiver is necessarily going to lag a little bit due =
to those things, but the situation of there being a lag is not remedied by =
making the lagging party be the sender instead.  This also mirrors flow con=
trol, where the window is consumed as soon as the frames are submitted, eve=
n if they haven't been sent yet.\r\n\r\nAs you note, the reason we consider=
ed switching the lag was to make the sender more conservative about which s=
treams are in which state to avoid accidentally violating max_concurrent_st=
reams.  That's no longer an issue, since the receiver is the one controllin=
g that now."}],"action":{"name":"View Issue","url":"https://github.com/quic=
wg/base-drafts/issues/743#issuecomment-324162922"}}}</script>=

----==_mimepart_599ca8562ec1c_3c7c3f8dae81bc3c5048e--