Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt

Tom Bergan <tombergan@chromium.org> Fri, 12 July 2019 08:04 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 58CCF1201D8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2019 01:04:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 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, 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=chromium.org
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 k-I8ip4PlsdJ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 12 Jul 2019 01:04:07 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (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 6C43E120096 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 12 Jul 2019 01:04:07 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hlqUp-00054p-D4 for ietf-http-wg-dist@listhub.w3.org; Fri, 12 Jul 2019 08:01:35 +0000
Resent-Date: Fri, 12 Jul 2019 08:01:35 +0000
Resent-Message-Id: <E1hlqUp-00054p-D4@frink.w3.org>
Received: from uranus.w3.org ([128.30.52.58]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <tombergan@chromium.org>) id 1hlqUn-00052Y-46 for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2019 08:01:33 +0000
Received: from www-data by uranus.w3.org with local (Exim 4.89) (envelope-from <tombergan@chromium.org>) id 1hlqUm-0004Lx-U5 for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2019 08:01:32 +0000
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <tombergan@chromium.org>) id 1hlfbt-0001PH-TE for ietf-http-wg@listhub.w3.org; Thu, 11 Jul 2019 20:24:09 +0000
Received: from mail-yw1-xc33.google.com ([2607:f8b0:4864:20::c33]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <tombergan@chromium.org>) id 1hlfbp-0003aX-Kg for ietf-http-wg@w3.org; Thu, 11 Jul 2019 20:24:09 +0000
Received: by mail-yw1-xc33.google.com with SMTP id l79so4345609ywe.11 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2019 13:23:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kg+aYy9g8H+n6eEr78T68uUTS/QvZFlYKBmh9i0SvOY=; b=jSQ7uN1QIMyFhjR6OW/5XnVIDBezRQMlRbd6H09iQreL+6WQZ06mDym7Xr5ct6q3vz HHC/7VCRKE047TEbPPcCpKFYw50cBIPnkHI5nxcCTGxNDGpevWIwPkfwOd04t+y9FmN+ HdXwswXITriw2s7MugsMy9mFXySYZ5blMlWWk=
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=kg+aYy9g8H+n6eEr78T68uUTS/QvZFlYKBmh9i0SvOY=; b=o+CVEIt/28ypDZ4FzNlvwhcvOsTKOsACxjEpsuB+Zr7n5t5Suu4YVzFoNHGz5Jl11a 2KyoQLpcQReWNn1JyKqtYTAkmIH9yEvkBttLZriQdipsSYJIIvEc74oH7xOyaXSxUwdB 1XYweUK1qT44f9ecqpepfsPgp2kqrSk/e56W1mjB+MIQtrnoHhgQ3XCBnIx0apQOGSxe ky+lC1r301Ev2c1rxpjt2aeSw1J9naHCLGByOy9rFPJYiRUbt6jRLKHwhKPNnEazYgaJ AWnIaNZKeoyAh6ooQrYnS4vHUpIYKt13aF1Jyjth3oGQXrajdwvbrvjQU2Gh39SYqRUI hXJw==
X-Gm-Message-State: APjAAAVS+528yNrVZ89q73bOwfuxIQnYZwwV5UF9LvzNa35MNI6U5O2C eX0OiR/Uuc6GBJOG5AO237jqLiTCqso=
X-Google-Smtp-Source: APXvYqzCFzepfJxBa1rz6dk4zD289EhLzwbZzlrkfH5NjHAOZ0uw1SV2KdSnQAjxmqCmyoavgB+WVQ==
X-Received: by 2002:a81:8407:: with SMTP id u7mr3464291ywf.243.1562876622837; Thu, 11 Jul 2019 13:23:42 -0700 (PDT)
Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com. [209.85.219.180]) by smtp.gmail.com with ESMTPSA id v135sm1674313ywc.53.2019.07.11.13.23.40 for <ietf-http-wg@w3.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 13:23:40 -0700 (PDT)
Received: by mail-yb1-f180.google.com with SMTP id s41so354992ybe.12 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2019 13:23:40 -0700 (PDT)
X-Received: by 2002:a25:5d0e:: with SMTP id r14mr4046614ybb.234.1562876619758; Thu, 11 Jul 2019 13:23:39 -0700 (PDT)
MIME-Version: 1.0
References: <156259027635.887.6250697935165505332.idtracker@ietfa.amsl.com> <CANatvzy7wH=h9tsbzVF9G4Mu5P=RtUMQ1kwAad5H7gpA49Sq+g@mail.gmail.com> <CAC7UV9bTUBpTZGZz+US8cGzQ0Dj6PMqTPaY2KtyYrC-4mavgoQ@mail.gmail.com> <CANatvzz9rFcKo6BPLkDgExGghNhHckDrTHJQhAu6uLTNA-UW7g@mail.gmail.com> <CAC7UV9ZPA=8oCbVFJcJfgJ6P1-fPa95bgp087vZ1a0ETzaV=Lg@mail.gmail.com> <CANatvzzerfmPPZkhaki0YKQZgw-Y6vHx0QKTRRztd+wc_uDUYQ@mail.gmail.com> <CAC7UV9b9H17TEfs66+DPURO4oFxZtPV+12RnS5y8s2n+Yiid9Q@mail.gmail.com> <CANatvzywa1s=Wc-zO=MaFVwaUc7tY=4CZCXdpLn0AnxUthoC_w@mail.gmail.com> <CAC7UV9Zc0Urfz+beqFtMSeuy=F4NbqA8Ym=V-5n4PhvexPa-dw@mail.gmail.com>
In-Reply-To: <CAC7UV9Zc0Urfz+beqFtMSeuy=F4NbqA8Ym=V-5n4PhvexPa-dw@mail.gmail.com>
From: Tom Bergan <tombergan@chromium.org>
Date: Thu, 11 Jul 2019 13:23:28 -0700
X-Gmail-Original-Message-ID: <CA+3+x5GHB8MRa0ZEXdGb+bJ3cdTyF8xhR=as-B7EZ-FBKMNbMw@mail.gmail.com>
Message-ID: <CA+3+x5GHB8MRa0ZEXdGb+bJ3cdTyF8xhR=as-B7EZ-FBKMNbMw@mail.gmail.com>
To: Robin MARX <robin.marx@uhasselt.be>
Cc: Kazuho Oku <kazuhooku@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000c02869058d6d91e8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::c33; envelope-from=tombergan@chromium.org; helo=mail-yw1-xc33.google.com
X-W3C-Hub-Spam-Status: No, score=-4.3
X-W3C-Hub-Spam-Report: AWL=-0.228, 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 1hlfbp-0003aX-Kg 75dea4d79c1f03846e218c898b180550
X-caa-id: 1ef436a1a5
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt
Archived-At: <https://www.w3.org/mid/CA+3+x5GHB8MRa0ZEXdGb+bJ3cdTyF8xhR=as-B7EZ-FBKMNbMw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36792
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>

I agree with Robin's feedback. Echoing some of that feedback, plus adding
my own:

1. It doesn't make much sense to have one mechanism for initial
prioritization (HTTP headers) and another for reprioritization (H2/H3
frames).

2. Why not make urgency an sh-integer? This would avoid endless debates
about how many priority levels are needed. If a server doesn't want to
support 15 decimal digits
<https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-10#section-3.6>
of
priority, it can collapse that integer however it wishes. There is no MUST
requirement to strictly follow the requested ordering.

3. I'm not sure how I feel about Section 3, specifically "[...] a server is
permitted to send a 'Priority' response header field.  When used, the
parameters found in this response header field override those specified by
the client." It seems quite brazen for the server to tell the client that
they have prioritization wrong, when the client is the one who will
actually use the resource.

4. I think the "progressive" parameter is too closely tied to "progressive
images". This was called "concurrency" in Pat's proposal
<https://github.com/pmeenan/http3-prioritization-proposal#bandwidth-splitting>,
which is a better name IMO. Concurreny=0 means "FIFO preferred" and
concurrency=1 means "any order". Concurrency=1 is useful any time you don't
care about the ordering, not only when the responses "can be processed
progressively".

5. In an ideal world, the concurrency parameter is not necessary at all.
Resources with the same urgency would be served in an arbitrary order,
possibly interleaved. Ordering would be expressed through urgency levels
only. The concurrency parameter was introduced because it's difficult to
encode lengthy sequential orderings in very few bits (7 bits in Pat's
proposal). But with 15 digits, or ~53 bits, you can mimic Pat's proposal by
using the 7 upper bits for urgency and the lower ~46 bits for the FIFO
order. That is likely good enough.

On Thu, Jul 11, 2019 at 3:19 AM Robin MARX <robin.marx@uhasselt.be> wrote:

> Hello Kazuho,
>
> Yes, you are right, my apologies. Patrick's proposal recently changed to
> the approach proposed by Ian Swett in
> https://github.com/quicwg/base-drafts/pull/2700 and I was still thinking
> of the old version.
>
> I see that you have a PR that splits urgency up into about 8 numerical
> levels (https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/34),
> each with their own semantics and logic.
> This feels a bit like SPDY priorities-on-steroids and is indeed a nice
> middle ground between Patrick's 64 levels and your original 3. I still
> don't like the naming of the groups, but to settle that I guess we will
> need to resort to a duel at dawn ;)
> I've left some notes on the PR adding some additional examples to the text
> to further clarify intended usage. With something like that in, I feel it's
> a workable proposal.
>
> With best regards,
> Robin
>
> On Thu, 11 Jul 2019 at 05:46, Kazuho Oku <kazuhooku@gmail.com> wrote:
>
>>
>>
>> 2019年7月10日(水) 18:19 Robin MARX <robin.marx@uhasselt.be>be>:
>>
>>> Hello Kazuho,
>>>
>>> I agree that more extensive signaling would be research project with a
>>> medium/high turn around time.
>>> I think that there might have been a mis-interpretation from my end on
>>> that count though: I interpreted this draft as a way to be able to postpone
>>> the prioritization to after H3 / not make finishing H3 dependent on it.
>>> My assumption was that we would ship H3 with the draft-21 changes (aka:
>>> very similar to H2's setup) and then augment/extend that with this approach
>>> e.g., 6 months afterwards.
>>>
>>> Instead, if I understand you correctly, it is the intent to finish this
>>> together with H3 and expect browsers/clients to implement this together
>>> with H3 as its default (and only?) standardized prioritization option.
>>>
>>
>> Yes. That is the intent.
>>
>> My view is that if we are to have something other than the H2-based
>> design, it's beneficial to do it before or as the H3 hits the market. This
>> is because then we could use H3 as the vehicle for providing something
>> better, at the same time easing the pain of people implementing the complex
>> H2-based scheme.
>>
>>
>>> As such, it is my fear that we would be trying to rush this, to have
>>> "something" ready by the deadline, without properly testing or
>>> "researching" how it would work or if it covers all use cases. Afaict,
>>> that's going dangerously close to how we got the H2 setup in the first
>>> place...
>>> If it's the intent to have something simpler for H3 that allows for
>>> rudimentary tie-ins for server-side prioritization and that works well with
>>> existing browser setups, I feel Patrick Meenan's original proposal is far
>>> superior and more flexible than the current proposal in the draft for this
>>> purpose, while being nearly as simple/straightforward.
>>> To be clear: we could still use the "HTTP header" approach, just not the
>>> "urgency" and "progressive" aspects then (e.g., priority= level=63,
>>> concurrency=3).
>>>
>>
>> I think that there is a slight misunderstanding here.
>>
>> Assuming that the Patrick's proposal your are referring to is
>> https://github.com/pmeenan/http3-prioritization-proposal, concurrency is
>> a boolean parameter. In terms of functionality, it is identical to the
>> "progressive" parameter of the Priority header proposal.
>>
>> Therefore, the only difference between the two proposals regarding how
>> the priorities are expressed are:
>> * if each urgency has a meaning
>> * the number of the urgency levels (3 vs. 64)
>>
>> That said, I can see that just having 3 levels would be too restrictive
>> for browsers.
>>
>> If we are to propose the header-based approach as "the" priority scheme
>> for H3, I think we should try to provide a way to transplant the urgency
>> levels (that are currently internal to the browsers) to the "urgency"
>> parameter.
>>
>>
>>> Later work after the "research project" is done could then add
>>> additional header values to allow more use cases / semantics etc.
>>>
>>> With best regards,
>>> Robin
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, 10 Jul 2019 at 03:25, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>
>>>> Hi Robin,
>>>>
>>>> 2019年7月9日(火) 22:56 Robin MARX <robin.marx@uhasselt.be>be>:
>>>>
>>>>> Hello Kazuho,
>>>>>
>>>>> Thanks for the comments, most of which I agree with. The clarification
>>>>> from Lucas elsewhere that the frame could contain an "opaque encoded
>>>>> header" makes things a bit more pleasant for me.
>>>>> I have created some issues on github to further explain some of my
>>>>> points, as I feel some of your comments don't really answer my other
>>>>> reservations.
>>>>>
>>>>> 5) and 7) On the semantics of the used header names and values:
>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/27
>>>>>     My point was more general that the semantics of what you have now
>>>>> do not map (perfectly) to the semantics that are already in-place when
>>>>> talking about browser resource loading and this can create confusion down
>>>>> the road.
>>>>>     Simply clarifying what your "re-defined" blocking means does not
>>>>> help prevent confusion all that much imo.
>>>>>     With your examples at the end as well, for me you are "abusing"
>>>>> the blocking indicator to manipulate sending behaviour, rather than
>>>>> communicating the actual semantics of a blocking resource (a CSS in the
>>>>> document is still render blocking, even if it is less important than one in
>>>>> the <head>).
>>>>>
>>>>
>>>> By saying "communicating the actual semantics of a blocking resource",
>>>> I assume that you are suggesting to send something like "this is a request
>>>> initiated by a style tag in body." Generally speaking, I think signaling
>>>> that sort of signal is a good idea.
>>>>
>>>> OTOH, that's going to be a research project. I am open to defining such
>>>> signals alongside "urgency" that's being proposed by the document. OTOH,
>>>> "switching" to that approach would mean that it'd be less likely that we'd
>>>> have an alternative prioritization scheme adopted when we ship H3.
>>>>
>>>> Therefore, it is my view that what we should do now is encode the
>>>> priority levels that the browsers use today, at the same time assigning
>>>> meanings to each of the priority levels.
>>>>
>>>> We need to assign meanings so that servers can tweak the prioritization
>>>> scheme, because the server needs to know what type of resource is assigned
>>>> to each level.
>>>>
>>>> Consider the case where a server wants to send HTML before CSS (it's
>>>> not a terrible idea, that's what Chrome suggests using the H2 scheme now).
>>>> That'd be only possible when the client uses a signal like "document",
>>>> "blocking". If the signals were named like "highest" or "medium" (or "5" or
>>>> "4"), and without the knowledge of to which of the two HTML and CSS will be
>>>> associated to, it would be impossible for a server to prioritize HTML above
>>>> CSS (or in the opposite order).
>>>>
>>>>
>>>>>     Resolution to this can be as simple as re-naming the values to
>>>>> prevent confusion.
>>>>>
>>>>
>>>> We can discuss about the names.
>>>>
>>>>
>>>>> 6) On the array of use cases / semantics that can be
>>>>> represented/should be representable:
>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/28
>>>>>     You say for example that promoting an image to a hero image is not
>>>>> the intent of the example. I can then ask: how would you indicate a
>>>>> hero-image server to client then? There doesn't seem to be a way in the
>>>>> current setup to (properly) do this.
>>>>>
>>>>
>>>> You can set the urgency. For example, if the server believes that an
>>>> image is as important as the document itself in terms of "using" the
>>>> document, it can set the value of the response header to "Priority:
>>>> urgency=document." That would be the instruction to the H2/H3 terminator
>>>> that the response should be given the same priority level as the HTML.
>>>>
>>>>
>>>>>     You could say that the server simply uses its internal knowledge
>>>>> and sends that image first, but then the whole "this is usable by
>>>>> intermediates"-argument becomes less powerful.
>>>>>     I feel we should communicate as much metadata as possible back to
>>>>> the server to allow it to make complex decisions, if it so chooses. The
>>>>> server can still ignore most of the metadata if it decides to implement a
>>>>> simpler scheme.
>>>>>     In essence, the metadata communicated in the header should, imo,
>>>>> be relatively de-coupled from the concrete implementations at the server
>>>>> (and the current HTTP/2 setups)
>>>>>
>>>>> With best regards,
>>>>> Robin
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 9 Jul 2019 at 03:42, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>>>
>>>>>> Hi Robin,
>>>>>>
>>>>>> Thank you for the comments. My responses below.
>>>>>>
>>>>>> 2019年7月8日(月) 23:56 Robin MARX <robin..marx@uhasselt.be>be>:
>>>>>>
>>>>>>> Hello Kazuho and Lucas,
>>>>>>>
>>>>>>> Thank you for the draft. Most of this feedback I've given elsewhere
>>>>>>> as well, but to keep everything in one place:
>>>>>>>
>>>>>>> 1) I really like the header-based approach. It's extensible, allows
>>>>>>> us to make progress on H3, is easier to use/understand,
>>>>>>> can be "backported" to H2, has other nice properties which you touch
>>>>>>> upon in the text (intermediates, caching, etc.)
>>>>>>>
>>>>>>
>>>>>> I'm delighted to hear that.
>>>>>>
>>>>>>
>>>>>>> 2) I really dislike the header-based approach. It makes
>>>>>>> re-prioritization a mess. You don't touch upon this (yet) in the draft,
>>>>>>> but the discussion on github (
>>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/wiki/Roughing-out-reprioritization)
>>>>>>> proposes
>>>>>>> using a separate, special H3/H2 level frame to provide this. This
>>>>>>> just feels -very- dirty to me. The problem is that I can't really think
>>>>>>> of a (much) better solution, other than referring to re-prioritized
>>>>>>> resource A in resource B's headers, which is a whole other can of worms.
>>>>>>> I'm not
>>>>>>> really opposed to using the separate frame if that's the only
>>>>>>> option, but it still takes away some of the nice properties of 1)
>>>>>>>
>>>>>>
>>>>>> While I can see how you feel sad, I am not worried, because
>>>>>> reprioritization can also be HTTP-version-independent in terms of API. The
>>>>>> only difference would be how the prioritization hints (in text) are encoded
>>>>>> as frames.
>>>>>>
>>>>>>
>>>>>>> 3) I really like the switch to "absolute"/"stateless" priority
>>>>>>> levels/semantics (as you're referred to them elsewhere), as opposed to
>>>>>>> building the tree directly.
>>>>>>> This really helps for (partial) server-side (re-)prioritization. It
>>>>>>> does require the server (implementers) to know a bit more about how
>>>>>>> browsers work, but
>>>>>>> I don't really see that as a big issue (given that we provide
>>>>>>> guidance and examples on proper options)
>>>>>>>
>>>>>>
>>>>>> :+1:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 4) I don't feel the current defined priority fields+values cover the
>>>>>>> use cases though. You touch upon this in section 5.2, but I disagree with
>>>>>>> you there:
>>>>>>> For me, these new priority primitives are the core of the proposal
>>>>>>> (not the header-based approach. I would champion these new semantics in a
>>>>>>> frame-based setup as well)
>>>>>>> and imo these should be nailed down (semi-)completely before
>>>>>>> considering this approach. There should probably be more degrees of
>>>>>>> "urgency" \
>>>>>>> (e.g., as Patrick Meenan mentioned things like "deferred" and
>>>>>>> "background'), and there should maybe be something like
>>>>>>> "importance"/"weight"/"precedence"/...
>>>>>>> to be more fine-grained within resources of the same "urgency" level.
>>>>>>>
>>>>>>
>>>>>> I think that adding "deferred" is easy, assuming that we would agree
>>>>>> on the meaning. It would mean the responses that should be sent _after_ the
>>>>>> "non-blocking" responses.
>>>>>>
>>>>>> Re "background," I think we need to discuss how we want to prioritize
>>>>>> them. Should we assign it a yet lower precedence (than "deferred")? Or
>>>>>> should we state that it should be given some amount of bandwidth regardless
>>>>>> of other responses?
>>>>>>
>>>>>> As mentioned in
>>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/12,
>>>>>>> it might be good
>>>>>>> to look at the existing work on the Priority Hints spec, seeing as
>>>>>>> they probably have already looked at much of this as well.
>>>>>>>
>>>>>>> 5) I am also not sure about the interpretation of the current
>>>>>>> fields. For example, as noted by Patrick (
>>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/13),
>>>>>>> blocking has a specific meaning and it doesn't map 100% to your
>>>>>>> current text.
>>>>>>>
>>>>>>
>>>>>> I assume this to have been fixed by
>>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/14.
>>>>>> IIUC, Patrick's concern was that "blocks the processing of the document"
>>>>>> seems to be applicable to JavaScript files loaded in <BODY>. In #14 we've
>>>>>> changed the text to "blocks using the document", and I think it's clearer
>>>>>> that urgency=blocking does not necessarily apply to such JavaScript files.
>>>>>>
>>>>>>
>>>>>>> Similarly, what does progressive mean exactly? IIUC JS and CSS can
>>>>>>> be parsed/compiled
>>>>>>> in a streaming fashion in modern engines as well, it's mainly their
>>>>>>> application that is delayed until they are fully available.
>>>>>>>
>>>>>>
>>>>>> When used by a client, it is a signal that indicates if the client
>>>>>> prefers receiving the responses with the bandwidth being distributed among
>>>>>> similar responses, or if it prefers receiving the response one by one.
>>>>>>
>>>>>> Similarly, is a non-progressively encoded jpeg
>>>>>>> counted as "progressive"? How does the browser know if a JPEG will
>>>>>>> be progressive or not when making the request? I feel you've got the
>>>>>>> answers, but the usage of these
>>>>>>> specific terms can make it more difficult to actually use this
>>>>>>> scheme in practice.
>>>>>>>
>>>>>>
>>>>>> For images, a browser should set progressive to 1, when it can assume
>>>>>> that the image can be rendered progressively, as doing so improves user
>>>>>> experience.
>>>>>>
>>>>>> Servers would benefit from setting progressive to 0 for baseline JPEG
>>>>>> images, assuming that sending the first few percent of the file does not
>>>>>> improve user experience.
>>>>>>
>>>>>> Assuming that what I've stated here makes sense, I think it might be
>>>>>> a good idea to clarify these points using examples in the draft.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 6) This is also clear a bit from the example in section 3 (switching
>>>>>>> image from progressive to non-progressive). I -assume- the goal here is to
>>>>>>> do something like a "hero" image,
>>>>>>> which you want to send before other images. However, it feels to me
>>>>>>> that "abusing" the progressive field for this is not the best way to go
>>>>>>> about that.
>>>>>>>
>>>>>>
>>>>>> As stated above, that's not the intent.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> 7) Most of this comes together in the fact that I'm having a hard
>>>>>>> time thinking of how to represent existing H2 logic/browser use cases in
>>>>>>> this new scheme.
>>>>>>> E.g., how would you derive Chrome's current "dynamic fifo" from this
>>>>>>> metadata? How would you implement Patrick Meenan's proposed 'ideal' setup
>>>>>>> from these directives?
>>>>>>> Having a couple of concrete examples would help to understand your
>>>>>>> intents and probably also to ferret out some missing pieces.
>>>>>>>
>>>>>>
>>>>>> I agree that talking about mappings is a good idea. I think it would
>>>>>> be something like:
>>>>>>
>>>>>> HTML -> urgency=document, progressive=?1
>>>>>> JS, CSS in HEAD -> urgency=blocking, progressive=?0
>>>>>> images -> urgency=non-blocking, progressive=?1
>>>>>> async-loaded JS -> urgency=deferred, progressive=?0
>>>>>>
>>>>>> There's some wiggle room for fonts and JS, CSS being used inside
>>>>>> BODY. Depending on how important they seem to be, a client can set urgency
>>>>>> to "blocking" (if it essentially prevents the document from being used), to
>>>>>> "document" (if it thinks that the resources are as important as characters
>>>>>> and tags inside the HTML document), to "non-blocking" (if it thinks that
>>>>>> they are not important in terms of using the document), or even to
>>>>>> "deferred" (consider the case of a script tag at the body of the HTML
>>>>>> loading some analytic script).
>>>>>>
>>>>>> If we are to be fine with one particular approach, I think we can
>>>>>> recommend that. But we do not need to struggle to reach consensus on one
>>>>>> particular algorithm, because in the proposed approach, servers can correct
>>>>>> the precedence of mis-prioritized requests under the proposed scheme..
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> TL;DR: I see this draft as a combination of two proposals:
>>>>>>> A) a new way to define priority levels/semantics (i.e., "how will
>>>>>>> the resource be used " rather than "when should you send it") : all for
>>>>>>> this!
>>>>>>>          Needs more work though, current draft doesn't (fully)
>>>>>>> support use cases and imo, it should.
>>>>>>> B) sending those new levels via headers instead of frames: many
>>>>>>> advantages, and "feels right"
>>>>>>>         Except for the re-prioritization bit...
>>>>>>>
>>>>>>> With best regards,
>>>>>>> Robin
>>>>>>>
>>>>>>>
>>>>>>> On Mon, 8 Jul 2019 at 15:00, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Today, Lucas and I have submitted the following draft, that defines
>>>>>>>> an
>>>>>>>> HTTP header field for driving prioritization.
>>>>>>>>
>>>>>>>> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
>>>>>>>>
>>>>>>>> In short, the draft defines an end-to-end HTTP header field called
>>>>>>>> "Priority" for transmitting prioritization hints in absolute values
>>>>>>>> that have meanings. It is much simpler than the prioritization
>>>>>>>> scheme
>>>>>>>> of H2 that communicates and uses a "tree". Not only the client, but
>>>>>>>> also the server can send the prioritization hints, in order to
>>>>>>>> improve
>>>>>>>> the way the responses are prioritized. The prioritization scheme is
>>>>>>>> independent to HTTP versions; it can be used on both H2 and H3 (and
>>>>>>>> also on H1 for providing hints to intermediaries).
>>>>>>>>
>>>>>>>> For more detail, please refer to the draft.
>>>>>>>>
>>>>>>>> Background: back in May in London, the QUIC WG had a discussion on
>>>>>>>> if
>>>>>>>> porting the prioritization scheme of H2 to H3 is the way to go [1]..
>>>>>>>>
>>>>>>>> I think there were two major arguments for having something
>>>>>>>> different:
>>>>>>>> * Prioritization scheme of H2 is complex, and porting it to H3
>>>>>>>> increases the complexity [2].
>>>>>>>> * With the H2 scheme, it is hard for the server to tweak the
>>>>>>>> prioritization tree, because clients build their trees in their own
>>>>>>>> ways [3][4].
>>>>>>>>
>>>>>>>> The arguments against were:
>>>>>>>> * Redesigning prioritization for H3 is likely to delay the
>>>>>>>> standardization and time-to-market.
>>>>>>>> * Having something different in H3 is an act of "adding" complexity
>>>>>>>> to
>>>>>>>> HTTP as a whole.
>>>>>>>>
>>>>>>>> This discussion has led us to wonder if there could be a technical
>>>>>>>> solution that resolves the issues of the H2 scheme (see the pro
>>>>>>>> arguments), at the same time minimizing the downsides.
>>>>>>>>
>>>>>>>> And we came up with this proposal. I think the key selling points of
>>>>>>>> the proposal are:
>>>>>>>>
>>>>>>>> * Much simpler thanks to each request carrying an absolute priority
>>>>>>>> value. No need to synchronize a "tree".
>>>>>>>> * Because the priority value sent by the client indicates how each
>>>>>>>> request / response affects the use of other responses (e.g.,
>>>>>>>> "blocking", "non-blocking"), the server can understand the intent of
>>>>>>>> the client and further optimize the delivery order.
>>>>>>>> * Use of the HTTP header field as the conveyer of the priority value
>>>>>>>> allows an origin server to indicate hints to an intermediary that
>>>>>>>> terminates the H2/H3 connections from the client. For example, an
>>>>>>>> origin server can indicate higher precedence for some images that
>>>>>>>> matter more to the user, while giving lower precedence to others.
>>>>>>>> * Another benefit of using an HTTP header field instead of a frame
>>>>>>>> is
>>>>>>>> that prioritization logic becomes independent from HTTP versions.
>>>>>>>> That
>>>>>>>> would help both clients and servers improve the quality of their
>>>>>>>> implementation, as well as fostering website owners fine-tune the
>>>>>>>> prioritization through the use of the Priority response header.
>>>>>>>> * A header-based prioritization scheme can be improved as time goes,
>>>>>>>> as HTTP headers are extensible by their nature. It also means that a
>>>>>>>> header-based design can be rolled out at an earlier stage than a
>>>>>>>> frame-based design.
>>>>>>>>
>>>>>>>> To paraphrase, the header-based design provides simplicity,
>>>>>>>> extensibility, room to evolve, and the possibility to roll out
>>>>>>>> early.
>>>>>>>> This could be the only prioritization scheme for H3. Separating
>>>>>>>> prioritization into a version-independent approach simplifies H3,
>>>>>>>> taking some load away from QUIC WG.
>>>>>>>>
>>>>>>>> Of course, H3 needs to hit the market with a prioritization scheme,
>>>>>>>> we
>>>>>>>> need to agree on that particular scheme. But I think we might be
>>>>>>>> able
>>>>>>>> to agree on the need for a header-based prioritization scheme, that
>>>>>>>> a
>>>>>>>> server can tweak, that uses absolute priorities. If that is the
>>>>>>>> case,
>>>>>>>> I think we have fair chance on agreeing on something pretty soon.
>>>>>>>>
>>>>>>>> To summarize, with the proposed design, I think we have the chance
>>>>>>>> of
>>>>>>>> making prioritization better as we roll out HTTP/3, without getting
>>>>>>>> the standardization process delayed.
>>>>>>>>
>>>>>>>> Please let us know what you think. Thank you in advance.
>>>>>>>>
>>>>>>>>
>>>>>>>> [1]
>>>>>>>> https://github.com/quicwg/wg-materials/blob/master/interim-19-05/priorities.pdf
>>>>>>>> [2] https://github.com/quicwg/base-drafts/issues/2739
>>>>>>>> [3] https://github.com/quicwg/base-drafts/issues/2740
>>>>>>>> [4] In
>>>>>>>> https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0008.html
>>>>>>>> ,
>>>>>>>> Robin points out that server intervention is necessary for best
>>>>>>>> performance.
>>>>>>>>
>>>>>>>> ---------- Forwarded message ---------
>>>>>>>> From: <internet-drafts@ietf.org>
>>>>>>>> Date: 2019年7月8日(月) 21:51
>>>>>>>> Subject: New Version Notification for
>>>>>>>> draft-kazuho-httpbis-priority-00.txt
>>>>>>>> To: Kazuho Oku <kazuhooku@gmail.com>om>, Lucas Pardue <
>>>>>>>> lucaspardue.24.7@gmail.com>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> A new version of I-D, draft-kazuho-httpbis-priority-00.txt
>>>>>>>> has been successfully submitted by Kazuho Oku and posted to the
>>>>>>>> IETF repository.
>>>>>>>>
>>>>>>>> Name:           draft-kazuho-httpbis-priority
>>>>>>>> Revision:       00
>>>>>>>> Title:          The Priority HTTP Header Field
>>>>>>>> Document date:  2019-07-08
>>>>>>>> Group:          Individual Submission
>>>>>>>> Pages:          9
>>>>>>>> URL:
>>>>>>>>
>>>>>>>> https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-00.txt
>>>>>>>> Status:
>>>>>>>> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/
>>>>>>>> Htmlized:
>>>>>>>> https://tools.ietf.org/html/draft-kazuho-httpbis-priority-00
>>>>>>>> Htmlized:
>>>>>>>> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority
>>>>>>>>
>>>>>>>>
>>>>>>>> Abstract:
>>>>>>>>    This document describes the Priority HTTP header field.  This
>>>>>>>> header
>>>>>>>>    field can be used by endpoints to specify the absolute
>>>>>>>> precedence of
>>>>>>>>    an HTTP response in an HTTP-version-independent way.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please note that it may take a couple of minutes from the time of
>>>>>>>> submission
>>>>>>>> until the htmlized version and diff are available at tools.ietf.org
>>>>>>>> .
>>>>>>>>
>>>>>>>> The IETF Secretariat
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Kazuho Oku
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Robin Marx
>>>>>>> PhD researcher - web performance
>>>>>>> Expertise centre for Digital Media
>>>>>>>
>>>>>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>>>>>>>
>>>>>>> www.uhasselt.be
>>>>>>> Universiteit Hasselt - Campus Diepenbeek
>>>>>>> Agoralaan Gebouw D - B-3590 Diepenbeek
>>>>>>> Kantoor EDM-2.05
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Kazuho Oku
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Robin Marx
>>>>> PhD researcher - web performance
>>>>> Expertise centre for Digital Media
>>>>>
>>>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>>>>>
>>>>> www.uhasselt.be
>>>>> Universiteit Hasselt - Campus Diepenbeek
>>>>> Agoralaan Gebouw D - B-3590 Diepenbeek
>>>>> Kantoor EDM-2.05
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Kazuho Oku
>>>>
>>>
>>>
>>> --
>>>
>>> Robin Marx
>>> PhD researcher - web performance
>>> Expertise centre for Digital Media
>>>
>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>>>
>>> www.uhasselt.be
>>> Universiteit Hasselt - Campus Diepenbeek
>>> Agoralaan Gebouw D - B-3590 Diepenbeek
>>> Kantoor EDM-2.05
>>>
>>>
>>>
>>
>> --
>> Kazuho Oku
>>
>
>
> --
>
> Robin Marx
> PhD researcher - web performance
> Expertise centre for Digital Media
>
> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
>
> www.uhasselt.be
> Universiteit Hasselt - Campus Diepenbeek
> Agoralaan Gebouw D - B-3590 Diepenbeek
> Kantoor EDM-2.05
>
>
>