Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 5417A130F97
 for <quic-issues@ietfa.amsl.com>; Tue,  8 Jan 2019 11:06:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.064
X-Spam-Level: 
X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001,
 HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key)
 header.d=github.com
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id ftoOfvMVGvDF for <quic-issues@ietfa.amsl.com>;
 Tue,  8 Jan 2019 11:06:19 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 9703E130F85
 for <quic-issues@ietf.org>; Tue,  8 Jan 2019 11:06:19 -0800 (PST)
Date: Tue, 08 Jan 2019 11:06:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com;
 s=pf2014; t=1546974378;
 bh=WLkw5LmE3PZ9KyaZlECDHR3G4sHE5ItRBURWQcdMm1A=;
 h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID:
 List-Archive:List-Post:List-Unsubscribe:From;
 b=n9eVpshUCR44D/NzvG7KNlM2i/FtYsbqOwQvbt5tv4RLanN6QfNM7V0AKpoo5h3z9
 y8P0OOu39tu6DEwmZfLxCDIBuWjFSaW+xVT3nQ6ZntqOtER9fMjHqBgXpFXwQY2kHw
 hiCjo40XUi8kz0iEwcI8uUXmGeaJ9d7Ex/kvJYaE=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab190849e4a4abe3f6fd940e24d9ebeec4a971cc9b92cf00000001184cb6aa92a169ce17856d43@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2268/c452415035@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2268@github.com>
References: <quicwg/base-drafts/pull/2268@github.com>
Subject: Re: [quicwg/base-drafts] only require RESET_STREAM on STOP_SENDING in
 Ready and Sent state (#2268)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c34f4aa2e92a_7b063fab472d45c41977db";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/5SnZnYkvkV7bIHlv_wI__YvVxUE>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG
 <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>,
 <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 19:06:21 -0000


----==_mimepart_5c34f4aa2e92a_7b063fab472d45c41977db
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

Receiving a FIN isn't enough to complete the state machine, though some implementations might short-circuit it when sending a STOP_SENDING.  The reliability machinery expects to send all data declared lost unless there's a RESET_STREAM.  I think the language needs to be something like:

> ...MUST send a RESET_STREAM frame if the stream is in the Ready or Send state.  If the stream is in the Data Sent state and any outstanding data is declared lost, an endpoint SHOULD send a RESET_STREAM frame in lieu of a retransmission.

(This effectively makes a new side state from Data Sent where you're waiting to decide if you need to send a RESET_STREAM.)

-- 
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/2268#issuecomment-452415035
----==_mimepart_5c34f4aa2e92a_7b063fab472d45c41977db
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Receiving a FIN isn't enough to complete the state machine, though som=
e implementations might short-circuit it when sending a STOP_SENDING.  Th=
e reliability machinery expects to send all data declared lost unless the=
re's a RESET_STREAM.  I think the language needs to be something like:</p=
>
<blockquote>
<p>...MUST send a RESET_STREAM frame if the stream is in the Ready or Sen=
d state.  If the stream is in the Data Sent state and any outstanding dat=
a is declared lost, an endpoint SHOULD send a RESET_STREAM frame in lieu =
of a retransmission.</p>
</blockquote>
<p>(This effectively makes a new side state from Data Sent where you're w=
aiting to decide if you need to send a RESET_STREAM.)</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/pull/2268#issuecomment-452415035">view it on GitHub</a>, o=
r <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkq7lhL6=
edm0qKCHaMulM6l9GSD4nBks5vBOwqgaJpZM4Zjx3_">mute the thread</a>.<img src=3D=
"https://github.com/notifications/beacon/AWbkq19Pv0oXgz-xU9JUGoJGT3e-ATyn=
ks5vBOwqgaJpZM4Zjx3_.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":"@=
MikeBishop in #2268: Receiving a FIN isn't enough to complete the state m=
achine, though some implementations might short-circuit it when sending a=
 STOP_SENDING.  The reliability machinery expects to send all data declar=
ed lost unless there's a RESET_STREAM.  I think the language needs to be =
something like:\r\n\r\n\u003e ...MUST send a RESET_STREAM frame if the st=
ream is in the Ready or Send state.  If the stream is in the Data Sent st=
ate and any outstanding data is declared lost, an endpoint SHOULD send a =
RESET_STREAM frame in lieu of a retransmission.\r\n\r\n(This effectively =
makes a new side state from Data Sent where you're waiting to decide if y=
ou need to send a RESET_STREAM.)"}],"action":{"name":"View Pull Request",=
"url":"https://github.com/quicwg/base-drafts/pull/2268#issuecomment-45241=
5035"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/pull/2268#issuecomment-4=
52415035",
"url": "https://github.com/quicwg/base-drafts/pull/2268#issuecomment-4524=
15035",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c34f4aa2e92a_7b063fab472d45c41977db--

