IETF Logo Mail Archive

Re: [quicwg/base-drafts] Forwarding upstream errors, and the implications (#3300)

ianswett <notifications@github.com> Mon, 23 December 2019 15:01 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 B9CEF1200B7 for <quic-issues@ietfa.amsl.com>; Mon, 23 Dec 2019 07:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.382
X-Spam-Level:
X-Spam-Status: No, score=-6.382 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_24=1.618, 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 ynBzHBycWJEa for <quic-issues@ietfa.amsl.com>; Mon, 23 Dec 2019 07:01:12 -0800 (PST)
Received: from out-10.smtp.github.com (out-10.smtp.github.com [192.30.254.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070D5120026 for <quic-issues@ietf.org>; Mon, 23 Dec 2019 07:01:12 -0800 (PST)
Received: from github-lowworker-2300405.va3-iad.github.net (github-lowworker-2300405.va3-iad.github.net [10.48.17.39]) by smtp.github.com (Postfix) with ESMTP id A3DBC1212CD for <quic-issues@ietf.org>; Mon, 23 Dec 2019 07:01:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1577113271; bh=C1k9pxhP0V5LvPGEq2+S9U+RDjLEWOIEzUs4aJEGCWQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=G5a/qyhU/TiKHyqGkul03O1RhiTO+thayt+USgfMZ6nejuldf8znNVMvICQzLf+Sf DBlHZDs2sW49MG9r8SZ26Um2BdHAldeGKvWM9qHbJQQOeaCr0cmyl7tNY3yLVwbXxq tmmntyVUi29qjgdAsbPzojvpLW15CGTNNe8lAMMc=
Date: Mon, 23 Dec 2019 07:01:11 -0800
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2VQZMPSOLFHKJXZ4V4BYETPEVBNHHCABYU5A@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/568497686@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 errors, and the implications (#3300)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e00d6b75f1f8_7b13fe179ecd96c10400d8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/izgmxSeyEOiDKewe9LSiBkiKOf8>
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, 23 Dec 2019 15:01:14 -0000

With TCP, typically the reset will arrive after the payload, so the typically the partial payload can be processed.

How about using a similar recommendation for QUIC/H3: You CAN/SHOULD send all the data before transmitting the reset, but there's no need to guarantee it all arrives before sending the reset?  If an implementation really wants to guarantee the payload arrives before the stream is reset, it can, but this seems like best effort.

I don't want to add a new mechanism for this, but I agree it'd be nice to avoid the H3 connection being torn down in this case.  I do think we should scope this case a bit tighter and be more specific than the current PR, since it currently says any incorrectly formatted response MUST NOT cause a connection close and I'm realizing how wide that might be.

-- 
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-568497686

v2.23.0 | Report a Bug | By Email