IETF Logo Mail Archive

Re: [quicwg/base-drafts] Limit fallout of on-stream badness (#3336)

ianswett <notifications@github.com> Tue, 14 January 2020 21:20 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 0A8C2120882 for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 13:20:33 -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 j2c4mBbgGcUK for <quic-issues@ietfa.amsl.com>; Tue, 14 Jan 2020 13:20:26 -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 3B40F120110 for <quic-issues@ietf.org>; Tue, 14 Jan 2020 13:20:26 -0800 (PST)
Received: from github-lowworker-28f8021.ac4-iad.github.net (github-lowworker-28f8021.ac4-iad.github.net [10.52.25.98]) by smtp.github.com (Postfix) with ESMTP id 61A3B960DAF for <quic-issues@ietf.org>; Tue, 14 Jan 2020 13:20:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579036825; bh=zDRJNwDvYRLhD6hPGKFukOTusjVANIkqPe2RRENT8eg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eHtZGJP7AEF6CoYQ/gCe/vHW8eHHctZ5X6g6THCU8LIp5eicEM3C/HH0xFMUIkPiN P0lO6OH0J/HuoWHDzqDrMzua6rhJG2+D3uncdmInRzGybvcoxjeII7s+6BUbQMCY10 m4I/dXB/wDX5H2oK/EZINDzbumK/CmWEr3/dwYB4=
Date: Tue, 14 Jan 2020 13:20:25 -0800
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK46HPZTJHA2HDYUZQ54FNRRTEVBNHHCBO6ZLI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3336/c574379204@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3336@github.com>
References: <quicwg/base-drafts/pull/3336@github.com>
Subject: Re: [quicwg/base-drafts] Limit fallout of on-stream badness (#3336)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1e309952f7a_184f3fe62e6cd960779b5"; 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/hG283JcoeWor8wQlVaMexWQMHQY>
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, 14 Jan 2020 21:20:33 -0000

Thanks for writing this PR, seeing it written down makes me like it clear that I'm not a fan of this change.

One can certainly implement a proxy that doesn't validate the frames, but for this proxy to receive a single H3 connection on the front and send multiple H3 connections out the back, it's going to have to do more than blindly proxy.  For example, there's only one control stream, and I can't imagine how it's possible to run QPACK anything but hop-by-hop.  It also has to map push Ids, etc.

If there's some practical use case I'm missing, please tell me, but in most cases, blindly proxying these frames wouldn't even work, with the DATA frame being the possible exception?

-- 
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/pull/3336#issuecomment-574379204

v2.23.0 | Report a Bug | By Email