Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4290C12004A for ; Sat, 17 Aug 2019 07:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 SKxWR3lZUPTO for ; Sat, 17 Aug 2019 07:10:38 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E032912002E for ; Sat, 17 Aug 2019 07:10:37 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id z11so4260046wrt.4 for ; Sat, 17 Aug 2019 07:10:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=itlyVit/83ShGA9UlMZCc+bkIXSGJ83XTNb9MLAYM8Q=; b=DEw6f5pXHC81kVDT63go/vDAVKCUpAcUlLzEbSz/tPBq/4kAU7sDeR0fXhE9YztxBx SnVpAObLbYH5K8iFeH41FypzEuI4zWlKPZLpiCmXYilrjK9tSf2FBVYHxGs1+riRYDOj uBtbtiKq+7Yn6i4RHLcJ+RJi1IVguJSW+zNWCDeeCLrIqjkk8IqlgDdcK6aW+AP31/1y ZsN1STf3VYJeK/j7eEbjnKJIEVIRrr/AlgJfMwZhsiH56/pi1cAhoOBT87Mtn3BBMixg 01ajdNpWW7lDP0cAtZmOikJZ7T160blLgq7nPoXsA3ss5nHPn4lWbyZrQUU+xr0XEpwM z1lg== 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=itlyVit/83ShGA9UlMZCc+bkIXSGJ83XTNb9MLAYM8Q=; b=LNH5/dooLpZ+19wgkUVfXt0aH34/2KvVd0CQyqrR3MTk1f/yP6BOofCLbR35pKFQ7e x1G2LqIMMD6522k+i5yWQND9cHVkgXolTkD5H1e3vSDbRTqdfuiHWzR7L1c7W1hm+29p sLgdLZ7D36MmnMscfKffG2I68ewt7EPz4ho+JFPa59I6ObATNstHbzKLzoQqmoJ8S1G6 Kj7SAuSdiFrWfqv50Z0hm8DSsJUdChChg4LYZgmHndFb/ZT1OORSUWiRK6XQuI4ikbtD lQZGDmm+/uM/U8TedjMaFIzzHoMkL/pn/kpi92rWFfKRSFHmsLgW18ug0fk446vKFRe+ 0EAg== X-Gm-Message-State: APjAAAX98EFW67GEHn8jGb91lxcUh3xXGNkWEG4SQ4DlBySliW+GCjXQ N/mmb0oW9vu4UwgXWeypcIrBz96if/BRE2A5rZm9hw== X-Google-Smtp-Source: APXvYqxJq8phfl/vGmw7voOgyb4oDZ8I+kRi0Kded2Ug9Ukcv+Nlr6jNWdKZOolaRqEruk+p+MB7ywGyELQcDBge+FQ= X-Received: by 2002:adf:afe7:: with SMTP id y39mr16110935wrd.350.1566051035953; Sat, 17 Aug 2019 07:10:35 -0700 (PDT) MIME-Version: 1.0 References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> In-Reply-To: From: Ryan Hamilton Date: Sat, 17 Aug 2019 07:10:23 -0700 Message-ID: Subject: Re: Call for consensus: HTTP/2 Priorities To: Robin MARX Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000b33b01059050ab69" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Aug 2019 14:10:41 -0000 --000000000000b33b01059050ab69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with the proposal of removing HTTP/2 priorities from HTTP/3. HTTP/2 Priorities are overly complicated for the task at hand (as the implementation experience with HTTP/2 suggests). I look forward to the priority design team's output. On Sat, Aug 17, 2019 at 6:54 AM Robin MARX wrote: > At the risk of repeatedly screaming into the void: > > I do not have a problem with the removal of HTTP/2-style priorities per > se. The setup is certainly quite complex and can be simplified in terms o= f > implementation. > However, the dependency tree is also very flexible and able to represent = a > wide variety of different prioritization schemes. > That this flexibility has been severely under-utilized to this day, does > not necessarily mean it's not needed in my opinion. > And sure, we can drop it now, ship with something simple, and move to a > more complex/flexible setup again down the road once we have more insight= s. > > However, that latter point is still not what seems to be on the table > here. I still feel like we're proposing dropping priorities completely > right now and -maybe-, > just maybe (NOT *necessarily *as Mark says*)* shipping H3 with some form > of priorities on-board (i.e., "priorities should not block H3"). The way = I > see this going forward > is that many people just won't bother implementing any prioritization > concept until it's clear what will end up chosen (and it's in the spec). > Consequently, people will keep testing QUIC stack performance without > caring about multiplexing (much): downloading a single file over a single > stream, > which imo is only part of the equation. I see us ending up with shipped > implementations that don't have decent prioritization support, this time > not because they can't > be bothered to implement a dependency tree, but simply because nobody tol= d > them they should. Thus we run the risk of H3 performing worse than H2. > > As such, I am not really in favor of removing priorities from the spec > until we have a replacement. Or if we do, I feel priorities should block = H3 > (even if it's just for a simplified setup). > > > I really feel we're sticking our heads in the sand on this. We've been > ignoring HTTP priorities for too long (otherwise we wouldn't be in this > current mess). Next to that, > we've also been ignoring QUIC-level priorities (with the very vague > https://tools.ietf.org/html/draft-ietf-quic-transport-22#section-2.3 as > only indication). I've asked this > of multiple implementers on multiple occasions and no one had a concrete > idea of how they will/should be mapping application-layer priorities to > QUIC stream priorities yet. > People seem to expect this to somehow resolve itself or that it can be > bolted on as an afterthought, and maybe it will/can, but I doubt it. > > The only other conclusion I can draw from all this, is that priorities > don't really matter in the big picture. I certainly see enough indicators > to that end. For example Microsoft Edge > not bothering to use them in the first place. For example browsers not > seeming to a/b test optimal approaches for over 4 years. For example, som= e > people advocating that "passive" > resource request order + content-type is enough of a signal in itself to > provide good page loading performance. For example, people proposing not > letting them block H3. > This viewpoint is 100% contradictory to my own prioritization research an= d > my understanding of current web page building techniques. Maybe I'm missi= ng > things others take for > granted. Maybe I'm making mistakes. Maybe priorities are not the > cornerstone of a multiplexed protocol that I view them to be. In that cas= e, > by all means go ahead and continue > down this proposed route, as it indeed seems the best way forward. If not= : > please give them the attention they deserve. > > With best regards, > Robin > > > On Sat, 17 Aug 2019 at 14:10, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > >> +1 >> >> >> On 17 August 2019 at 00.08.06, Jana Iyengar (jri.ietf@gmail.com) wrote: >> >> +1 to removing the current priorities from HTTP/3. >> >> On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham > > wrote: >> >>> In Montreal, we had a discussion about priorities, where the outcome wa= s >>> that people in the room agreed to defer to the HTTP Working Group regar= ding >>> whether HTTP/3 should ship with something compatible with HTTP/2 priori= ties >>> in it: >>> >>> https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h= 3-priorities >>> >>> Since then, the HTTP Working Group has come to consensus that it does >>> not believe we should do so: >>> https://www.w3.org/mid/00CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net >>> >>> This consensus call is to confirm this approach in this WG. In practica= l >>> terms, it means we will remove the current HTTP/2-aligned priorities >>> machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will sh= ip >>> without any form of priorities; just not this one. Doing so will resolv= e a >>> number of outstanding issues, and make way for a replacement scheme, >>> currently under discussion in a design team in the HTTP Working Group. >>> >>> Please respond by the middle of next week; we'd like to move forward >>> with this resolution. >>> >>> Kind regards, >>> >>> -- >>> Mark Nottingham https://www.mnot.net/ >>> >>> > > -- > > 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 > > > --000000000000b33b01059050ab69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with the proposal of removing HTTP/2 priorities=C2= =A0from HTTP/3. HTTP/2 Priorities are overly complicated for the task at ha= nd (as the implementation experience with HTTP/2 suggests). I look forward = to the priority design team's output.

On Sat, Aug 17, 2019 at 6:54= AM Robin MARX <robin.marx@uha= sselt.be> wrote:
At the risk of repeatedly screaming into the void:=

I do not have a problem with the removal of HTTP/2-styl= e priorities per se. The setup is certainly quite complex and can be simpli= fied in terms of implementation.
However, the dependency tree is = also very flexible and able to represent a wide variety of different priori= tization schemes.
That this flexibility has been severely under-u= tilized to this day, does not necessarily mean it's not needed in my op= inion.=C2=A0
And sure, we can drop it now, ship with something si= mple, and move to a more complex/flexible setup again down the road once we= have more insights.=C2=A0

However, tha= t latter point is still not what seems to be on the table here. I still fee= l like we're proposing dropping priorities completely right now and -ma= ybe-,=C2=A0
just maybe (NOT=C2=A0necessarily as Mark says<= i>) shipping H3 with some form of priorities on-board (i.e., "prio= rities should not block H3"). The way I see this going forward=C2=A0
is that many people just won't bother implementing any priorit= ization concept until it's clear what will end up chosen (and it's = in the spec).=C2=A0
Consequently, people will keep testing QUIC s= tack performance without caring about multiplexing (much): downloading a si= ngle file over a single stream,=C2=A0
which imo is only part of t= he equation. I see us ending up with shipped implementations that don't= have decent prioritization support, this time not because they can't= =C2=A0
be bothered to implement a dependency tree, but simply bec= ause nobody told them they should. Thus we run the risk of H3 performing wo= rse than H2.=C2=A0

As such, I am not really in fav= or of removing priorities from the spec until we have a replacement. Or if = we do, I feel priorities should block H3 (even if it's just for a simpl= ified setup).


I really feel we'= re sticking our heads in the sand on this. We've been ignoring HTTP pri= orities for too long (otherwise we wouldn't be in this current mess). N= ext to that,
we've also been ignoring QUIC-level priorities (= with the very vague=C2=A0https://tools.ietf.org/htm= l/draft-ietf-quic-transport-22#section-2.3=C2=A0as only indication). I&= #39;ve asked this
of multiple implementers on multiple occasions = and no one had a concrete idea of how they will/should be mapping applicati= on-layer priorities to QUIC stream priorities yet.=C2=A0
People s= eem to expect this to somehow resolve itself or that it can be bolted on as= an afterthought, and maybe it will/can, but I doubt it.=C2=A0
The only other conclusion I can draw from all this, is that pr= iorities don't really matter in the big picture. I certainly see enough= indicators to that end. For example Microsoft Edge
not bothering= to use them in the first place. For example browsers not seeming to a/b te= st optimal approaches for over 4 years. For example, some people advocating= that "passive"
resource request order=C2=A0+ content-t= ype is enough of a signal in itself to provide good page loading performanc= e. For example, people proposing not letting them block H3.=C2=A0
This viewpoint is 100% contradictory to my own prioritization research and= my understanding of current web page building techniques. Maybe I'm mi= ssing things others take for=C2=A0
granted. Maybe I'm making = mistakes. Maybe priorities are not the cornerstone of a multiplexed protoco= l that I view them to be. In that case, by all means go ahead and continue= =C2=A0
down this proposed route, as it indeed seems the best way = forward. If not: please give them the attention they deserve.
With best regards,
Robin=C2=A0


On= Sat, 17 Aug 2019 at 14:10, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= wrote:
+1


On 17 August 2019 at 00.08= .06, Jana Iyengar (= jri.ietf@gmail.com) wrote:

+1 to removing the current priorities from HTTP/3.

On Thu, Aug 15, 2019 at 8:49 PM Mark Nottingham <mno= t@mnot.net> wrote:
In Montreal, we had a discussion about priorities, where the outcome was that people in the room agreed to defer to the HTTP Working Group regarding whether HTTP/3 should ship with something compatible with HTTP/2 priorities in it:
=C2=A0 https://gi= thub.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3-priorities

Since then, the HTTP Working Group has come to consensus that it does not believe we should do so:
=C2=A0 https://www.w3.org/mid/00= CD4B65-7015-45F6-9F18-624B0DB7A501@mnot.net

This consensus call is to confirm this approach in this WG. In practical terms, it means we will remove the current HTTP/2-aligned priorities machinery from HTTP/3. It does NOT necessarily mean that HTTP/3 will ship without any form of priorities; just not this one. Doing so will resolve a number of outstanding issues, and make way for a replacement scheme, currently under discussion in a design team in the HTTP Working Group.

Please respond by the middle of next week; we'd like to move forward with this resolution.

Kind regards,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/



--

=C2=A0<= /tr>
Robin= =C2=A0Marx
PhD researcher - web performance
Expertise centre for Digital Media
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94
=C2= =A0
www.uhasselt.be=
Unive= rsiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor=C2=A0ED= M-2.05
=C2=A0
3D""
--000000000000b33b01059050ab69--