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

Geoff Kizer <notifications@github.com> Thu, 12 December 2019 20: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 6F5A61200BA for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 12:32:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHMSl92Wf7z3 for <quic-issues@ietfa.amsl.com>; Thu, 12 Dec 2019 12:32:18 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F43120024 for <quic-issues@ietf.org>; Thu, 12 Dec 2019 12:32:17 -0800 (PST)
Date: Thu, 12 Dec 2019 12:32:17 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576182737; bh=ZHiJ9CkJ3wamEKx/QeIAp3gv0r+I+5QSiWKLIbo9DCE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=EyHQrBWM0e/jBVu7WvN5pLnp0J5gCb7oECBDfheiAsDbtja8f3H/QDQAFglK4U5ru 8Yn2gEgbKPKqfBRwMlsOytF8r6logf7lSlMvLLH7uAZ6dpf1PZo6ffNRRsc0jQTEBw PiaJdt3roQs13bkQA/YAxjEOq6T4Ffx07LaR90q4=
From: Geoff Kizer <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYOBNFYOJ2LXOQFJQV377LFDEVBNHHB7WKXVY@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/565174436@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_5df2a3d11519f_56393fe9900cd960129110"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: geoffkizer
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/iKnMD8LR7I7u8K5dfypkQZwvOrY>
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, 12 Dec 2019 20:32:19 -0000

@janaiyengar 

> If there is a stream-level error within the transport, that results in a connection level error.

I understand the rationale here, but I think it's going to lead to some difficult to diagnose behavior.

Here's a concrete example: Consider a garbage collected language where the QuicStream class represents a QUIC stream. The user acquires a QuicStream instance, does some sends and receives, and neglects to properly shutdown the QuicStream. The QuicStream instance will eventually be collected, which will cause the entire connection to be killed.

Note that this is a _programming error_ -- the user failed to shutdown the stream properly -- but it's a _very common_ programming error. Ideally, it should be straightforward to diagnose. Killing the entire connection makes this rather hard to diagnose. Terminating the stream with a well-known error code like "INTERNAL_ERROR" or "UNKNOWN" or similar is much easier to diagnose.


-- 
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-565174436