Re: Question about HTTP 2.0 priority

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/10/2014 2:12 p.m., Chad Austin wrote:
> Hi,
> 
> I am reading the HTTP 2.0 draft, and I wonder whether HTTP 2.0
> supports implementing simple stream priorities like SPDY does.
> 
> Our use case is documented in detail at 
> http://chadaustin.me/2014/08/web-platform-limitations-xmlhttprequest-priority/
>
> 
, but I will summarize here.
> 
> We have a whole pile of 3D assets that we need to retrieve from
> various URLs and load into WebGL.  Some of them are higher-priority
> than others. None of them depend on any other.  For example, we may
> want to prioritize resources closer to the camera.  We definitely
> want to prioritize meshes and low-resolution textures over
> high-resolution textures and animation files.
> 
> Ideally, our application would immediately issue ALL requests and
> let the browser's network stack (and HTTP/SPDY/HTTP2 backend)
> efficiently utilize the socket(s) and bandwidth to transfer
> high-priority assets before low-priority assets.  However, if there
> is available bandwidth, we would benefit from receiving
> low-priority assets in the meantime.
> 
> We would benefit from a large number of priority bits, but could
> make it work with as low as 3 bits.  (2 bits would be too few.)
> 
> How do I map that use case to HTTP 2.0's dependency graph?  At
> first blush, it seems hard: I'd have to define a stream per
> priority level, and set dependencies such that all low-priority
> streams depend on high-priority streams?  And if a high-priority
> stream finishes, then reset the dependency to another high-priority
> stream?
> 

Not hard at all. Just reverse your thinking about priority levels.

You have to create a stream per asset in HTTP/2. The priority for the
stream is assigned based on which *single* asset that stream is being
used to deliver.

For assiging HTTP/2 priorities to your assets just work out the
dependency tree they naturally have anyway. Then walk down it
assigning the root asset the highest priority and each successive
level gets assigned a dependency on the asset/stream above it in the tree.

If the drawing dependency is something like:
 map/mesh -> objects -> skeletons -> low-res texture -> high-res texture

The HTTP/2 fetch dependency would be:
 map-/mesh <- objects <- skeletons <-low-res <- high-res

eg.
 - everything depends on the map/mesh finishing first.
 - object descriptions need to finish next,
 - followed by skeletons as the object they are for finishes,
 - followed by low-res textures once skeleton+object are finished,
 - high-res texture for a construct only required after all the
previous bits are in.

When there is multiple (say 20) high-priority objects/skeletons
depending on a single low-res texture it is up to you whether you make
a dependency of the low-res texture on the 1st objects stream ID or
the 20th objects. If priority is obeyed, depending on the first object
will allow that and later received objects to a bit render earlier
incrementally, depending on the last one will make them all wait for
complete data, but then render as a batch.

HTTP/2 explicitly makes priority optional, so it helps your download
performance if the requests are ordered in a similar way to how you
want them prioritized ("by group" as it were). That way even a naive
intermediary which ignores priority is likely to server the
most-wanted assets first due purely to their stream ID numbers being
first.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJULOojAAoJELJo5wb/XPRjoCkIAMsSm78OpqY+HxJXwkBfDRb8
+2wDSSBuXuTRkCdhkblT2u/5wgsSvfnoZaPAf2dEMa9j2qK2LUgUUiwMN6wIPH38
WFvq/YLNKMNKecx2r7JvbZ//vvLgyFp5vP1D4mcSpWbf1RY3jKoRd7bfnD7wu/vO
OOZify8d3Qq5r6Ax2Cj2kkhfuudFwlpg1CsmOd5PNrxan7qjLc3tRYeMB5SJU6W/
TxmuIq0iLSvdiHDawANk/sI9sesjB7Wblu8WjuZh4+XaQClHRuNv9PS8yFrY/Qzq
I5chqtT27X+cV8CX4GojjWQi9pFqUksAsnmP2VlKquBeSqDq7tl/1/M/H/VTHhU=
=ZG/f
-----END PGP SIGNATURE-----

Received on Thursday, 2 October 2014 06:01:47 UTC