Re: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)

Barry Pollard <barry@tunetheweb.com> Tue, 16 June 2020 16:50 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 0C8CE3A0400 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Jun 2020 09:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=tunetheweb.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 Gz5FKPkBe4SP for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Jun 2020 09:50:48 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C603A00C1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Jun 2020 09:50:48 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1jlEl5-0000QC-SQ for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Jun 2020 16:48:24 +0000
Resent-Date: Tue, 16 Jun 2020 16:48:23 +0000
Resent-Message-Id: <E1jlEl5-0000QC-SQ@lyra.w3.org>
Received: from www-data by lyra.w3.org with local (Exim 4.92) (envelope-from <barry@tunetheweb.com>) id 1jlEkw-0000LI-BQ for ietf-http-wg@listhub.w3.org; Tue, 16 Jun 2020 16:48:14 +0000
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <barry@tunetheweb.com>) id 1jl5Hq-0006v7-I7 for ietf-http-wg@listhub.w3.org; Tue, 16 Jun 2020 06:41:34 +0000
Received: from mail-lj1-x229.google.com ([2a00:1450:4864:20::229]) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <barry@tunetheweb.com>) id 1jl5Ho-0005tz-Rl for ietf-http-wg@w3.org; Tue, 16 Jun 2020 06:41:34 +0000
Received: by mail-lj1-x229.google.com with SMTP id z9so22113863ljh.13 for <ietf-http-wg@w3.org>; Mon, 15 Jun 2020 23:41:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tunetheweb.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mBEIdbFEd6Vh9Q2fWImmJNxLsHqVBtGqi/15+NHDMxY=; b=b9bVgN8c74aM+pdAUWWbPZGk05cMCuFP0caJks2A0VqtDgWv3jBkm8nXwSkehS1JGC wOeImZ7xEUUSmzFvogUVzizpAbHxzHxx0Dh3XuSpyzPca2e50MvINafCVtdO7uRH1EQn lEyfKLwy1EESKJVBk0XAcZi9uJY7e5/S+Md8c=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mBEIdbFEd6Vh9Q2fWImmJNxLsHqVBtGqi/15+NHDMxY=; b=KVva6gCGN0zWFYWqKVOc77kuynXiGhMf0qsyPt0YxGX6acsoCTMAjpgbiCSQ2ZqqRm EidH/xqateYUAiBhj5/wpj9USJCJbU8sOb234QnEeHJK2C3MdbWqj1GxbS3Tn4ica8hm Xe1SZ1ZFgKsIksihFkobtljtdeJaeW7v5ipKHzHZ7dp6qfsdW/Pc4cdjuOvTnO2JmMhN 0Ikaoc7jXOKyGxQO0FxxJWHfnfDSweTHRkmriPFxN55rhUJidmL697LHeABuqPbtH7oY 0mipUNVjDAvF8q2Q8sNeMxk298lvlRST5ab/0QJYHtlcWllAPCUPsNJqzezkVK6aPYH0 xi0Q==
X-Gm-Message-State: AOAM530mybwxwS2xXCMcCOJwIaCcBFsuasGnJoebat/RhO3/blXD7ZdU ZplzLQiwNuOcsLGyoBjeTmKWYtIJN6Y41JEzP3iTJ/ucz4v1wg==
X-Google-Smtp-Source: ABdhPJzktl1Wd/QvrJUVYn1+Mubw1Y3iWBsVEGRgZE9zaEiSDfrX52yqPSCN2zcPmMdbKb8Evgm6f0CZgl0QiFOFWvg=
X-Received: by 2002:a2e:22c2:: with SMTP id i185mr733073lji.200.1592289680582; Mon, 15 Jun 2020 23:41:20 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9obRjBSADN1KtKF6jvFVzNS1+JzaS0D0kCVKHKkd4sn+MQ@mail.gmail.com> <459C86F8-A989-4EF4-84DC-3568FF594F36@apple.com> <CANatvzwSpSHd7kZD-4tyMGkBJDdCBi6r_pLBvnaT8rrQy6SBHQ@mail.gmail.com> <CACMu3treK0m2mbpw9FebOjOcEed0bW-DbLbryHJH1DWAHoz+9g@mail.gmail.com> <CALGR9oZgE7ZfXdoYdUh9LUYC1fi8fMUyyTpvmV3GF7Z6Oxgg1g@mail.gmail.com> <20200609144428.GC22180@lubuntu> <CAJV+MGyuhxx=P6kZKktuREeq5pipZjxmwWP4jE_Sxhj_+krU2Q@mail.gmail.com> <CANatvzx_eg84V7UefOtSF+NHGHnTg7h-9n5bsRZRXxBqsaOkfQ@mail.gmail.com> <CACj=BEip6+7AunFsD=6qM5rsgrTfg6bRctOMu1gOe-KVjAW7Dw@mail.gmail.com> <CANatvzyv03VH9=+J=M2yY0EwCXp7HMWsXYaXOE=WYGDKBHdaVA@mail.gmail.com> <2C53D8AF-EFA8-42A3-9666-955A054468DB@greenbytes.de> <CACj=BEic2qzMXEfcsKS9CYnowChc-kMRjH66d3uKs+pqTz9Fug@mail.gmail.com> <4E0E8032-A903-46A2-A131-F1F4DE3CC037@greenbytes.de> <CACj=BEjOC-8S38U36Jw+Yb7yH_BZjxBkeLE6dLWH=8VMyBW80Q@mail.gmail.com> <ECF2C350-5D53-4E3B-9AAC-2F7E3FD4B528@greenbytes.de> <CACj=BEh53ZWj1UV6tNDaWPiuHbmbVmkYimu_rdYcYm06dZJAAQ@mail.gmail.com> <CAJV+MGzesbFRZFGK5SUM70HJrx3fdJ8AAGGqmwqDQhrL3eFmUw@mail.gmail.com> <CACj=BEiVPfOPGPuSu-tx5AovWwvTEwjCTqEooMq2muEteHZLAw@mail.gmail.com> <CAJV+MGyrKyhamN3WY+HE1i_0hKWQo6kuLe-6hO53YMrHPbto=w@mail.gmail.com> <CAM37g06T_U+Th83D7sH3S_LB-b_9TcaX5b9nDSFE8Z-x5U+c9A@mail.gmail.com> <CANatvzwEr97ec5h=YOZopFt2ou+vabthD+YMRwh0aESKy2jkkA@mail.gmail.com>
In-Reply-To: <CANatvzwEr97ec5h=YOZopFt2ou+vabthD+YMRwh0aESKy2jkkA@mail.gmail.com>
From: Barry Pollard <barry@tunetheweb.com>
Date: Tue, 16 Jun 2020 07:40:45 +0100
Message-ID: <CAM37g05x7hZ=AfAicFHmPBxtz4VJhH14cCF2MKcRpfvq4_y1Cw@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Bence Béky <bnc@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucaspardue.24.7@gmail.com>, Patrick Meenan <patmeenan@gmail.com>, Stefan Eissing <stefan.eissing@greenbytes.de>, Yoav Weiss <yoav@yoav.ws>
Content-Type: multipart/alternative; boundary="000000000000ca7f1d05a82dd434"
Received-SPF: pass client-ip=2a00:1450:4864:20::229; envelope-from=barry@tunetheweb.com; helo=mail-lj1-x229.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1jl5Ho-0005tz-Rl c6f0f79a05f1312ea4a1466110274b19
X-caa-id: 5eb0363da7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Priority implementation complexity (was: Re: Extensible Priorities and Reprioritization)
Archived-At: <https://www.w3.org/mid/CAM37g05x7hZ=AfAicFHmPBxtz4VJhH14cCF2MKcRpfvq4_y1Cw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37773
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>

On Tue 16 Jun 2020 at 01:06, Kazuho Oku <kazuhooku@gmail.com> wrote:

>
> In such a deployment, I would argue that the H3 reverse proxy should
> respect the priorities when choosing a request from the queue, regardless
> of the prioritization signal being initial or reprioritization. Otherwise,
> the H3 reverse proxy would end up providing responses to requests mostly in
> the order of the requests being issued.
>

That I agree with. But some prioritisation choices are discrete - for
backend requests the request is either queued or sent to back end or
completed by the backend. I wouldn’t try to interrupt that after it’s been
sent to the back end. So you use the best prioritisation signals available
at the time when choosing which request to the backend.

If 8 items come in at medium priority and they all require back end calls,
and we can only have 8 backend resources in flight at same time, then send
them. If a 9th high priority request then comes in while those 8 are being
processed then tough - there are no free slots to the backend for that
request despite it being high priority - those backend slots were filled
with the best prioritisation signals available at the time.

Of course if 10 items need backend resources, with differing priorities,
then use that priorities to decide which 8 of those to send first. But I’m
Just saying this is less likely to happen until all the back end slots are
filled because 10 things do not come in at once - they come in one by one
and I’d argue they should be sent to the back end ASAP and then left to
complete, rather than holding back requests or interrupting requests
already sent to back end. So initially, until all backend slots are filled,
prioritisation is not used here because effectively there is no queue
initially.

Either way, after the back end process is complete for one or more requests
and returned to the web server, we’ve another queue of bytes to return to
the browser and so another opportunity to use prioritisation to select
which stream’s bytes to send back.

Basically what I’m saying is only use prioritisation when there’s a queue
and a choice to be made.

However, as there is more likely to be queuing on the final return step to
the client, we’ll end up using prioritisation more there (which is no bad
thing!).