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

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.)

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)

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)

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. 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. 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. 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.

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.

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.


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>, 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