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 9118C120072 for ; Sat, 17 Aug 2019 06:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 YqFXzNjclDhT for ; Sat, 17 Aug 2019 06:54:16 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 5812D12002E for ; Sat, 17 Aug 2019 06:54:16 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id u15so7746297ljl.3 for ; Sat, 17 Aug 2019 06:54:16 -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; bh=qWkuSEu/1gVbJm9GAC9uwDxHXZn7w+JlI+cat0k4AZs=; b=pCdzzr5CD1xuzMFkmXidYB9OWP+kYCqYDvBZQi6ytvDbAVaxtFN6idq167pK1mD+2O TgSDcbUIXhIkdofnueDqswElPMJebshAoXRMUvuFSIe1eGeV4/7tq+bsYC+LQGUz2aQo P+glNkKc8Giu5qyZic8pfZBm5sLgSUhTtMXk8= 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; bh=qWkuSEu/1gVbJm9GAC9uwDxHXZn7w+JlI+cat0k4AZs=; b=Vk+06Wd3mISYFIwISjb4LzmY1epA9wWeoCZS9xNQbcM7F2y4TUqlfGVhMPFGooDERj zulE/fqARzazgD8PmRysFpboaipXmO6HZdAJ7Pwxon53STHmHhr35rwnu5h4dhdimQO3 i75LY7ftlsToE4D2J8GNW/zjZ071/jo23oA/3NDbSVDY6n0xpl/Ym9aa6KXH4cPjo12o uy0SxaGTw1gDC4Xcsn8pDiRWflVZYKJeWNRX189RvEB23CFZ/2wOnNTNeVKHEx2Jd0PR uV9kAPfCpL0AmfnFS94Sk6Rxd98M22Ykyh2n+Cgap8zufTGXLE3dsknuX9dbdMY5Zpx5 bVnw== X-Gm-Message-State: APjAAAUhr8aGW/nXACS3lr6V/3MQM/ikA0tpGMXh5v3Cg7hF8tHnep4O 5hjpPD0ESsDRaUxVQgWnwqsCrhtPt7S73X8Tla7mzVrtjmc= X-Google-Smtp-Source: APXvYqzfGIU9VoCnpAtNSvEcyUqUC5+xIyA6NYd2AJnAmKw3mUyUpQweS7ZQRY/PJ4RV5lZuD/pxBK862Nig7NQ1Hq8= X-Received: by 2002:a2e:81cb:: with SMTP id s11mr7954925ljg.179.1566050053338; Sat, 17 Aug 2019 06:54:13 -0700 (PDT) MIME-Version: 1.0 References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> In-Reply-To: From: Robin MARX Date: Sat, 17 Aug 2019 15:54:03 +0200 Message-ID: Subject: Re: Call for consensus: HTTP/2 Priorities To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000002151e505905071b2" 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 13:54:21 -0000 --0000000000002151e505905071b2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 of 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 insights. 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 told 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, some 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 and my understanding of current web page building techniques. Maybe I'm missing 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 case, 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 was >> that people in the room agreed to defer to the HTTP Working Group regard= ing >> whether HTTP/3 should ship with something compatible with HTTP/2 priorit= ies >> in it: >> >> https://github.com/quicwg/wg-materials/blob/master/ietf105/minutes.md#h3= -priorities >> >> Since then, the HTTP Working Group has come to consensus that it does no= t >> 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 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 shi= p >> 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 wit= h >> this resolution. >> >> Kind regards, >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> --=20 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 --0000000000002151e505905071b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
At the risk of repeatedly screaming into the void:
I do not have a problem with the removal of HTTP/2-style priori= ties per se. The setup is certainly quite complex and can be simplified in = terms of implementation.
However, the dependency tree is also ver= y 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.= =C2=A0
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 insights.=C2=A0

However, that latt= er 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-,= =C2=A0
just maybe (NOT=C2=A0necessarily as Mark says) shipping H3 with some form of priorities on-board (i.e., "prioritie= s should not block H3"). The way I see this going forward=C2=A0
<= div>is that many people just won't bother implementing any prioritizati= on concept until it's clear what will end up chosen (and it's in th= e spec).=C2=A0
Consequently, people will keep testing QUIC stack = performance without caring about multiplexing (much): downloading a single = file over a single stream,=C2=A0
which imo is only part of the eq= uation. I see us ending up with shipped implementations that don't have= decent prioritization support, this time not because they can't=C2=A0<= /div>
be bothered to implement a dependency tree, but simply because no= body told them they should. Thus we run the risk of H3 performing worse tha= n H2.=C2=A0

As such, I am not really in favor of r= emoving 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 s= etup).


I really feel we're stic= king 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 th= e very vague=C2=A0https://tools.ietf.org/html/draft-ietf-quic-transpo= rt-22#section-2.3=C2=A0as 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 QU= IC stream priorities yet.=C2=A0
People seem to expect this to som= ehow resolve itself or that it can be bolted on as an afterthought, and may= be it will/can, but I doubt it.=C2=A0

The only oth= er 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, some people advocating that "passive"=
resource request order=C2=A0+ content-type is enough of a signal= in itself to provide good page loading performance. For example, people pr= oposing not letting them block H3.=C2=A0
This viewpoint is 100% c= ontradictory to my own prioritization research and my understanding of curr= ent web page building techniques. Maybe I'm missing things others take = for=C2=A0
granted. Maybe I'm making mistakes. Maybe prioritie= s are not the cornerstone of a multiplexed protocol 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 gi= ve them the attention they deserve.

With best rega= rds,
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/



--

<= td style=3D"font-family:Verdana,Geneva,sans-serif">Agoralaan Gebouw D - = B-3590 Diepenbeek --0000000000002151e505905071b2--
Robin=C2=A0Marx
PhD researcher - web performance
Expertise centre for Digita= l Media
=C2=A0
T +32(0)11 26 84 79 - GSM +32(0)497 72 86 9= 4
=C2=A0
www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Kantoor=C2=A0EDM-2.05
=C2=A0
3D""