Re: New Version Notification for draft-kazuho-httpbis-priority-00.txt
Kazuho Oku <kazuhooku@gmail.com> Fri, 12 July 2019 00:35 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 162E31200C7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2019 17:35:51 -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 (2048-bit key) header.d=gmail.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 71yTYB65lPwZ for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 11 Jul 2019 17:35:45 -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 76C1212009C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 11 Jul 2019 17:35:45 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hljUt-0001yn-Lz for ietf-http-wg-dist@listhub.w3.org; Fri, 12 Jul 2019 00:33:11 +0000
Resent-Date: Fri, 12 Jul 2019 00:33:11 +0000
Resent-Message-Id: <E1hljUt-0001yn-Lz@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 <kazuhooku@gmail.com>) id 1hljUr-0001xZ-GH for ietf-http-wg@listhub.w3.org; Fri, 12 Jul 2019 00:33:09 +0000
Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <kazuhooku@gmail.com>) id 1hljUn-000535-A1 for ietf-http-wg@w3.org; Fri, 12 Jul 2019 00:33:09 +0000
Received: by mail-lj1-x22f.google.com with SMTP id x25so7626846ljh.2 for <ietf-http-wg@w3.org>; Thu, 11 Jul 2019 17:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BHGqBM3dwvQjvku0UWCxx42WvzTzKTeoPDOWtWVRfw0=; b=jPDExVhrSdFJeOHWoVJ0IaElNxVNebmdVxAJXtSReoCnc13m44qCMqIn9OzWt3dD6u qgVxn/8ExGo9ECkBskPOD/GF4yNC1P7fKYIv/S9cSi7JgihtZ45TO2225/dQyV7TJZk/ rjDoVTAJtWwOpdSR/0J7B3bISPy5OE2Nyxue7yGZRgQRn0TAzTnrqlSMLjFZcj4biRGG hDpw/oahRfh0yjf7jCWqlmxakSo+BDL7eA0CDUBaxDH8c+1ptbzCFzgXFWwNB7xZRuvG yh/2kBTL6FdFAzBshuBmZvgUv6+QdkypmmEo+KYm5T3WY/KH1FIrr3r2yzFxb6qg8F/P ++sQ==
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=BHGqBM3dwvQjvku0UWCxx42WvzTzKTeoPDOWtWVRfw0=; b=uKQYp4I1Tncan73CWSjv8rnROx9ka5YsnacZ/6CR6AfgK+2P0MGpPTaziZzms6i1xy XnzOKFaxV3h3zruYAwYb9DHsjrV10pj+VZ5QX7SQj4I0f+BiusYALSN5ncmThpst6Qsi DMglv32vj+/LgJiUoLHDOTf9qcdTvFgGAh5ihRV9BMa2u5r86kt7letM+4Mx+eDSy7JK bhJcBlLMFY9KwFO8YC/ihFh1yj14Sqw/iH9ep83YqLd4rYz3uPQOjmddmxQHas0xifNy iGtIQKvAbhCGYrzXR98yFk5x2NliSje+bSdxUes4KTvddTh9AZivfAuxWShR1fnhpXz0 hwUw==
X-Gm-Message-State: APjAAAXmNraPZTGqEaZBXh3MmyyQLlUC0HcCbDfDBai3rQl80a4SpwPk 2/r4UT2sX8SsAT2qAX65FbRRN/TaPvcxRvF+jzpjXCXY
X-Google-Smtp-Source: APXvYqwijj3CUk/5eLgxAsVepVXID0cDV+ySPHhLgg6kKb6jxXlPumSDygDiIOPE21LaptVw6JlAfDQJWgthnrdLPNk=
X-Received: by 2002:a2e:124b:: with SMTP id t72mr4193251lje.143.1562891561498; Thu, 11 Jul 2019 17:32:41 -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: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 12 Jul 2019 09:32:30 +0900
Message-ID: <CANatvzy9UGY=+q=mU6+OEWuZiKk_rz3En983QRFEnW=K1fp5HA@mail.gmail.com>
To: Robin MARX <robin.marx@uhasselt.be>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000587cc5058d710cf7"
Received-SPF: pass client-ip=2a00:1450:4864:20::22f; envelope-from=kazuhooku@gmail.com; helo=mail-lj1-x22f.google.com
X-W3C-Hub-Spam-Status: No, score=-2.8
X-W3C-Hub-Spam-Report: AWL=1.332, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 1hljUn-000535-A1 a6d153c380f370a3d1dfe8353ceeb567
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/CANatvzy9UGY=+q=mU6+OEWuZiKk_rz3En983QRFEnW=K1fp5HA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36790
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>
Hi Robin, 2019年7月11日(木) 19:15 Robin MARX <robin.marx@uhasselt.be>: > 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. > I'm glad to hear that, and more importantly, thank you for the detailed feedback. I think that PR #34 is becoming much more mature thanks to your comments, and I'm feeling more confident that it is the correct approach. > > 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>: >> >>> 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>: >>>> >>>>> 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>: >>>>>> >>>>>>> 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>, 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 > > > -- Kazuho Oku
- Fwd: New Version Notification for draft-kazuho-ht… Kazuho Oku
- Re: New Version Notification for draft-kazuho-htt… Robin MARX
- Re: New Version Notification for draft-kazuho-htt… Kazuho Oku
- Re: New Version Notification for draft-kazuho-htt… Robin MARX
- Re: New Version Notification for draft-kazuho-htt… Kazuho Oku
- Re: New Version Notification for draft-kazuho-htt… Robin MARX
- Re: New Version Notification for draft-kazuho-htt… Kazuho Oku
- Re: New Version Notification for draft-kazuho-htt… Robin MARX
- Re: New Version Notification for draft-kazuho-htt… Kazuho Oku
- Re: New Version Notification for draft-kazuho-htt… Kazuho Oku
- Re: New Version Notification for draft-kazuho-htt… Tom Bergan
- Re: New Version Notification for draft-kazuho-htt… Kazuho Oku
- Re: New Version Notification for draft-kazuho-htt… Roy T. Fielding
- Re: New Version Notification for draft-kazuho-htt… Tom Bergan
- Re: New Version Notification for draft-kazuho-htt… Patrick Meenan
- Re: New Version Notification for draft-kazuho-htt… Tom Bergan
- Re: New Version Notification for draft-kazuho-htt… Lucas Pardue
- Re: New Version Notification for draft-kazuho-htt… Kazuho Oku