Re: Broader discussion - limit dictionary encoding to one compression algorithm?
Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com> Tue, 21 May 2024 18:02 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E930C14F5FB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2024 11:02:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Level:
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="RquKdXU+"; dkim=pass (2048-bit key) header.d=w3.org header.b="Wdh8ggm7"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5pp2Bv4Dq9E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 21 May 2024 11:02:50 -0700 (PDT)
Received: from mab.w3.org (mab.w3.org [IPv6:2600:1f18:7d7a:2700:d091:4b25:8566:8113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B54C1DA1F8 for <httpbisa-archive-bis2Juki@ietf.org>; Tue, 21 May 2024 11:02:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Cc:To:From:Date:Reply-To; bh=mp9EA3npa2atJWHclky/YsXVYW4iYdp55mXwrPxxuvQ=; b= RquKdXU+/qxm73oV7NzPOlzKHN3aJNYb1jiI/kS8DfID+wbDXXf5e2cUW6zTfP3lKST9Nj4ATV3Aa 2NkaMZDP6Fun8Ms8FGK/O3Bt4ohnLb3WJA6rY2oV/9TFCSL18dUp4sj4j6TxIXzZZFcqhes4mqOwl KNrNDrWyoAk5XepFuynEdBoK+eA3cleiU6XzXId9Tkjtyub2TfGW1uB6yPPzBbep3XNaJCqJrUzLp fXRZB73EBRKWfXMRy7297t8ZbLbfz+e4HLqpMylJcsW/H5CyFhnPO5ZYOnhVZFYbVM5D4MZ+e0xuu j8i4fdl6n9bBNxFBcHwSONoOZL6bNEKMbg==;
Received: from lists by mab.w3.org with local (Exim 4.96) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1s9ToF-00FY62-2Z for ietf-http-wg-dist@listhub.w3.org; Tue, 21 May 2024 18:01:59 +0000
Resent-Date: Tue, 21 May 2024 18:01:59 +0000
Resent-Message-Id: <E1s9ToF-00FY62-2Z@mab.w3.org>
Received: from ip-10-0-0-144.ec2.internal ([10.0.0.144] helo=pan.w3.org) by mab.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <gs-lists-ietf-http-wg@gluelogic.com>) id 1s9ToE-00FY55-1U for ietf-http-wg@listhub.w3.internal; Tue, 21 May 2024 18:01:58 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject: Cc:To:From:Date:Reply-To; bh=mp9EA3npa2atJWHclky/YsXVYW4iYdp55mXwrPxxuvQ=; t=1716314518; x=1717178518; b=Wdh8ggm7fHutBEszo0DGw4Y4YcfB4FTh2yR7tZmwCzoS+dJ raoU7gVmBbuZcEZGJjKtFCMyVf8mMCDf9Yu7MRHKBb1RRVHrUCG1YOo5BiSZliSM7JgPHrZR8YQTx k2HRO3/O3YpzYNGTIasoiPI9wXJn7BDUbOYM9Tkp4gM+09pIgQkKJQJtuZeD4pmedJsIkTdrhiRp6 BITREXfQRxRjx9uxt3YmWSL8iHcEXD4VAu58mOENHNSPC+jF3koYxwuZVFkMhM1RX7riAYDoC6kPt FtltA4WIYibwq40bF43YK8YxZKvLEpt94jShySjyyjErrcj6cZ/etF/huLpKtrNA==;
Received-SPF: pass (pan.w3.org: domain of gluelogic.com designates 52.86.233.228 as permitted sender) client-ip=52.86.233.228; envelope-from=gs-lists-ietf-http-wg@gluelogic.com; helo=smtp1.atof.net;
Received: from smtp1.atof.net ([52.86.233.228]) by pan.w3.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (Exim 4.96) (envelope-from <gs-lists-ietf-http-wg@gluelogic.com>) id 1s9ToD-006QMd-2u for ietf-http-wg@w3.org; Tue, 21 May 2024 18:01:58 +0000
X-Spam-Language: en
X-Spam-Relay-Country:
X-Spam-DCC: B=www.nova53.net; R=smtp1.atof.net 1205; Body=1 Fuz1=1 Fuz2=1
X-Spam-RBL:
X-Spam-PYZOR: Reported 0 times.
Date: Tue, 21 May 2024 14:01:45 -0400
From: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
To: Patrick Meenan <patmeenan@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <ZkzhiRlXfG30_FVx@xps13>
References: <CAJV+MGzjUnZZ=XFn5veOvuhVWyZNP2b9U0fxpS3UmrDC_bc_wQ@mail.gmail.com> <202405211641.44LGfY2U006906@critter.freebsd.dk> <CAJV+MGzwbFAC7NhP611HDaVYMjMX0Q+KZ-QYirFu5WzjWL771g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAJV+MGzwbFAC7NhP611HDaVYMjMX0Q+KZ-QYirFu5WzjWL771g@mail.gmail.com>
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DMARC_MISSING=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: pan.w3.org 1s9ToD-006QMd-2u 724b86498da13e827aca301cfeaa9d58
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Broader discussion - limit dictionary encoding to one compression algorithm?
Archived-At: <https://www.w3.org/mid/ZkzhiRlXfG30_FVx@xps13>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51955
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On Tue, May 21, 2024 at 01:02:30PM -0400, Patrick Meenan wrote: > On Tue, May 21, 2024 at 12:41 PM Poul-Henning Kamp <phk@phk.freebsd.dk> > wrote: > > > Patrick Meenan writes: > > > > > ** The case for a single content-encoding: > > > […] > > > ** The case for both Brotli and Zstandard: > > > > First, those are not really the two choices before us. > > > > Option one is: Pick one single algorithm > > > > Option two is: Add a negotiation mechanism and seed a new IANA registry > > with those two algorithms > > > > As far as I can tell, there are no credible data which shows any > > performance difference between the two, and no of reason to think that any > > future compression algorithm will do significantly better. > > > > We already have a negotiation mechanism. It uses "Accept-Encoding" and > "Content-Encoding" and the existing registry. Nothing about the negotiation > changes if we use one, two or more. The question is if we specify and > register the "dcb" content-encoding as well as the "dcz" content encoding > as part of this draft or if we only register one (or if we also add a > restriction that no other content encodings can use the dictionary > negotiation). > > As far as future encodings, we don't know if any algorithms will do better > but there is the potential for content-aware delta encodings to do better > (with things like reallocated addresses in WASM, etc). More likely, there > will probably come a time where someone wants to delta-encode > multi-gigabyte resources where the 50/128MB limitations laid out for "dcb" > and "dcz" won't work and a "large window" variant may need to be specified > (as a new content encoding). A practical approach is to allow for future unknowns as you describe above, and to pick one of (brotli, zstd) to be required to be implemented in this version of the standard, with the other optional. Future versions might have a different required algorithm, and include the intention that an algorithm required in a prior version will remain an option in future versions. If a content-provider spends the time to build procedures and infrastructure to deploy compression dictionaries, they will probably experiment with their content and their CPU, memory, and other resource limitations; and along with client capabilities, balance their choices based on all of those inputs and more. Proxies and CDNs may make different choices on what they support receiving from origin servers, how they store it, and what they support sending to clients. Intermediate security scanners and possibly alternate corporate malware will add other limitations. Compression dictionaries are an optional feature and one that an origin server might choose not to implement (or a server deployed before and older than the specification). Cheers, Glenn
- Broader discussion - limit dictionary encoding to… Patrick Meenan
- Re: Broader discussion - limit dictionary encodin… Poul-Henning Kamp
- Re: Broader discussion - limit dictionary encodin… Patrick Meenan
- Re: Broader discussion - limit dictionary encodin… Glenn Strauss
- Re: Broader discussion - limit dictionary encodin… Roy T. Fielding
- Re: Broader discussion - limit dictionary encodin… Jyrki Alakuijala
- Re: Broader discussion - limit dictionary encodin… Patrick Meenan
- Re: Broader discussion - limit dictionary encodin… Jyrki Alakuijala