Date: Sat, 12 Jan 2019 01:59:47 -0800
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab412a5b473b50d944065a8b4d5de995d0c4833e7592cf0000000118517c9392a169ce17c1011d@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2331/453734970@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2331@github.com>
References: <quicwg/base-drafts/issues/2331@github.com>
Subject: Re: [quicwg/base-drafts] What should the receiver do when the peer
 closes a unidirectional stream before providing the stream type? (#2331)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c39ba938dd3_5f713fa8fc2d45bc61168";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/nxZIwQDbreOzNHUlFz1WKkc4tF4>


----==_mimepart_5c39ba938dd3_5f713fa8fc2d45bc61168
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

(It's now RESET_STREAM)

You can close normally (FIN), or with RESET_STREAM. In both cases there is a final size. The difference is that RESET_STREAM does not require unsent or lost data to be (re)transmitted. (I'm sure you are aware of all this).

If you get a RESET_STREAM and you do not have the stream type, there is no point in waiting for it. If you get a FIN without a type and a final size >= 1 but have not received the first byte, you can choose to wait for it. You probably should - but an implementation could make a mistake here assuming an error if an internal struct says type = type_missing. I take it you issue is intended for RESET only, but you were not clear on that.

Now, further analysis:
Assume you send a non critical stream with a type, and some other data. Then decide to RESET_STREAM in a later packet. This later packet overtakes the previous packet holding the type. Since the receiver cannot assume that the type was ever sent or will ever be received, it must act on what it knows. Hence, if it treats this as a critical error, streams can never be reset. Consequently, either streams should never be reset, or a reset without a type should not be treated as critical. I.e. a stream only exists for real once a type is positively known.

-- 
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/2331#issuecomment-453734970
----==_mimepart_5c39ba938dd3_5f713fa8fc2d45bc61168
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>(It's now RESET_STREAM)</p>
<p>You can close normally (FIN), or with RESET_STREAM. In both cases ther=
e is a final size. The difference is that RESET_STREAM does not require u=
nsent or lost data to be (re)transmitted. (I'm sure you are aware of all =
this).</p>
<p>If you get a RESET_STREAM and you do not have the stream type, there i=
s no point in waiting for it. If you get a FIN without a type and a final=
 size &gt;=3D 1 but have not received the first byte, you can choose to w=
ait for it. You probably should - but an implementation could make a mist=
ake here assuming an error if an internal struct says type =3D type_missi=
ng. I take it you issue is intended for RESET only, but you were not clea=
r on that.</p>
<p>Now, further analysis:<br>
Assume you send a non critical stream with a type, and some other data. T=
hen decide to RESET_STREAM in a later packet. This later packet overtakes=
 the previous packet holding the type. Since the receiver cannot assume t=
hat the type was ever sent or will ever be received, it must act on what =
it knows. Hence, if it treats this as a critical error, streams can never=
 be reset. Consequently, either streams should never be reset, or a reset=
 without a type should not be treated as critical. I.e. a stream only exi=
sts for real once a type is positively known.</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/2331#issuecomment-453734970">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq2od=
sG0rseV1Ew0fMiVxo-qVnO6mks5vCbITgaJpZM4Z8gYm">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkq-kIFwdUqIfcobUT0ei5-274=
6T4Sks5vCbITgaJpZM4Z8gYm.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<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://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
mikkelfj in #2331: (It's now RESET_STREAM)\r\n\r\nYou can close normally =
(FIN), or with RESET_STREAM. In both cases there is a final size. The dif=
ference is that RESET_STREAM does not require unsent or lost data to be (=
re)transmitted. (I'm sure you are aware of all this).\r\n\r\nIf you get a=
 RESET_STREAM and you do not have the stream type, there is no point in w=
aiting for it. If you get a FIN without a type and a final size \u003e=3D=
 1 but have not received the first byte, you can choose to wait for it. Y=
ou probably should - but an implementation could make a mistake here assu=
ming an error if an internal struct says type =3D type_missing. I take it=
 you issue is intended for RESET only, but you were not clear on that.\r\=
n\r\nNow, further analysis:\r\nAssume you send a non critical stream with=
 a type, and some other data. Then decide to RESET_STREAM in a later pack=
et. This later packet overtakes the previous packet holding the type. Sin=
ce the receiver cannot assume that the type was ever sent or will ever be=
 received, it must act on what it knows. Hence, if it treats this as a cr=
itical error, streams can never be reset. Consequently, either streams sh=
ould never be reset, or a reset without a type should not be treated as c=
ritical. I.e. a stream only exists for real once a type is positively kno=
wn."}],"action":{"name":"View Issue","url":"https://github.com/quicwg/bas=
e-drafts/issues/2331#issuecomment-453734970"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2331#issuecomment=
-453734970",
"url": "https://github.com/quicwg/base-drafts/issues/2331#issuecomment-45=
3734970",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c39ba938dd3_5f713fa8fc2d45bc61168--