W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

Re: HTTP/3 Prioritization Proposal

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 30 Jan 2019 17:30:48 +1300
To: Patrick Meenan <patmeenan@gmail.com>, Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <4659a997-1b0d-cedc-be2f-ad0ac0b69ea2@treenet.co.nz>
On 30/01/19 12:47 pm, Patrick Meenan wrote:
> The sequential ordering of resources is intentional and desired for
> pretty much everything except for images. Scripts and CSS loaded in the
> order that they block the parser using 100% of the bandwidth lets you
> pipeline the loading and parse/execution so you can be executing the
> first script while the second is transferring. If you load them
> concurrently then they all complete at the same time (later than
> individual ones) and then you need to do the parse/execution of all of
> them. The Chrome chaining of requests is to achieve exactly that while
> the Safari and Firefox models end up with the parallel loading and
> sharing of bandwidth (but they do better for images which benefit from
> parallel loading). This is a real problem in the field today where
> things discovered late that get inserted early in the chain (visible
> images or fonts) try to attach to a stream that already finished from
> the server's perspective, miss, and attach to the root with a low
> weight, effectively making them the lowest priority resource instead of
> highest.
> 

Ah. That last sentence.

IIRC, it was intended that such last-minute discovered be given a choice
of higher weight explicitly in their HEADERS priority field suitable for
resolving this last-place position within the other streams active at
the time. The client agent (Browser) is the only agent with full
knowledge about whether this new discovery is a blocking object or just
a background load sufficient.

The weight re-allocation prescribed on parent stream closure fixes up
any discrepancy from in-transit completions[1]. Then if one actually
cares about the sync a PRIORITY can explicitly realign to exact values
as needed by the client. Though in the later case traffic delivery (and
thus stream turnover) is expected to most often be so fast as to not
matter much in that regard.


[1] My personal preference is still to leave weights as static values
only changed by PRIORITY to make predictions by the client about server
state much more reliable.

Amos
Received on Wednesday, 30 January 2019 04:31:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 January 2019 04:31:15 UTC