IETF Logo Mail Archive

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

mjoras <notifications@github.com> Wed, 10 July 2019 16:40 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 BCD7A120179 for <quic-issues@ietfa.amsl.com>; Wed, 10 Jul 2019 09:40:33 -0700 (PDT)
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 fbXaA_Iww6_q for <quic-issues@ietfa.amsl.com>; Wed, 10 Jul 2019 09:40:31 -0700 (PDT)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1341D1201EF for <quic-issues@ietf.org>; Wed, 10 Jul 2019 09:40:22 -0700 (PDT)
Date: Wed, 10 Jul 2019 09:40:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1562776815; bh=tp4/Z54uP6efu07GknXQYdKgyo0jthQOZ6Z9GD466i0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=pvIb7smmYmtYCRHkHWCujWv/Jj/6dZnznrqdgGScmqk2k7HM/5T0PtIgeXiUImg6K XFOR03ozWQevrfgzxav4JOc7CTlvhV3/PiDK2cGgKPSlo3dO9ID7xNUM8IKyyb3Fqa W2a5Bc1I7N7xZHYWlN+jctv/B+rHqd9adCIxXS5g=
From: mjoras <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6DQD2WL47GS6KOKK53GNDW5EVBNHHBXRCWWI@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/510138171@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2884@github.com>
References: <quicwg/base-drafts/issues/2884@github.com>
Subject: Re: [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_5d2614eee78e1_10ef3f9a6fecd968250366c"; 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/ueNybTALGFlhKVFFRFLS59taBPc>
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: Wed, 10 Jul 2019 16:40:34 -0000

I am suggesting more than an editorial change, actually. I'm disputing that it makes sense for the transport to be the one initiating the RESET_STREAM as opposed to the STOP_SENDING merely being informative to the application protocol, i.e. it should be the application protocol's responsibility to respond to the STOP_SENDING by resetting the stream.

>From an implementation standpoint, one would obviously want feedback on receiving a STOP_SENDING frame. This makes it so the implementation has to make a choice when receiving the STOP_SENDING. Is it supposed to reset the stream before or after delivering this information to the application protocol? This has consequences as resetting the stream before informing the application obviously effects the stream state.

Is there any disadvantage to instead only requiring that the transport inform the application protocol of the receipt of the STOP_SENDING, and then the application protocol is left to decide when to actually reset the relevant stream?

-- 
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/2884#issuecomment-510138171

v2.23.0 | Report a Bug | By Email