Re: Call for consensus: HTTP/2 Priorities

Mark Nottingham <mnot@mnot.net> Mon, 26 August 2019 07:01 UTC

Return-Path: <mnot@mnot.net>
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 B4C12120827 for <quic@ietfa.amsl.com>; Mon, 26 Aug 2019 00:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Wbujjzbn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=yd842aBD
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 jJLQL356f7SV for <quic@ietfa.amsl.com>; Mon, 26 Aug 2019 00:01:35 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 920A9120180 for <quic@ietf.org>; Mon, 26 Aug 2019 00:01:35 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id AC1AF30B; Mon, 26 Aug 2019 03:01:34 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 26 Aug 2019 03:01:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=R vnKStTW06iwb4jUcqmnF+h1QXXsRIQnJhTxFk/Yygk=; b=WbujjzbnKu2znjdTT bEFMgGzKLUBIAaRBr1LNiDWoOEycmozidP6ScnVmhlM/dejJiMX6tJJt1JEV3kQb fQjZpnOjKbWHUbR43gDXs761AyQBY9FGWxu6d686srxbh14xBWdCsfqO28I16gT4 tKnEk4YZ3WJUhGmCeJVOJ5PaCBLRSBzukBdbePCw5ksd2aeoPAmYz3truli7BBUc BI3x7/JVCZ39YjU6FMYf9eRPvK2NnVb5JdKBuqBsGKjmPUTaxcIF8xtJ7vjO8ZwZ nqluA13R158FvR8TFMPiu1mmWX8A1ljwMwwxBBSYKxIANQ1FGJZOuwy+xwNJSM/K nxDBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=RvnKStTW06iwb4jUcqmnF+h1QXXsRIQnJhTxFk/Yy gk=; b=yd842aBDA04aZHUKt40ht0g3eDb3f8vMAWRjE0r28KvXg2E7djHYnm6VK 6F9Clb7bddJfTLED63mjfyzBHjkbSKmYnZpJ112ar9wL1/vBh4TeOTkVxf/VKbz2 tGxw4FJnESFUsHv/5qtgCdFFPFjpL33vlc01I8QQ2jx9Jp2+n9EUBVkVuDMX1KwQ gR2839s1P8TmC8zlhnYfF6AgrUQEmLF96AwmSIkr4k5a/HWnkn6bEek4eT9CV0s8 XzLxQuI/uq7pQ2CDbruzd47MC74mEePyoJ69xo5/jmlUx6JNCxu4fboEl9bPdtiT z0rKo56DPWuk426LD42gmGmr5J2Yw==
X-ME-Sender: <xms:zINjXRsDGZ84pkrsnKIMqkUjKWG8DN6jBYcQmao5-A4W_dpfIKEBvg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudehfedgudduiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeforghr khcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuffhomhgrih hnpehonhhthhhurghughduhedvtddulegrthekgeelphhmmhgrrhhknhhothhtihhnghhh rghmmhhnohhtmhhnohhtrdhnvghtpdiffedrohhrghdpghhithhhuhgsrdgtohhmpdhivg htfhdrohhrghdpuhhhrghsshgvlhhtrdgsvgdpmhhnohhtrdhnvghtpdhhthhtphefrdhi thdphhhtthhpphhrihhorhhithhivghsfhhorhhtohholhhonhhgohhthhgvrhifihhsvg ifvgifohhulhgunhhtsggvihhnthhhihhstghurhhrvghnthhmvghsshdrnhgvgihtnecu kfhppedugeegrddufeeirddujeehrddvkeenucfrrghrrghmpehmrghilhhfrhhomhepmh hnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:zINjXRueM5WP3l4mqRtVodUvsODecl5CE20jZEf2jnmL6PVIGrxxjg> <xmx:zINjXZcS8uf50G7oMMBggsEGprCE5B7SpqEGWk42fFDyyHFNaj_FdQ> <xmx:zINjXU50Vf1AgWM-_MT7N7OB9zPusNxxXbzxKh8epgC37YvtHRoFZA> <xmx:zoNjXahxkV-JV77ri-aXyZnpXkkibaCNkBM-kFUfCpvUHKUMDpMoIQ>
Received: from macbook-pro.mnot.net (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 381F5D60062; Mon, 26 Aug 2019 03:01:30 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: Call for consensus: HTTP/2 Priorities
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAC7UV9av8zbZ8VDcrgFcQAY15+WdOq7EDM9myNid9He6bFZU8Q@mail.gmail.com>
Date: Mon, 26 Aug 2019 17:01:26 +1000
Cc: IETF QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF8E6554-5C4F-4A69-A0B0-85A039A29F2F@mnot.net>
References: <5E8935DC-6FB5-40F8-A843-1B3991D08CB9@mnot.net> <CACpbDcddQK3yO-hCrFys6eFYZXYvXzJ-SM68ix0xkGt_t52OJA@mail.gmail.com> <CAN1APdd=9=U+hYHEfZ3Zg36B7GLnJ13L3iT3zNV1QBEq1ACqnA@mail.gmail.com> <CAC7UV9av8zbZ8VDcrgFcQAY15+WdOq7EDM9myNid9He6bFZU8Q@mail.gmail.com>
To: Robin MARX <robin.marx@uhasselt.be>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/MC_lGnVVoB6j5jJQEr1XSMnkuJ8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Aug 2019 07:01:39 -0000

Hi Robin,

Thanks for taking the time to respond.

I think these points are well taken; by far most people want to get a priority hinting mechanism into H3. Personally I view this as clearing the decks to let that happen; if we aren't distracted by the myriad issues with H2 priorities, it looks like we can get something simple in pretty quickly.

Additionally, this is definitely NOT a consensus call to ship H3 without priority hints at all; if we do that, we'd need to come to a separate consensus for that first, and my current reading is that there's not a will to do so yet.

Cheers,


> On 17 Aug 2019, at 11:54 pm, Robin MARX <robin.marx@uhasselt.be> 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 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øe Jørgensen <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 <mnot@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:
>>   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 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 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   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
>  
> 

--
Mark Nottingham   https://www.mnot.net/