Re: [quicwg/base-drafts] Forwarding upstream error mid-body to downstream (#3300)

Martin Thomson <notifications@github.com> Tue, 17 December 2019 03:46 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 5620112009C for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 19:46:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 T8cI3HF42pFC for <quic-issues@ietfa.amsl.com>; Mon, 16 Dec 2019 19:46:10 -0800 (PST)
Received: from out-11.smtp.github.com (out-11.smtp.github.com [192.30.254.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29705120041 for <quic-issues@ietf.org>; Mon, 16 Dec 2019 19:46:10 -0800 (PST)
Date: Mon, 16 Dec 2019 19:46:09 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1576554369; bh=AivDtpwFhrtAzQT3J4XJOKJCx+HG0TLzXkghtbMuenc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=T9tvKCNnitttiELtnNw9wTh0oPiW3ZWt522ldM/Vs4ibEI/4FBJRrdpG20MJiAZes wFkwJ2m5b5zH5YcvTqP+c8PbFqpd7wVZGWwAvXTPVAvO1fYM+1i9zdqWMi/kHGJOY/ 4qBN/FBsTQrl6tIUwmocdrh+r9azaZBurfAbhEUE=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZRLKQZA4JTQ7MKX7V4AWBADEVBNHHCABYU5A@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3300/566367359@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3300@github.com>
References: <quicwg/base-drafts/issues/3300@github.com>
Subject: Re: [quicwg/base-drafts] Forwarding upstream error mid-body to downstream (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5df84f8110598_457f3fec3decd95c857cb"; 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/QFeCWU3KgenIrQbyCZ2fxO5B48U>
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, 17 Dec 2019 03:46:12 -0000

Look, I recognize the difficulty here, but I don't think that this problem suggests anything other than a (maybe) a new stream reset error code.  I realize that pushes for widening of the HTTP/3-to-transport interface, but I can't see an alternative that does not create horrible externalities for this use case.  Important as it might be for CDNs and the web, I don't think that it is a good idea to have the rest of the system bear the cost of dealing with the problem.

I am very much opposed to the proposal in #3303 for previously-stated reasons.

Enabling in-order delivery of stream resets would be a massive disruption to the protocol, even if we only did it at the HTTP/3 layer.  I don't concretely know how to do that, but it implies a significant shift (or bifurcation) in the stream model if we did it at the transport layer.

Adding in-order resets at the application layer for HTTP/3 is not trivial either.  A frame on the same stream is not going to work because it prevents an intermediary from forwarding without reframing at that layer.  Otherwise, they would not be able to guarantee that they can send any frame on the stream.  That requires a big shift in how people approach building of intermediaries.  Something on a control stream might work, but then you have the potential for ambiguity about placement relative to the target stream unless you effectively replicate the RESET_STREAM design at the application layer.  That would make me very uncomfortable.

It seems to me that you *can* address this without changing the protocol, even if it requires some awkward crossing of protocol layers.  That's my preference.

-- 
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/3300#issuecomment-566367359