IETF Logo Mail Archive

Re: [quicwg/base-drafts] Allow the Transport to Stop/Reset a Stream? (#3291)

Martin Thomson <notifications@github.com> Fri, 13 December 2019 01:32 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 0F24D120145 for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 17:32:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 hMeBbFFzOLDi for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 17:32:19 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C2E1200FB for <quic-issues@ietf.org>; Thu, 12 Dec 2019 17:32:19 -0800 (PST)
Received: from github-lowworker-5825cd4.ac4-iad.github.net (github-lowworker-5825cd4.ac4-iad.github.net [10.52.22.68]) by smtp.github.com (Postfix) with ESMTP id B642B8C0854 for <quic-issues@ietf.org>; Thu, 12 Dec 2019 17:32:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576200736; bh=oMR0rkMskllnf/CudidtIm93jc99dxuNDlHOL9mFtuA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w1PIXloAIjnjE7pSobeJUMfrMfPM+lkiPR/lhsfeVGEv4hIHEB11z+jTJu0amSRHN 8jEVcoMTvphr8NNCR5mU7hU76hFGqLN+wbShVy4TG3coa29IPyUNP60EdUjCK1VX+K 1tz9InJooPQouD9Vq4WL7mgP0IPY3TkNF1t2rKkc=
Date: Thu, 12 Dec 2019 17:32:16 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4C2YPAUF6HLV5AQTN4AAOKBEVBNHHB7WKXVY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3291/565262144@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3291@github.com>
References: <quicwg/base-drafts/issues/3291@github.com>
Subject: Re: [quicwg/base-drafts] Allow the Transport to Stop/Reset a Stream? (#3291)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df2ea20a5793_5b453ff91c6cd964109039"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/E_EkCEa_8loZwrw7Eb-z-6P5R5c>
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: Fri, 13 Dec 2019 01:32:21 -0000

I will observe that the garbage-collected stream object can a) do nothing and leave the stream hanging, b) close the stream, or c) call on some help to decide what to use with RESET_STREAM or STOP_SENDING or both.  I think that (a) is likely the default.  The local implementation drops state and carries on.  The other side might be left hanging, but that is - as much as anything else - the only clear bit of application intent you might infer from what happened.

Now, if you want to ensure that the problem is noticed and acted upon, local signals might be the next step.  But if the other side needs to know, then terminating the connection will get the problem noticed.

-- 
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/3291#issuecomment-565262144

v2.29.0 | Report a Bug | By Email | System Status