Re: [quicwg/base-drafts] Remap STOPPING to something other than zero (#1804)

Nick Banks <notifications@github.com> Thu, 27 September 2018 19:02 UTC

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 8C816130F1D for <quic-issues@ietfa.amsl.com>; Thu, 27 Sep 2018 12:02:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.455
X-Spam-Level:
X-Spam-Status: No, score=-8.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 roHCvpdY14pv for <quic-issues@ietfa.amsl.com>; Thu, 27 Sep 2018 12:02:55 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6268130F34 for <quic-issues@ietf.org>; Thu, 27 Sep 2018 12:02:54 -0700 (PDT)
Date: Thu, 27 Sep 2018 12:02:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538074973; bh=05zSHaikaKHkuQuCZpwjzQtUN5uuspIW5O0a70PwY80=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QNv0y+sj5kbWwsD2TZok51mmtS6zCYoNH+ngH9Mwoc1tkFFcI6Ve6gL1GGnUNkBsX Q2a4s8KPypImqLLKN3K1u/BQkgRNsmzU4uQjt0F5e8U3ZZVDlHx3Etti8e0KVhEMEC lJvxnn6IucI1weqPF+UtH0gwSN99DbFzvXNwgeC0=
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab77c4a850d62c8bb6c3aec6c3cfffcf586ef3f8ab92cf0000000117c4eb5d92a169ce15b0cecf@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1804/425207032@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1804@github.com>
References: <quicwg/base-drafts/issues/1804@github.com>
Subject: Re: [quicwg/base-drafts] Remap STOPPING to something other than zero (#1804)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bad295db79dd_2ba33feb728d45bc34576"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: nibanks
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/NaZhEwI8-zlm1UEIVc0Lf7ByxSc>
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: Thu, 27 Sep 2018 19:02:57 -0000

I'm imagining the logic for this stuff something like this:
```
recv_stop_sending():
	if (already_sent_rst_stream())
		do_nothing()
	else
		indicate_stop_sending_to_app()
		send_rst_stream(STOPPING)
		
recv_rst_stream():
	if (already_sent_stop_sending())
		do_nothing()
	else
		indicate_abortive_shutdown_to_app()
```
The way I see it, when you have sent a STOP_SENDING, you really don't care how the peer closes/resets the stream as long as it does and stops sending. No matter what, you wouldn't indicate it up to the app layer. Requiring the use of an explicit STOPPING error code still seems pointless to me. If you are worried about differentiating and indicating up that the peer reset their stream right **after** you told them to stop, I don't see the point. It's going to be a race condition. Simplest just to follow the logic above.

-- 
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/1804#issuecomment-425207032