IETF Logo Mail Archive

[quicwg/base-drafts] Transport API: Reset after FIN? (#3163)

Mike Bishop <notifications@github.com> Mon, 28 October 2019 20:24 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 24766120096 for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 13:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_32=0.001, 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 f3fxNSnQPUBV for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 13:24:45 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8B3112004E for <quic-issues@ietf.org>; Mon, 28 Oct 2019 13:24:45 -0700 (PDT)
Received: from github-lowworker-a6a2749.va3-iad.github.net (github-lowworker-a6a2749.va3-iad.github.net [10.48.16.62]) by smtp.github.com (Postfix) with ESMTP id CE22A8C0D03 for <quic-issues@ietf.org>; Mon, 28 Oct 2019 13:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572294284; bh=m4sT4QbzZlxba838T48yS5ZiikY0RJqEeKSRwgWBNnA=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=gHGVNTRwD7XiHZicAfG+7Bjv/LKtqgq5UDA9gdXAHkfOYONKqDGeCxOnAHm8JYiaF cFM6p98BBj3h6k2nDGKwYNY6xQj/t8pAQBJtmItaMmgs+5L9hpxsmmcQpJ8VIfAENS RfxuVR4dg5y4wQ7by2ifUhKleU6YSPLVQJVnY/zY=
Date: Mon, 28 Oct 2019 13:24:44 -0700
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK5NRQDL5POJOYB2NH53YSHRZEVBNHHB5G7VA4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3163@github.com>
Subject: [quicwg/base-drafts] Transport API: Reset after FIN? (#3163)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db74e8cbf4b2_35543fbeed0cd960253282"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/CgV221rK4n6gcMWvvCSuNVIS378>
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: Mon, 28 Oct 2019 20:24:47 -0000

In discussion on #2857, @mikkelfj points out that it requires transport stacks to support abrupt closure of a stream even after the stream has been cleanly closed.

This reflects the possibility to transition from "Data Sent" (stream has ended) to "Reset Sent" by sending a RESET_STREAM.  Based on the state diagram in the transport doc, if an implementation was already in the "Data Recvd" state, they wouldn't actually send a RESET_STREAM, as they're already in a terminal state; a reset call would be a no-op or an error of some kind.

However, @mikkelfj points out that in a handle-based API, this essentially means that handles for closed streams have to be recognizable as such for the lifetime of the connection.  This might be burdensome for some implementations.

Should we reword the requirement here to say that it's permitted if the stream hasn't yet reached the "Data Recvd" state.

-- 
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/3163

v2.23.0 | Report a Bug | By Email