[quicwg/base-drafts] Inconsistency in STOP_SENDING requirements relative to resetting streams in general (#2884)

mjoras <notifications@github.com> Tue, 09 July 2019 15:37 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 CD6B71201F8 for <quic-issues@ietfa.amsl.com>; Tue, 9 Jul 2019 08:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_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 TvSVSxMavgux for <quic-issues@ietfa.amsl.com>; Tue, 9 Jul 2019 08:37:03 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.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 5E5D612017C for <quic-issues@ietf.org>; Tue, 9 Jul 2019 08:37:03 -0700 (PDT)
Date: Tue, 09 Jul 2019 08:37:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1562686622; bh=bWMvlJe0VuIxnwTD0JWGHqiaaXfsqfZNshW9ky92q9w=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=dRETwkK0KYEH3CRlrNfE3WMW8QqNT7uNU/Z+agepseFXzKvGmS9OC2jald/Ju88eT 7zW6nI1L+xJFI7k4HAlrs6KHqfwVsPou52Nj3R7MJ9DK2W/hVVfV9XwaU3mNlwiCU/ 5KSdhAvMnL91xiOSpYDehcB7p/3Dk/+Z+dc+EPSk=
From: mjoras <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2JJ2ZQU6LRTDLN2HF3GHTR5EVBNHHBXRCWWI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2884@github.com>
Subject: [quicwg/base-drafts] Inconsistency in STOP_SENDING requirements relative to resetting streams in general (#2884)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d24b49e4f591_5c563feaae4cd96017569d4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mjoras
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/W5_HgWt9AC2vjhna5v7WKAwfHR8>
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: Tue, 09 Jul 2019 15:37:06 -0000

Section 11.2 of the transport draft reads:

>RESET_STREAM MUST be instigated by the protocol using QUIC, either directly or through the receipt of a STOP_SENDING frame from a peer. RESET_STREAM carries an application error code. Resetting a stream without knowledge of the application protocol could cause the protocol to enter an unrecoverable state. Application protocols might require certain streams to be reliably delivered in order to guarantee consistent state between endpoints.

This would suggest that the transport implementation itself should not be deciding to send RESET_STREAMs on its own, rather it is a matter of the application protocol using QUIC. However, it is somewhat weaselly about STOP_SENDING. My original interpretation of this text was that the implementation should expose the fact that a STOP_SENDING has been received, but it is up to the application protocol to actually reset the stream. This interpretation is not consistent with section 3.5, Solicited State Transitions: 

> A STOP_SENDING frame requests that the receiving endpoint send a RESET_STREAM frame. An endpoint that receives a STOP_SENDING frame MUST send a RESET_STREAM frame if the stream is in the Ready or Send state. If the stream is in the Data Sent state and any outstanding data is declared lost, an endpoint SHOULD send a RESET_STREAM frame in lieu of a retransmission.
I believe the only reasonable way to interpret this is that the transport itself should respond to the STOP_SENDING by issuing a RESET_STREAM.

Requiring that the QUIC implementation itself reset the stream seems to go against the philosophy that the protocol should have complete control over resets. It's true that in the case of receiving a STOP_SENDING, the protocol on the other side is asking for a RESET_STREAM, but the entity being solicited should be its peer protocol implementation, not the QUIC implementation. I believe we can fix this by altering the normative text requiring sending a RESET_STREAM, instead prescribing that an application protocol ought to handle STOP_SENDING by eventually fulfilling the solicited reset.

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