Re: Please review HTTP performance aspects of Incremental Font Transfer
Martin Thomson <mt@lowentropy.net> Wed, 29 June 2022 01:53 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 0B314C15AAE1 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Jun 2022 18:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.758
X-Spam-Level:
X-Spam-Status: No, score=-7.758 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=mfnj+ccm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q8hGGTWU
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 kfO_k_yUHc9R for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 28 Jun 2022 18:53:11 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 63BBFC15AACD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 28 Jun 2022 18:53:10 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1o6MqP-00CNGx-Gb for ietf-http-wg-dist@listhub.w3.org; Wed, 29 Jun 2022 01:50:17 +0000
Resent-Date: Wed, 29 Jun 2022 01:50:17 +0000
Resent-Message-Id: <E1o6MqP-00CNGx-Gb@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mt@lowentropy.net>) id 1o6MqO-00CNG4-Lu for ietf-http-wg@listhub.w3.org; Wed, 29 Jun 2022 01:50:15 +0000
Received: from wout5-smtp.messagingengine.com ([64.147.123.21]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <mt@lowentropy.net>) id 1o6MqM-006sLu-Os for ietf-http-wg@w3.org; Wed, 29 Jun 2022 01:50:15 +0000
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 2E2C1320090F for <ietf-http-wg@w3.org>; Tue, 28 Jun 2022 21:50:01 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 28 Jun 2022 21:50:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1656467400; x= 1656553800; bh=dMZwH5iA3hvBDK35wHLeRINfTk+7HzxNxaBjJlvqU6E=; b=m fnj+ccmheBBEQmNpez7JSlp3txiZrh7oF0kTR9Q/yxlD4ZKXRGB7e9DH9Xj5yrWM xId6AdUU3TC2qRftAY7Yif1KCglRYX8w2uqOUHZoY1R6dRR9beFak0hQJIZsygPT 2tcPwXj9FE0FZBSuoCU4BEiezO6UjJdPQIDaGLyB+0YHVb28rcZOPUPNYMihSHCX zETUj1s501nYKYzTlCkMKfZo43PyHdUCevAqKqVvxJaBcyd4AqD9fHnghLFwvfIr aVuKS2irkjJPiIct9Wbff7Zy/z5cKnC4kQqpdnOFlMNNo+x6x6RvrYgDnNI6WboK Q6qZFVeehXYeZVKtCseQA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1656467400; x=1656553800; bh=d MZwH5iA3hvBDK35wHLeRINfTk+7HzxNxaBjJlvqU6E=; b=Q8hGGTWUo0rbeTX8a FrReXoClaNw5OY82fKNWNCzphSz4Bk1jMGjrLwr+T4cCsUi+EYglyhnyM5lCe2Vx oy0fAj8vRueNeXTCpdqmiUqDHDimX3XVE7CZ3NF+m+B0vCJa4+taAxI0igtOnrNs jryYc8UQGkvuN0sXNorsnDGskCkr5psjK07F/xUnv+pomBFeTdq6ESZn7ET9+Kif prfyDXRG0flbkR+0GLpAkqZd7rw1Uf9a7uAe7waIpneQa/VF7MX/spjnW14o8IpL P+eHi02Cu/W8M5iGUS9tobRoTtx5hb37vY+hGQ01B3uGY7lByh9plopfeex+vCxR OqxWA==
X-ME-Sender: <xms:yK-7Yj_Nlz-haPq9e7vBHhDqyBOs10DtiwkSrw3m4E0EJQydRvy1QA> <xme:yK-7YvsZE5aFW6DakdW1JlxRa5klGR8W0vVSncMH10Bd-aOjjyW3COn4PcFNtbOxt Le_k5tmKcJh7Ojpg10>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudegkedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepffegteduleevledtte ekgeffveejudfffffgveevtdegudejheevgeejieefjeeinecuffhomhgrihhnpehgihht hhhusgdrtghomhdpthhhvghrvghishgrlhhothhofhhnihhhvghvihguvghnthhinhhthh gvshhpvggtihhfihgtrghtihhonhdrhihouhdpfiefrdhorhhgnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphi drnhgvth
X-ME-Proxy: <xmx:yK-7YhDqPaQ4WObA0kQIxossHa-wfrvVoTePhXdCRhxIxqsutm5aTA> <xmx:yK-7Yvd0SnqnoOXDok0NpyWL7Au4t6TPSn5-SQvo-c0Lhq0BgD6Seg> <xmx:yK-7YoN7wTgrSyMMDC6j5_WqyYCN48_RYtlvNwvQptIUehBKdsYpbw> <xmx:yK-7YuYAd9LXesSMOcXkRcdlUdCpmIERXXK-02126L8N-GDZ_R4lUg>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6CF382340077; Tue, 28 Jun 2022 21:50:00 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7
Mime-Version: 1.0
Message-Id: <b29bbf8b-25da-4abb-a310-34ad4c68d7ba@beta.fastmail.com>
In-Reply-To: <5eb29866-36c1-8fe5-0f1b-0d560c2f7dff@w3.org>
References: <5eb29866-36c1-8fe5-0f1b-0d560c2f7dff@w3.org>
Date: Wed, 29 Jun 2022 11:49:40 +1000
From: Martin Thomson <mt@lowentropy.net>
To: ietf-http-wg@w3.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=64.147.123.21; envelope-from=mt@lowentropy.net; helo=wout5-smtp.messagingengine.com
X-W3C-Hub-DKIM-Status: validation passed: (address=mt@lowentropy.net domain=lowentropy.net), signature is good
X-W3C-Hub-DKIM-Status: validation passed: (address=mt@lowentropy.net domain=messagingengine.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-11.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IM=-5, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1o6MqM-006sLu-Os 64478b031ba6b551888883c534087b44
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Please review HTTP performance aspects of Incremental Font Transfer
Archived-At: <https://www.w3.org/mid/b29bbf8b-25da-4abb-a310-34ad4c68d7ba@beta.fastmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40215
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/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi Chris, This is not the first time that I've seen this specification, but I've not commented before. It seems fairly obvious (more so with the research referred to) that being able to obtain a subset of large fonts is good for performance. So work in this area is appreciated. However, there are a number of aspects of this design that are neither obvious nor explained. The most obvious question is about why you would provide *two* mechanisms. Nothing explores why you might prefer one over the other, at server or client. It is simply taken for granted there there are two. I don't know how a client might be expected to use this specification in a sensible fashion based on the information presented. Nor how a server might choose to deploy one or the other. There is a lot of text on a format for expressing subsets of fonts that I did not read, but the idea that you might just put those in a query parameter on any font request is ... (I'm struggling to find the right word here) ...irresponsible. Grossly so. Mark has already entreated you to read RFC 8820, but I will quote from Section 2.4 so that there is no mistaking the error: > Extensions MUST NOT constrain the format or semantics of queries, to avoid collisions and erroneous client assumptions. This spec violates that assumption. https://github.com/w3c/IFT/issues/75 offers some alternative designs that I encourage you to explore. This one is not acceptable. There are a bunch of other issues that are apparent to me as a non-expert: 1. The issue Mark raised about connection management (https://github.com/w3c/IFT/issues/74) is a case of over-specification. The general strategy for retrieving enough of a font to learn where pieces of it might live might be useful, but you can specify too much and this very much does so. 2. The use of transfer coding for compression won't work in most cases. Transfer coding isn't available in all versions of HTTP. 3. There is a lot of NIH evident in the specification. You are inventing new integer encodings and an entire data format. I also see what appears to be a novel checksum algorithm. I do like the idea of specifying how a font might be laid out to make it easier to process in pieces, but some of this seems very optimistic about what people will be able to do with fonts to make them faster for pages. Do you really want to have a different font for every page? Is that a good outcome when every page has its own font to download? We are dealing with similar issues with bundling of JS. The result seems to be that you can optimize for one page, or optimize for many pages, but not both. This specification contains none of that sort of nuance. As for being able to produce a complete font in response to a query that specifies codepoint and feature subsets, that has some very poor caching properties, in addition to the query semantics issues already identified. I can't see anywhere that the specification addresses those concerns. Cheers, Martin On Tue, Jun 28, 2022, at 22:34, Chris Lilley wrote: > The Web Fonts WG requests review of the Incremental Font Transfer (IFT) > specification by the IETF HTTP WG. A new WD of IFT was published today [1] > > This specification defines two methods to incrementally transfer fonts > from server to client. Incremental transfer allows clients to load only > the portions of the font they actually need which speeds up font loads > and reduces data transfer needed to load the fonts. A font can be loaded > over multiple requests where each request incrementally adds additional > data. > > Earlier work [2] demonstrated the performance improvements in terms of > bytes transferred and reduced network delay, for various network types. > > The current work proposes a specific networking mechanism by which the > client and server can negotiate which IFT method to use [3], and to > transfer requested subsets of the entire font [4][5]. Note too that Mark > Nottingham has raised a performance concern for the Range Request method [6] > > We would particularly value the review of the IETF HTTP WG on those > aspects, although review of the entire specification would of course be > most welcome. > > Please feel free to raise issues on our GitHub repo [7]. > > [1] https://www.w3.org/TR/2022/WD-IFT-20220628/ > [2] https://www.w3.org/TR/PFE-evaluation/ > [3] https://www.w3.org/TR/2022/WD-IFT-20220628/#method-selection > [4] https://www.w3.org/TR/2022/WD-IFT-20220628/#extend-subset > [5] > https://www.w3.org/TR/2022/WD-IFT-20220628/#browser-behaviors-subsequent-requests > [6] https://github.com/w3c/IFT/issues/74 > [7] https://github.com/w3c/IFT/issues/ > > -- > Chris Lilley > @svgeesus > Technical Director @ W3C > W3C Strategy Team, Core Web Design > W3C Architecture & Technology Team, Core Web & Media
- Please review HTTP performance aspects of Increme… Chris Lilley
- Re: Please review HTTP performance aspects of Inc… Martin Thomson
- Re: Please review HTTP performance aspects of Inc… Chris Lilley
- Re: Please review HTTP performance aspects of Inc… Martin Thomson