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

Nick Banks <notifications@github.com> Sat, 07 December 2019 01:54 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 41208120044 for <quic-issues@ietfa.amsl.com>; Fri, 6 Dec 2019 17:54:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_28=1.404, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0HCyvN8y1Vq8 for <quic-issues@ietfa.amsl.com>; Fri, 6 Dec 2019 17:54:29 -0800 (PST)
Received: from out-21.smtp.github.com (out-21.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75229120033 for <quic-issues@ietf.org>; Fri, 6 Dec 2019 17:54:29 -0800 (PST)
Received: from github-lowworker-2300405.va3-iad.github.net (github-lowworker-2300405.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id C70A5A0925 for <quic-issues@ietf.org>; Fri, 6 Dec 2019 17:54:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1575683668; bh=ROGmjXniNbPOJaOt82Anzzkko5V7QKtrTKr8h3tZQUA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Rp2Oujd86yFSySfSPAOeFrlUB9h3HKfjKIMd3Kk3nAK6OWsDAimuZD6IphuxOatVI wehraSQiPRpUXzkDazPE77zzAnwf4EQY8MqTcRLsH4H1Zs43xDKnyMdvB8dxY2uDHu TYvPm7SBdunNFLfVGbCUKpoUa193uCzHajd7SUCo=
Date: Fri, 06 Dec 2019 17:54:28 -0800
From: Nick Banks <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK76UTWOEDV72SIWSXN37A4NJEVBNHHB7WKXVY@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@github.com>
Subject: [quicwg/base-drafts] Allow the Transport to Stop/Reset a Stream? (#3291)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5deb0654b7b0a_56133fd7228cd960597de"; 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/0gB9GHOsQFieF66BUC9mPQ3GJWo>
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: Sat, 07 Dec 2019 01:54:31 -0000

Per the current design for streams, the application MUST be the one to shutdown a stream, because the error code space for streams is purely application layer; and the QUIC transport has no knowledge of these error code, so it can't just pick one.

When writing a general purpose QUIC library, and integrating it into other general purpose libraries ([i.e. dotnet](https://github.com/dotnet/runtime/pull/427)) I constantly have to explain to non-QUIC folks that they can't just close their stream object/handle without first supplying an application layer specific error code; meaning any intermediate library needs input from the app even if some fatal error (memory allocation failure) happened along the way.

So, I've come to the point that it might be a good idea to allow for the transport layer to completely terminate a stream for it's own reason. Whether that means we add a flag to RESET_STREAM and STOP_SENDING to indicate the transport is specifying the error code, or we add a new frame entirely doesn't matter to me. It would just be a lot cleaner for general purpose libraries to be able to kill a stream when necessary, on its own (no app layer involvement).

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: