IETF Logo Mail Archive

[quicwg/base-drafts] Unidirectional RESET_STREAM/STOP_SENDING semantics map poorly to proxies (#2415)

martinduke <notifications@github.com> Mon, 04 February 2019 23:55 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 0A260129508 for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 15:55:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.553
X-Spam-Level:
X-Spam-Status: No, score=-12.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_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 xb6CnZ6M5xx3 for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 15:55:35 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8A7B1294FA for <quic-issues@ietf.org>; Mon, 4 Feb 2019 15:55:35 -0800 (PST)
Date: Mon, 04 Feb 2019 15:55:34 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549324534; bh=iqsjVlMctuq1JKOUdyNwbN5Fl1+fvmTS2Pxion6xqFM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=P83ocq+IqGf70gBrnecK+9x/G8oTvCsGSHlfoNRFnk0nz6itIYWjD0ADH7L5EcOc8 cdQLMGJTBQNVSmUcTNY96lMOHbfcG7PAf+O3yVRrtlgFQ1WvNZzKqjzP5rI+w/DpNQ YkL0SW47NRBSih9unN3Mbaj7wia7v1v+RQgLJxpA=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab19dd5a8f178cca7a0df6a8527adfec10695d8e3692cf00000001187092f692a169ce183bce82@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2415@github.com>
Subject: [quicwg/base-drafts] Unidirectional RESET_STREAM/STOP_SENDING semantics map poorly to proxies (#2415)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c58d0f68f633_768d3fcba32d45c012718c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/XsHTSG47QJ7leheyCoRTemmrPkY>
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, 04 Feb 2019 23:55:38 -0000

Apologies for the lateness of the issue, but I only recently realized I was doing it wrong.

What is the thinking behind RESET_STREAM only applying to the send side of a bidirectional stream? What use case says "never mind about what I'm sending you, but please keep sending to me" within the same stream context?

I ask because this is a break from the HTTP/2-TCP world and I'm not sure we fully understand its properties.  In particular, this divergence is uncomfortable for proxying HTTP/3 for HTTP/1 and HTTP/2 servers.

If the HTTP/3 client sends a RESET_STREAM, what is the proper semantic to translate to the HTTP/2 side? An HTTP/2 RESET_STREAM will kill both directions, which seems like a problem in the general case. We can FIN the H/2 stream, but is that communicating the correct semantic to the application?

Similarly, if we get a STOP_SENDING, what's the correct translation? Zeroing out receive flow control on the HTTP/2 stream?

More generally, a future (non-HTTP) proxy use case might map QUIC streams to some protocol over individual TCP connections. This has the same problem: FIN maps nicely to TCP FIN, but RESET_STREAM and STOP_SENDING both have to use TCP RST somehow.

Maybe the answer is that fronting non-QUIC/H3 protocols implies that STOP_SENDING and RESET_STREAM have to go together. Would that break stuff?

I can see a few cases where it might be optimal to be able to flush only one direction of queues, but wonder if this is worth the added semantic confusion, and the bandwidth cost of having to send RESET_STREAM in both directions. We need to get a "final length" in both directions to keep the flow control accounting right, but that could be declared by the receiver.

I'm not sure what specific recommendation to make here, but am curious about everyone's thoughts.

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

v2.23.0 | Report a Bug | By Email