IETF Logo Mail Archive

Re: Is a faithful HTTP/2 response scheduler necessarily O(n) in the worst case?

Kazu Yamamoto ( 山本和彦 ) <kazu@iij.ad.jp> Wed, 25 January 2017 04:08 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 733611296A3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 24 Jan 2017 20:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.22
X-Spam-Level:
X-Spam-Status: No, score=-10.22 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.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-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=iij.ad.jp
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 pXDb7-f3p1cR for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 24 Jan 2017 20:08:32 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C701296A0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 24 Jan 2017 20:08:31 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cWEpM-0003iD-VE for ietf-http-wg-dist@listhub.w3.org; Wed, 25 Jan 2017 04:04:56 +0000
Resent-Date: Wed, 25 Jan 2017 04:04:56 +0000
Resent-Message-Id: <E1cWEpM-0003iD-VE@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazu@iij.ad.jp>) id 1cWEpH-0003hS-B8 for ietf-http-wg@listhub.w3.org; Wed, 25 Jan 2017 04:04:51 +0000
Received: from mo900.iij.ad.jp ([202.232.31.76] helo=omgo.iij.ad.jp) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <kazu@iij.ad.jp>) id 1cWEpA-0000tD-W8 for ietf-http-wg@w3.org; Wed, 25 Jan 2017 04:04:46 +0000
DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Subject:From:In-Reply-To:References:Mime-Version:Content-Type: Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1485317061; x=1486526661; bh=V9yhtZUfl7TmkI3o5qgsgJw+Cc5VoBd1y+XVEU4/jvs=; b=cxQ4oKZwHomUDzY+jaY3wArwNa2 ZVr52PDSovewlJ3kBHIplsH6koUBxqAFMwSNHGYD9oM6MBq4Oo9+0pg4sMN63jzh/ks+DMDRGLm/H wfFEk7WvycstVm1REz06ZYP81TMuwR6IeAFQ6qaIknXEvbfO8On99W0ihlTYm0syyI3uh/udM0xK2 bwxrh6Q/az8fVO39vpmZI+NUmwG4y1rX3clTjYavS0EA5OSEegZI+roSS4l9mqf3SnkI3X0ApYDaO oA9/isXdWRjzDIJ5ruH0CR4m6uabG9+nDflRVs6JRUi3uY45ngI6oQN++tishgq+X22/+zytlc9Io N8bjREQ==;
Received: by omgo.iij.ad.jp (mo900) id v0P44K8g023567; Wed, 25 Jan 2017 13:04:20 +0900
X-MXL-Hash: 588823c457b2deba-41cbbaafea73ee220c85e1047adfa1a31e364e7c
Date: Wed, 25 Jan 2017 13:03:58 +0900
Message-Id: <20170125.130358.1140782660246356035.kazu@iij.ad.jp>
To: ietf-http-wg@w3.org
From: Kazu Yamamoto <kazu@iij.ad.jp>
In-Reply-To: <CA+3+x5GiJO0s6kjXofEicDdAimrz7eBC5vvX9Z+P0MNQGnA_Rg@mail.gmail.com>
References: <CA+3+x5EdkLSAR2gWR9TT72o2Tg4Z_xKXMh8yVREYD7mvNuLB8w@mail.gmail.com> <20170125.075510.1795999132739277437.kazu@iij.ad.jp> <CA+3+x5GiJO0s6kjXofEicDdAimrz7eBC5vvX9Z+P0MNQGnA_Rg@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 25.1 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=202.232.31.76; envelope-from=kazu@iij.ad.jp; helo=omgo.iij.ad.jp
X-W3C-Hub-Spam-Status: No, score=-7.1
X-W3C-Hub-Spam-Report: AWL=0.092, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1cWEpA-0000tD-W8 d7f2c20179cab266c628ebfeab96dcaf
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Is a faithful HTTP/2 response scheduler necessarily O(n) in the worst case?
Archived-At: <http://www.w3.org/mid/20170125.130358.1140782660246356035.kazu@iij.ad.jp>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33375
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi Tom,

> Why is that a misuse of priority? It seems entirely reasonable for a client
> to specify a mostly-linear order. There is a very good reason for this:
> inside HTML pages, CSS links and synchronous scripts must be evaluated in
> the order they appear in the HTML file. This implies that the server should
> send those resources in a linear order. This is exactly the rationale
> behind Chrome using mostly-linear orders. (This is not to say that
> mostly-linear orders are not occasionally problematic -- they are
> <https://bugs.chromium.org/p/chromium/issues/detail?id=651538#c1> -- but
> there are good reasons to linear orders at least some of the time.)

Thank you for your explanation.
I did not know this use case.
So, I would like to withdraw my previous word "misuse".

--Kazu

v2.23.0 | Report a Bug | By Email