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

Martin Thomson <notifications@github.com> Tue, 05 February 2019 00:09 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 1F9891294FA for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 16:09:18 -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 VjmtjQUrtzHI for <quic-issues@ietfa.amsl.com>; Mon, 4 Feb 2019 16:09:16 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C95126DBF for <quic-issues@ietf.org>; Mon, 4 Feb 2019 16:09:16 -0800 (PST)
Date: Mon, 04 Feb 2019 16:09:15 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1549325355; bh=ZwddqNvx4kVeNUoXFAWGYjL7elH1DSNe3dTs1jnurTI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mNcubcHVLKWOD5FKUPZLYp0LZ/nmLM6WjE5fB8aht32GEz+CgAiQ5YQC/R+3p/++d YWBKOlu28jvOObQxpKaAeeXcpHzdhocWitc94lqddYY49Rz0H+ZqclOskFI3M/Vo/1 WCwv1wOr2mS5JSTU6LG1ku3tWS4IH7DnVk6QmOcw=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba2add20c880f839f1e2f9319eaad171e65931ee392cf000000011870962b92a169ce183bce82@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/460463895@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2415@github.com>
References: <quicwg/base-drafts/issues/2415@github.com>
Subject: Re: [quicwg/base-drafts] Unidirectional RESET_STREAM/STOP_SENDING semantics map poorly to proxies (#2415)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c58d42b526c1_11263fa5b1cd45c410709a"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/jmd_Eq6bLL76PLjJtNweSsdVgf4>
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, 05 Feb 2019 00:09:18 -0000

This is a great example of something that would be better on the mailing list.

The reason for the split is to ensure that the state machine is consistent and synchronized.  Cancellation of a stream requires RESET_STREAM in both directions to ensure that the flow control state doesn't get out of sync.  We discussed attaching a value to STOP_SENDING, but that creates difficult conflicts if one side sends STOP_SENDING and the other sends RESET_STREAM concurrently.  We also don't insist on STOP_SENDING being transmitted reliably.  In other words, just fixing this would be a massive change.

It also exists to provide for cases in HTTP where one side of a flow (typically a request) isn't needed.  Consider a large POST to a resource that has been removed.  The server can send STOP_SENDING and a 404 response without fear that the 404 will be shredded.

All of that has been litigated at some length.

The problem here is in mapping to protocols that have inconsistently implemented or non-existent half-closed states.  That would be TCP for the former and HTTP/2 for the latter.  My inclination would be thus:

RESET_STREAM only = stop forwarding data in that direction, and record this state
STOP_SENDING only = stop forwarding data in that direction, and record this state
RESET_STREAM in both directions or RESET_STREAM and STOP_SENDING from the same peer = kill the flow, using things like h2 RST_STREAM or TCP RST

I don't think that this implies that RESET_STREAM and STOP_SENDING have to be bundled.

-- 
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#issuecomment-460463895