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

Kazuho Oku <notifications@github.com> Sun, 08 December 2019 23:59 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 466DA1200FF for <quic-issues@ietfa.amsl.com>; Sun, 8 Dec 2019 15:59:56 -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 8nptoZjAkPED for <quic-issues@ietfa.amsl.com>; Sun, 8 Dec 2019 15:59:54 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A801E1200FD for <quic-issues@ietf.org>; Sun, 8 Dec 2019 15:59:54 -0800 (PST)
Received: from github-lowworker-292e294.va3-iad.github.net (github-lowworker-292e294.va3-iad.github.net [10.48.102.70]) by smtp.github.com (Postfix) with ESMTP id AE4432C0E5A for <quic-issues@ietf.org>; Sun, 8 Dec 2019 15:59:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1575849593; bh=4cQZXw2snFG4TrEyhiLaZ5p/eQ8hsgp9GH+Dg6O6H6c=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MMKwywz/aH7JHJNvUQHRooOrsSWkW7OsLL2LtI8XLqJpWDk4aHsm1oj/Xi9t2MUe3 CDBmd6MlOqHGEHQNEd+yIps8NX6hV8OowUUUnT0nGv9uYG0myA/1doRx6NJzXzw83/ 6PqsTlmHkgxcAJtHUs3kVxd3cVdBjIu5rGaMSuLQ=
Date: Sun, 08 Dec 2019 15:59:53 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK52QCSF7IYWGMWZ4P537LAPTEVBNHHB7WKXVY@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/563012768@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_5ded8e799f3e8_6afa3fab77acd96c14113e"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/lytqqxEdkbeben0e07PJqQA1kYM>
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: Sun, 08 Dec 2019 23:59:56 -0000

While I can see the concern (at least theoretically), I am not sure if we can come up with a good design for HTTP/3.

The concept of having a stream-level reset as a transport-level feature (which should be application-agnostic) is based on the premise that each stream operates independently. For example, the transport resetting an arbitrary stream is fine in case of HQ (i.e. HTTP/0.9 over QUIC).

However, for application protocols like HTTP/3, that does not work, because the application protocol is designed to use multiple streams for doing an exchange. For example, exchange of an HTTP request typically involves three streams (i.e. the request stream, QPACK encoder stream, QPACK decoder stream). The transport cannot reset one stream, and the communication on the rest of the stream to succeed.

Considering this, I think it's reasonable to limit the signaling scheme of transport-level error signals to connection level (i.e. CONNECTION_CLOSE; frame=0x1c), at least in QUIC v1.

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