Re: Please review HTTP performance aspects of Incremental Font Transfer

Chris Lilley <chris@w3.org> Mon, 04 July 2022 12:38 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 0A171C15A74C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 4 Jul 2022 05:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.786
X-Spam-Level:
X-Spam-Status: No, score=-4.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-1.876, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
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 brbUImMeVpvr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 4 Jul 2022 05:38: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 F0DECC15A74A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 4 Jul 2022 05:38: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 1o8LIC-00Bb3w-78 for ietf-http-wg-dist@listhub.w3.org; Mon, 04 Jul 2022 12:35:08 +0000
Resent-Date: Mon, 04 Jul 2022 12:35:08 +0000
Resent-Message-Id: <E1o8LIC-00Bb3w-78@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <chris@w3.org>) id 1o8LIB-00Bb2z-Ax for ietf-http-wg@listhub.w3.org; Mon, 04 Jul 2022 12:35:07 +0000
Received: from raoul.w3.org ([128.30.52.128]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <chris@w3.org>) id 1o8LI9-009NjM-P2 for ietf-http-wg@w3.org; Mon, 04 Jul 2022 12:35:06 +0000
Received: from athedsl-406801.home.otenet.gr ([79.131.141.15] helo=[192.168.1.7]) by raoul.w3.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <chris@w3.org>) id 1o8LI9-0004D4-CL for ietf-http-wg@w3.org; Mon, 04 Jul 2022 12:35:05 +0000
Content-Type: multipart/alternative; boundary="------------Kx1jKKSL7y3wR0BGxUNjfCYk"
Message-ID: <022fab07-52d9-e8f6-115f-fd76bb31a655@w3.org>
Date: Mon, 04 Jul 2022 15:35:02 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0
To: ietf-http-wg@w3.org
References: <b29bbf8b-25da-4abb-a310-34ad4c68d7ba@beta.fastmail.com> <b29bbf8b-25da-4abb-a310-34ad4c68d7ba@beta.fastmail.com>
Content-Language: en-US
From: Chris Lilley <chris@w3.org>
In-Reply-To: <b29bbf8b-25da-4abb-a310-34ad4c68d7ba@beta.fastmail.com>
X-W3C-Hub-Spam-Status: No, score=-12.9
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, W3C_AA=-1, W3C_DB=-1, W3C_IH=-3, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1o8LI9-009NjM-P2 42d21cf303b816327102a7ff6905fa10
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/022fab07-52d9-e8f6-115f-fd76bb31a655@w3.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/40237
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>

Martin Thomson wrote:

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

Sorry that this wasn't clear. The simulation work to explore these two 
methods is described here:

https://www.w3.org/TR/PFE-evaluation/

or you could skip to the conclusions

https://www.w3.org/TR/PFE-evaluation/#conclusions

Basically Patch Subset gives clearly *much *better performance, but does 
require an intelligent server. Range Request gives worse performance (on 
slower networks, much worse than just requesting the entire font) but 
has the single advantage that a regular HTTP server can be used without 
modification, thus aiding self-hosted fonts where the content provider 
has no control over the server configuration.

We will make sure our spec also makes this clear (I thought it did 
already, but maybe only to someone already familiar with the earlier work).

For the technical points you raise, I would prefer to see those as 
GitHub issues so we can track the discussion over time, but I did want 
to make it clear how we came to have two separate methods.

-- 
Chris Lilley
@svgeesus
Technical Director @ W3C
W3C Strategy Team, Core Web Design
W3C Architecture & Technology Team, Core Web & Media