Re: [quicwg/base-drafts] Make using static table and Huffman encoding in QPACK opt-in (#3622)

Victor Vasiliev <notifications@github.com> Mon, 04 May 2020 16:29 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 255A43A0C92 for <quic-issues@ietfa.amsl.com>; Mon, 4 May 2020 09:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 wOizgpL8QdYC for <quic-issues@ietfa.amsl.com>; Mon, 4 May 2020 09:29:45 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D41A3A0C97 for <quic-issues@ietf.org>; Mon, 4 May 2020 09:29:40 -0700 (PDT)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net [10.48.102.32]) by smtp.github.com (Postfix) with ESMTP id 1CF34C65571 for <quic-issues@ietf.org>; Mon, 4 May 2020 09:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588609779; bh=GillorQCTUr9cR/OBLb+diDr7sEzaBZnY6dzlmWFW+4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=zuRC8SEme1+Xeb314eMZwlXMG4EqF7yw/b7l9D3Pg0rupaVrHlNNqFfHzGX6eey9V am65xea+SznWANk3MyHJXKvmYYE3yROfXoqGjCjSULnrsY4TEro9hXo6ct4sC1hQeB FNS09uTp+MN7nmSvRJF6L3cvK5WBaUGmakzpVsiU=
Date: Mon, 04 May 2020 09:29:39 -0700
From: Victor Vasiliev <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3QXGPX427EMTP32B54XQR7HEVBNHHCIZJKDU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3622/623568022@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3622@github.com>
References: <quicwg/base-drafts/issues/3622@github.com>
Subject: Re: [quicwg/base-drafts] Make using static table and Huffman encoding in QPACK opt-in (#3622)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eb042f3d3d4_705b3f82200cd9602170bc"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: vasilvv
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/I4qjdX-PHNc-XYD3GpWGQFxwVm0>
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 May 2020 16:29:50 -0000

> How should a server that has no intention of enabling this setting respond to HEADERS that include other instructions? If the answer is to blow up the connection then the (unintended?) side effect will encourage clients to start connections by sending all requests as "Literal Header Field Without Name Reference" until they receive the setting. But that stage of a HTTP/3 connection is the exact place where static and huffman have the most value; we groomed the static table to suit best the first flights of client requests.

Well, I suggest this mechanism as an opt-in, rather than an opt-out, so it's less of "encourage" and more of "require".

This will in fact affect the first flight of requests if the client does not receive server's SETTINGS frame fast enough.  That does sound like a problem, but it will be eventually fixed when we fix #3086, so I'm not particularly concerned.

> My concern is that by trying to accommodate some smaller segment of HTTP clients, we cause a serious regression compared to HTTP/2.

That's a fair point.  On the other hand, HTTP/2 did come with a lot of features that we decided to make optional in HTTP/3, so that would be another step in this direction.

> This sort of thing seems better suited to a version that is "profile of HTTP/3" that disables some things and mandates others.

I am not sure how that kind of profile would look in practice.  The reason I am filing this for v1 is that in general, you can add complexity as an opt-in, but opting out of it does not really work.

-- 
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/3622#issuecomment-623568022