IETF Logo Mail Archive

[quicwg/base-drafts] STOP_SENDING to QPACK streams (Issue #4984)

Tatsuhiro Tsujikawa <notifications@github.com> Wed, 06 April 2022 23:54 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 4BCE33A110B for <quic-issues@ietfa.amsl.com>; Wed, 6 Apr 2022 16:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 DfRA-NFEafT5 for <quic-issues@ietfa.amsl.com>; Wed, 6 Apr 2022 16:54:52 -0700 (PDT)
Received: from smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85BA13A10FD for <quic-issues@ietf.org>; Wed, 6 Apr 2022 16:54:52 -0700 (PDT)
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 144FD521755 for <quic-issues@ietf.org>; Wed, 6 Apr 2022 16:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1649289291; bh=ArwAiu0lGYpYUc3fyMtc+ojB+DEfml4+qUAS5mw8xco=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=KEdQXC9VTBiKrozVMPpMOscjp0MdQECMv6rXznKf3ZsyZwggpDF2lH56nPZeyVM66 xaRAtXCpMJt/AKrILbuEGb+nQtskmHOWt/HTtVbAdthjieYfTReglDDwKf90lMrBh4 DFn88FC/+xsFdtVvfqQlFhyanYqpusHmEr9on278=
Date: Wed, 06 Apr 2022 16:54:51 -0700
From: Tatsuhiro Tsujikawa <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6TBYTCQLGALSGU25WALNNMXEVBNHHEOPYYPA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4984@github.com>
Subject: [quicwg/base-drafts] STOP_SENDING to QPACK streams (Issue #4984)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_624e284b5cfd_1286c6fc515c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tatsuhiro-t
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/NnFW0YihTVXfeFDCuHHQ00kXXS0>
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, 06 Apr 2022 23:54:58 -0000

https://datatracker.ietf.org/doc/html/draft-ietf-quic-qpack-21#section-4.2

>    These streams MUST NOT be closed.  Closure of either unidirectional
   stream type MUST be treated as a connection error of type
   H3_CLOSED_CRITICAL_STREAM.

I'd like to clarify that whether this effectively says that receiver is not allowed to send STOP_SENDING.
STOP_SENDING is elicit RESET_STREAM that closes a stream.

> An endpoint that receives a STOP_SENDING frame
   MUST send a RESET_STREAM frame if the stream is in the "Ready" or
   "Send" state. 

STOP_SENDING itself does not close a stream, but it is an action to request a closure.
I found in interop runner test, one implementation sends STOP_SENDING to QPACK streams.
My implementation sends RESET_STREAM when it is received as mandated by spec, and upon stream closure, the connection is closed because QPACK streams are closed, then the test fails.

HTTP draft explicitly says that requesting closure for the control stream is prohibited:

> The sender MUST NOT close the control stream, and the receiver MUST NOT
   request that the sender close the control stream.

It would be nice to add the similar statement to QPACK streams.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4984
You are receiving this because you are subscribed to this thread.

Message ID: <quicwg/base-drafts/issues/4984@github.com>

v2.23.0 | Report a Bug | By Email