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!).
- Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Extensible Priorities and Reprioritization Eric Kinnear
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Martin Thomson
- Re: Extensible Priorities and Reprioritization Bence Béky
- Priority implementation complexity (was: Re: Exte… Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Dmitri Tikhonov
- Re: Priority implementation complexity (was: Re: … Roy T. Fielding
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Extensible Priorities and Reprioritization Kinuko Yasuda
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Martin Thomson
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Stefan Eissing
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Patrick Meenan
- Re: Priority implementation complexity (was: Re: … Kazuho Oku
- Re: Priority implementation complexity (was: Re: … Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Priority implementation complexity (was: Re: … Barry Pollard
- Re: Extensible Priorities and Reprioritization Kazuho Oku
- Re: Extensible Priorities and Reprioritization Yoav Weiss
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Priority implementation complexity (was: Re: … Tom Bergan
- Re: Priority implementation complexity (was: Re: … Lucas Pardue
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Patrick Meenan
- Re: Extensible Priorities and Reprioritization Lucas Pardue
- Reprioritization - implementation intent Mark Nottingham
- Re: Reprioritization - implementation intent Eric Kinnear
- Nice to have guidance (was: Re: Reprioritization … Lucas Pardue
- Re: Nice to have guidance (was: Re: Reprioritizat… Eric Kinnear
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss
- Re: Reprioritization - implementation intent Yoav Weiss