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

Robin MARX <robin.marx@uhasselt.be> Thu, 11 July 2019 10:19 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 87FAF12017D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2019 03:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 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.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=pass (1024-bit key) header.d=uhasselt.be
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 10w2UPFjepvS for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2019 03:18:57 -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 D45A61200D6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 11 Jul 2019 03:18:56 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hlW7I-0007e8-UF for ietf-http-wg-dist@listhub.w3.org; Thu, 11 Jul 2019 10:15:56 +0000
Resent-Date: Thu, 11 Jul 2019 10:15:56 +0000
Resent-Message-Id: <E1hlW7I-0007e8-UF@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <robin.marx@uhasselt.be>) id 1hlW7G-0007dM-Ly for ietf-http-wg@listhub.w3.org; Thu, 11 Jul 2019 10:15:54 +0000
Received: from mail-lj1-x22b.google.com ([2a00:1450:4864:20::22b]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <robin.marx@uhasselt.be>) id 1hlW7C-0003p0-ER for ietf-http-wg@w3.org; Thu, 11 Jul 2019 10:15:54 +0000
Received: by mail-lj1-x22b.google.com with SMTP id h10so5196981ljg.0 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2019 03:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uhasselt.be; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OmnTNa199Mzma7VoUZlxuEGJnrnE+XrFxg9vCpFHWh4=; b=U21AQIIionybXxqkzO4gsWxaxEJfWfdOHobr5VvJcSpgH/ir4xXxb/P82rfeD5ghni 5huoagDHjoLRG7S2YiQkPj0UWilIAjFSWKgzqjwICuLIyYFo2m+GoE/kRvCQhxlmW0Dl 0XY+DrP3kAyFAFIWqJ0QEXg4g7/macrttTfP0=
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=OmnTNa199Mzma7VoUZlxuEGJnrnE+XrFxg9vCpFHWh4=; b=iivaxiggiz2167CqNaexPtv7JFoQkUPj+1Gw2DTxvqmQEAog9RfKKPydO5sysweuZo z5mKTjfgqnn7Bbo1m6MCzSjxv/S5SHgjGpT56/GR/8wMOhkLJsztVpHZFwXY2/JWoT8u 5Qe/Kw7X96VyNdndoSk5obAVQBNkIYcq2T5QlEEW6GUnlD0n6AVNserCM51voAk1z1uH fO1R+aFnGeXnG1lmy04ZOh6ErGRcEMxcY2vom6YhbP1u/6JuCjBFMHrpSsZnx9QoOsuB j5Vwit+Qe0ey03hZaJ++FCAefosI4RFbk6XjK3/AmrT/tMqlC6E2k2IzC6nvNCNZPdeJ JE3A==
X-Gm-Message-State: APjAAAXpL5wmVVottmt7Bx7vAW+P0M+JmYh4hNL8JVf+2KVGZR9QViHv M6/8bOMlPXvBjqbrU0foFQdOicMIIf5GP9wABGiJjYEEMy0=
X-Google-Smtp-Source: APXvYqwUPG0R/T7oHLg0CTbnniMzVs8qmODgBBGi43C05PnXHCnNAb3+VGgA/LqIx1O22KewlehH76lhRUUdmVclnQM=
X-Received: by 2002:a2e:4794:: with SMTP id u142mr2010141lja.222.1562840127711; Thu, 11 Jul 2019 03:15:27 -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>
In-Reply-To: <CANatvzywa1s=Wc-zO=MaFVwaUc7tY=4CZCXdpLn0AnxUthoC_w@mail.gmail.com>
From: Robin MARX <robin.marx@uhasselt.be>
Date: Thu, 11 Jul 2019 12:15:16 +0200
Message-ID: <CAC7UV9Zc0Urfz+beqFtMSeuy=F4NbqA8Ym=V-5n4PhvexPa-dw@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000a7402f058d6512d3"
Received-SPF: pass client-ip=2a00:1450:4864:20::22b; envelope-from=robin.marx@uhasselt.be; helo=mail-lj1-x22b.google.com
X-W3C-Hub-Spam-Status: No, score=-3.8
X-W3C-Hub-Spam-Report: AWL=0.338, 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: mimas.w3.org 1hlW7C-0003p0-ER 90ee53e072026298953e5fdb51448796
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/CAC7UV9Zc0Urfz+beqFtMSeuy=F4NbqA8Ym=V-5n4PhvexPa-dw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36789
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>

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