Date: Thu, 02 Mar 2017 09:58:54 -0800
From: martinduke <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/353/283729446@github.com>
In-Reply-To: <quicwg/base-drafts/issues/353@github.com>
References: <quicwg/base-drafts/issues/353@github.com>
Subject: Re: [quicwg/base-drafts] Replace CONNECTION_CLOSE with Public Reset
 (#353)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_58b85d5e71b1d_73253fac1e151c381686b9";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Sclb0s2dZ8lI6eBkVIgCuLlB7ew>
Cc: Subscribed <subscribed@noreply.github.com>
Reply-To: quic@ietf.org


----==_mimepart_58b85d5e71b1d_73253fac1e151c381686b9
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

(1) and (2): If we decide to eliminate PUBLIC_RESET, then that obviously has implications here. I had detected any sentiment for this to date.

(3) I agree that network signaling is the other use case, but in the opposite direction you described. It is a signal from an endpoint to a stateful middlebox that there are no further packets coming on this connection ID.

As for your use case, this is the first I've heard of the response to a PUBLIC_RESET being "I'll try the same connection ID on a different path". That is an entirely different purpose than what has been described to date. In fact, I believe the consensus is to _not_ allow middleboxes to generate authentic resets.

-- 
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/353#issuecomment-283729446
----==_mimepart_58b85d5e71b1d_73253fac1e151c381686b9
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>(1) and (2): If we decide to eliminate PUBLIC_RESET, then that obvious=
ly has implications here. I had detected any sentiment for this to date.<=
/p>
<p>(3) I agree that network signaling is the other use case, but in the o=
pposite direction you described. It is a signal from an endpoint to a sta=
teful middlebox that there are no further packets coming on this connecti=
on ID.</p>
<p>As for your use case, this is the first I've heard of the response to =
a PUBLIC_RESET being "I'll try the same connection ID on a different path=
". That is an entirely different purpose than what has been described to =
date. In fact, I believe the consensus is to <em>not</em> allow middlebox=
es to generate authentic resets.</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/issues/353#issuecomment-283729446">view it on GitHub</a>, =
or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq1_5g=
-ALI4f6i0MyXxhfTsJ2B6Ztks5rhwNegaJpZM4MQZqy">mute the thread</a>.<img alt=
=3D"" height=3D"1" src=3D"https://github.com/notifications/beacon/AWbkqyk=
gbQQkk5m3WZ4Q54uRddxQDSTCks5rhwNegaJpZM4MQZqy.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/is=
sues/353#issuecomment-283729446"></link>
  <meta itemprop=3D"name" content=3D"View Issue"></meta>
</div>
<meta itemprop=3D"description" content=3D"View this Issue on GitHub"></me=
ta>
</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":"@martinduke in=
 #353: (1) and (2): If we decide to eliminate PUBLIC_RESET, then that obv=
iously has implications here. I had detected any sentiment for this to da=
te.\r\n\r\n(3) I agree that network signaling is the other use case, but =
in the opposite direction you described. It is a signal from an endpoint =
to a stateful middlebox that there are no further packets coming on this =
connection ID.\r\n\r\nAs for your use case, this is the first I've heard =
of the response to a PUBLIC_RESET being \"I'll try the same connection ID=
 on a different path\". That is an entirely different purpose than what h=
as been described to date. In fact, I believe the consensus is to _not_ a=
llow middleboxes to generate authentic resets."}],"action":{"name":"View =
Issue","url":"https://github.com/quicwg/base-drafts/issues/353#issuecomme=
nt-283729446"}}}</script>=

----==_mimepart_58b85d5e71b1d_73253fac1e151c381686b9--