Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
I replied on Friday night, but exceeded the 40 KB mailing list limit, and it has not been moderated through yet. So, replying again: On Tue, Oct 14, 2014 at 10:02 AM, Ilya Grigorik wrote: > > On Thu, Oct 9, 2014 at 12:12 PM, Chad Austin wrote: > >> >> This thread has been a bit confusing, partially because I did not have a >> deep understanding of HTTP 2's priority semantics and partially because I >> feel your responses have been too short and vague to truly answer the use >> case described at the top of the thread. For example, you said "0-7 >> priority is not sufficient. Please see the previous proposal.", yet I >> don't see any discussion in the previous proposal about why 0-7 is not >> sufficient. >> >> In addition, because I'm not sure it's clear, priorities and weights are >> *different >> concepts*. Weights are used to allocate resources between streams of >> identical priority. Priorities are used to specify that one request should >> be completed before another if possible. >> > > That was never the case in SPDY. In v1-v3.1 priority never guaranteed > strict delivery. Priorities were always advisory for the server, and in v4 > draft we changed that to the tree model that is in HTTP/2. > > Also, note that this behavior is *intentional*. When using transport > priorities, you're effectively telling the server: > - I need all of these requests, please mux all the frames such that I > receive all of the data as quickly as possible > - Also, if possible, please allocate the pipe based on specified > weights/dependencies/etc > > The above does not guarantee any order. Take an extreme example: B depends > on A; A is taking 3 seconds to generate on the backend, while B is ready to > ship. The server should not starve the connection while its waiting on A, > and it should pump bytes for B until its ready to return bytes for A. > > If you need *strict* response ordering, then you have to choices: > - Dispatch requests from the client based on completion of previous > request, instead of firing them off simultaneously > - Change your server to enforce your own arbitrary semantics (general > purpose servers won't do this) > Of course priorities are advisory. :) I don't need strict response ordering. I simply want to simultaneously maximize bandwidth utilization but also, when possible, have the server transmit bytes in the desired order. This is not an unreasonable request either: nginx backed by Varnish, assuming Varnish cache hits (~1ms latency), and assuming the connection is bandwidth-constrained, will send stream frames in approximately priority order. nginx's SPDY implementation is five small C files, and it prioritizes streams and frames with a very simple priority queue implementation. So while priority is advisory, it's also very important for achieving good performance, and it will also be effective in practice. If HTTP 2 servers don't prioritize, they run the risk of regressing performance relative to HTTP. This is because browsers currently prioritize HTTP behind the scenes with a priority queue. *The Use Case* >> >> Our application issues thousands (sometimes tens of thousands) of XHR >> HTTP requests to populate a WebGL-rendered 3D scene. >> >> Many of those requests are higher *priority* than others, in that, if >> possible, they should be completed *before* expending bandwidth on >> lower-priority resources. Moreover, there is no benefit to having multiple >> responses downloading simultaneously: assuming saturated bandwidth, it is >> always better here to complete one response before moving to the next. >> (Having two half-downloaded textures or meshes is not useful. Having one >> fully-downloaded texture or mesh and one not started yet is useful.) >> > > Makes sense. To match this, create a tree that captures these relationship. > Except it would be a linked list instead of a tree. Per Martin Thomson in http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0164.html, "We can't express a dependency on multiple resources, except by creating a linear chain: B2 -> B1 -> A2 -> A1 -> 0." In the use case described, managing priorities numerically is much simpler. If three resources A0, A1, A2 have priority 7, and resources B0, B1, and B2 have priority 6, and resource C has priority 5, then it's not a tree. It's a linked list: C -> B2 -> B1 -> B0 -> A2 -> A1 -> A0 -> 0. (C -> B0 -> B2 -> B1 -> A1 -> A2 -> A0 -> 0 would also be a fine ordering, as the sequencing within each level does not matter.) >From a software development point of view, the ideal JavaScript API would >> allow issuing *all* requests simultaneously, indicating their relative >> priority to the browser, and let the browser map the desired priority to >> the underlying protocol stack. >> > > Dependencies and weights. You're using priority values as crude levels to > indicate "ordering". Instead, identify think of each "priority level" as a > level in the deps tree, where each level can have multip
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
On Thu, Oct 9, 2014 at 12:12 PM, Chad Austin wrote: > Hi Ilya, > > This thread has been a bit confusing, partially because I did not have a > deep understanding of HTTP 2's priority semantics and partially because I > feel your responses have been too short and vague to truly answer the use > case described at the top of the thread. For example, you said "0-7 > priority is not sufficient. Please see the previous proposal.", yet I > don't see any discussion in the previous proposal about why 0-7 is not > sufficient. > > In addition, because I'm not sure it's clear, priorities and weights are > *different > concepts*. Weights are used to allocate resources between streams of > identical priority. Priorities are used to specify that one request should > be completed before another if possible. > That was never the case in SPDY. In v1-v3.1 priority never guaranteed strict delivery. Priorities were always advisory for the server, and in v4 draft we changed that to the tree model that is in HTTP/2. Also, note that this behavior is *intentional*. When using transport priorities, you're effectively telling the server: - I need all of these requests, please mux all the frames such that I receive all of the data as quickly as possible - Also, if possible, please allocate the pipe based on specified weights/dependencies/etc The above does not guarantee any order. Take an extreme example: B depends on A; A is taking 3 seconds to generate on the backend, while B is ready to ship. The server should not starve the connection while its waiting on A, and it should pump bytes for B until its ready to return bytes for A. If you need *strict* response ordering, then you have to choices: - Dispatch requests from the client based on completion of previous request, instead of firing them off simultaneously - Change your server to enforce your own arbitrary semantics (general purpose servers won't do this) > Per HTTP 2, "Streams with the same parent SHOULD be allocated resources > proportionally based on their weight." This is not the same thing as > priority. Weights may have value to others, but they don't have value to > the use case below. > Yes, which is why HTTP/2 introduces dependencies and weights. *The Use Case* > > Our application issues thousands (sometimes tens of thousands) of XHR HTTP > requests to populate a WebGL-rendered 3D scene. > > Many of those requests are higher *priority* than others, in that, if > possible, they should be completed *before* expending bandwidth on > lower-priority resources. Moreover, there is no benefit to having multiple > responses downloading simultaneously: assuming saturated bandwidth, it is > always better here to complete one response before moving to the next. > (Having two half-downloaded textures or meshes is not useful. Having one > fully-downloaded texture or mesh and one not started yet is useful.) > Makes sense. To match this, create a tree that captures these relationship. > From a software development point of view, the ideal JavaScript API would > allow issuing *all* requests simultaneously, indicating their relative > priority to the browser, and let the browser map the desired priority to > the underlying protocol stack. > Dependencies and weights. You're using priority values as crude levels to indicate "ordering". Instead, identify think of each "priority level" as a level in the deps tree, where each level can have multiple requests, resources for which can be further customized via weights. > > *Current Browser Behavior* > Browsers have widespread support for two protocols (HTTP and SPDY) and are > likely to support HTTP 2 very soon. > They will support HTTP/2, it's only a question of how soon. Latest FF and Chrome are already rolling out HTTP/2 support in stable channels, and the plan (for all browsers) is to actively deprecate SPDY. > *So what interface should the browser expose?* > > Before designing a browser API, a few questions must be answered: > > 1) Should the priority API support legacy HTTP and SPDY? > - SPDY is going to be aggressively deprecated. - Legacy HTTP has a lot of potential gotchas, I'd flag this as at risk. > 2) Should the priority API support future protocols beyond HTTP 2? > - Yes, it shouldn't be tied directly to HTTP/2 semantics. > 3) How likely is it future protocols will support non-dependency-based > priority models. > - Note that you *can* implement whatever you want on the server. Client sends its preferences, you do what you want. > 3) How much work should be placed on application developers? aka how > closely should the API fit the application domain? > - I'm not sure what "application domain" means, since that'll be different for every application. That said, yes, a sensible abstraction over the low-level plumbing is good. > IMO, the answers to the above questions are "yes", "yes", and "possible", > and "better for the API to fit the application domain than for the API to > reflect one possi
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
On Thu, Oct 9, 2014 at 9:12 PM, Chad Austin wrote: > Before designing a browser API, a few questions must be answered: > > 1) Should the priority API support legacy HTTP and SPDY? > 2) Should the priority API support future protocols beyond HTTP 2? > 3) How likely is it future protocols will support non-dependency-based > priority models. > 3) How much work should be placed on application developers? aka how > closely should the API fit the application domain? > > IMO, the answers to the above questions are "yes", "yes", and "possible", > and "better for the API to fit the application domain than for the API to > reflect one possible underlying protocol so that a truer implementation in > non-HTTP-2 protocols is possible". Your answers lack justification. Is there any reason to believe SPDY will remain supported in user agents? Is there any point in supporting prioritization in HTTP/1.1 when it's by-and-large not the protocol you want to use anyway if you care about performance? > Should I write a document with a formal API proposal including rationale or > is this thread sufficient? I don't really think we've reached that stage yet. Best to first figure out what we want and why before making any proposals. -- https://annevankesteren.nl/
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
Hi Ilya, This thread has been a bit confusing, partially because I did not have a deep understanding of HTTP 2's priority semantics and partially because I feel your responses have been too short and vague to truly answer the use case described at the top of the thread. For example, you said "0-7 priority is not sufficient. Please see the previous proposal.", yet I don't see any discussion in the previous proposal about why 0-7 is not sufficient. In addition, because I'm not sure it's clear, priorities and weights are *different concepts*. Weights are used to allocate resources between streams of identical priority. Priorities are used to specify that one request should be completed before another if possible. Per HTTP 2, "Streams with the same parent SHOULD be allocated resources proportionally based on their weight." This is not the same thing as priority. Weights may have value to others, but they don't have value to the use case below. OK, now that that's clear, let's have a redo: *The Use Case* Our application issues thousands (sometimes tens of thousands) of XHR HTTP requests to populate a WebGL-rendered 3D scene. Many of those requests are higher *priority* than others, in that, if possible, they should be completed *before* expending bandwidth on lower-priority resources. Moreover, there is no benefit to having multiple responses downloading simultaneously: assuming saturated bandwidth, it is always better here to complete one response before moving to the next. (Having two half-downloaded textures or meshes is not useful. Having one fully-downloaded texture or mesh and one not started yet is useful.) >From a software development point of view, the ideal JavaScript API would allow issuing *all* requests simultaneously, indicating their relative priority to the browser, and let the browser map the desired priority to the underlying protocol stack. This goal of this thread is to provide feedback into how said priorities should be specified. *Current Browser Behavior* Browsers have widespread support for two protocols (HTTP and SPDY) and are likely to support HTTP 2 very soon. Browsers currently prioritize requests but there is no content-facing access to said priorities beyond the limited
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
On Wed, Oct 1, 2014 at 8:39 PM, Chad Austin wrote: > Weight is actually not what I want. I want priority. They're different > concepts in that priority implies trumping and weight implies proportional > resource allocation. > > That is, if I make 10 high-priority requests, 20 medium-priority requests, > and 30 low-priority requests, I don't want ANY of the low-priority requests > to consume any resources until either 1) all higher-priority requests have > been serviced or 2) there are spare resources that cannot otherwise be used > for higher-priority requests. > And.. you've just defined a three-level deep dependency tree, with weights for resources within each group. > As you quoted, "Streams with the same parent SHOULD be allocated resources > proportionally based on their weight." Proportional allocation would be > incorrect for this use case. > Proportional within the same level of the tree, and based on assigned weights within that level. ig > > On Wed, Oct 1, 2014 at 8:19 PM, Ilya Grigorik wrote: > >> >> On Wed, Oct 1, 2014 at 7:59 PM, Chad Austin wrote: >> >>> I don't see a way to set a priority value in there. The specific >>> wording is "Streams can be prioritized by marking them as dependent on the, >>> completion of other streams". >>> >>> I see that a client can specify the weight of a stream and you can say >>> that a stream depends on another stream. Neither of those are what I >>> want. I simply want to specify priorities of a bunch of requests. How >>> would I do that in HTTP 2.0? >>> >> >> Weight is exactly what you want: >> http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.3.2 >> >> "A stream that is not dependent on any other stream is given a stream >>dependency of 0x0. In other words, the non-existent stream 0 forms >>the root of the tree." >> >> All dependent streams are allocated an integer weight between 1 to >>256 (inclusive)... Streams with the same parent SHOULD be allocated >> resources >>proportionally based on their weight. " >> >> In other words, if you don't care about dependencies, then don't assign >> the parent. Doing so will make all streams children of the root of the tree >> (0x0), and from there you can use weights to assign relative priority. >> >> Hope that makes sense. >> >> ig >> >> >> >> > > > -- > Chad Austin > http://chadaustin.me >
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
Weight is actually not what I want. I want priority. They're different concepts in that priority implies trumping and weight implies proportional resource allocation. That is, if I make 10 high-priority requests, 20 medium-priority requests, and 30 low-priority requests, I don't want ANY of the low-priority requests to consume any resources until either 1) all higher-priority requests have been serviced or 2) there are spare resources that cannot otherwise be used for higher-priority requests. As you quoted, "Streams with the same parent SHOULD be allocated resources proportionally based on their weight." Proportional allocation would be incorrect for this use case. Does that make sense? Is there anything I can clarify? p.s. I believe it's theoretically possible for an HTTP 2.0 client to map priorities onto stream dependencies, but it seems like the implementation would require a great deal of additional complexity. That is, a stream would be required for every possible priority level. Assume set of streams N at priority P and set of streams M at priority P+2. All of N (streams of priority P) would need to depend on an arbitrary stream in M (priority P+2). When the stream at priority P+2 is closed, the client would need to reattach all of N to another arbitrary stream in M. The addition of a new stream at priority P+1 would require reattaching everything in N (priority P) to the new stream. p.p.s. I asked a friend who stays relatively up-to-date with HTTP 2.0 on whether it's possible to implement SPDY-like priority on HTTP 2.0. His conclusion was "yes, with stream dependencies, but it would require the client to do a lot of work, and that feedback should go to ietf-http-wg@" To that end, I posted the following: http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0016.html On Wed, Oct 1, 2014 at 8:19 PM, Ilya Grigorik wrote: > > On Wed, Oct 1, 2014 at 7:59 PM, Chad Austin wrote: > >> I don't see a way to set a priority value in there. The specific wording >> is "Streams can be prioritized by marking them as dependent on the, >> completion of other streams". >> >> I see that a client can specify the weight of a stream and you can say >> that a stream depends on another stream. Neither of those are what I >> want. I simply want to specify priorities of a bunch of requests. How >> would I do that in HTTP 2.0? >> > > Weight is exactly what you want: > http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.3.2 > > "A stream that is not dependent on any other stream is given a stream >dependency of 0x0. In other words, the non-existent stream 0 forms >the root of the tree." > > All dependent streams are allocated an integer weight between 1 to >256 (inclusive)... Streams with the same parent SHOULD be allocated > resources >proportionally based on their weight. " > > In other words, if you don't care about dependencies, then don't assign > the parent. Doing so will make all streams children of the root of the tree > (0x0), and from there you can use weights to assign relative priority. > > Hope that makes sense. > > ig > > > > -- Chad Austin http://chadaustin.me
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
On Wed, Oct 1, 2014 at 7:59 PM, Chad Austin wrote: > I don't see a way to set a priority value in there. The specific wording > is "Streams can be prioritized by marking them as dependent on the, > completion of other streams". > > I see that a client can specify the weight of a stream and you can say > that a stream depends on another stream. Neither of those are what I > want. I simply want to specify priorities of a bunch of requests. How > would I do that in HTTP 2.0? > Weight is exactly what you want: http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.3.2 "A stream that is not dependent on any other stream is given a stream dependency of 0x0. In other words, the non-existent stream 0 forms the root of the tree." All dependent streams are allocated an integer weight between 1 to 256 (inclusive)... Streams with the same parent SHOULD be allocated resources proportionally based on their weight. " In other words, if you don't care about dependencies, then don't assign the parent. Doing so will make all streams children of the root of the tree (0x0), and from there you can use weights to assign relative priority. Hope that makes sense. ig
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
On Wed, Oct 1, 2014 at 7:24 PM, Ilya Grigorik wrote: > > On Wed, Oct 1, 2014 at 4:48 PM, Chad Austin wrote: > >> Does HTTP 2.0's dependency graph + weights system allow traditional >> priority semantics? That is, higher-priority resources would be serviced >> before lower-priority resources, unless resource capacity remains available. > > > Yes, that's exactly how its defined. See: > http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.3 > Hi Ilya, I don't see a way to set a priority value in there. The specific wording is "Streams can be prioritized by marking them as dependent on the, completion of other streams". I see that a client can specify the weight of a stream and you can say that a stream depends on another stream. Neither of those are what I want. I simply want to specify priorities of a bunch of requests. How would I do that in HTTP 2.0? Thanks for any clarification you can provide, -- Chad Austin http://chadaustin.me
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
On Wed, Oct 1, 2014 at 4:48 PM, Chad Austin wrote: > Does HTTP 2.0's dependency graph + weights system allow traditional > priority semantics? That is, higher-priority resources would be serviced > before lower-priority resources, unless resource capacity remains available. Yes, that's exactly how its defined. See: http://tools.ietf.org/html/draft-ietf-httpbis-http2-14#section-5.3 ig
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
On Wed, Oct 1, 2014 at 11:02 AM, Ilya Grigorik wrote: > > On Wed, Oct 1, 2014 at 10:54 AM, Chad Austin wrote: > >> I believe this proposal is very easy to implement: just plumb the priority >> value through to the prioritizing network layer browsers already >> implement. >> > What will it take to get this added to the spec? >> > > 0-7 priority is not sufficient. See previous discussion / proposal: > http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html > I would LOVE to have more bits of priority. :) Our particular use case would be satisfied by 7, but if priority was a general 32-bit integer, we would take full advantage of that. I do not understand how to map desired 3D asset priorities onto the HTTP 2.0 dependency graph. We don't have a set of dependent resources - just a priority for each one. Does HTTP 2.0's dependency graph + weights system allow traditional priority semantics? That is, higher-priority resources would be serviced before lower-priority resources, unless resource capacity remains available. I intend to ask on the HTTP-BIS mailing list, but perhaps somebody here who is more caught up on HTTP 2.0 can explain it to me... Thanks, -- Chad Austin http://chadaustin.me
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
0-7 priority is not sufficient. See previous discussion / proposal: http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Aug/0081.html ig On Wed, Oct 1, 2014 at 10:54 AM, Chad Austin wrote: > Hi all, > > I posted the following message to WebApps, but Anne van Kesteren suggested > that I instead post to WHATWG, and generalize my request to anything that > supports "Fetch". When reading below, feel free to interpret > XMLHttpRequest in the broadest sense. > > The proposal follows: > > *** > > I would like to see a priority field added to XMLHttpRequest. Mike > Belshe's proposal here is a great start: > http://www.mail-archive.com/public-webapps@w3.org/msg08218.html > > *Motivation* > > Browsers already prioritize network requests. By giving XMLHttpRequest > access to the same machinery, the page or application can reduce overall > latency and make better use of available bandwidth. I wrote about our > specific use case (efficiently streaming hundreds of 3D assets into WebGL) > in detail at > > http://chadaustin.me/2014/08/web-platform-limitations-xmlhttprequest-priority/ > > Gecko appears to support a general 32-bit priority: > > http://lxr.mozilla.org/mozilla-central/source/xpcom/threads/nsISupportsPriority.idl > and > > http://lxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp#45 > > Chrome appears to be limited to five priorities: > > https://code.google.com/p/chromium/codesearch#chromium/src/net/base/request_priority.h&sq=package:chromium&type=cs&rcl=1411964872 > but seems to have a fairly general priority queue implementation, so > increasing the number of priorities is likely straightforward. > > https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/resource_scheduler.cc&sq=package:chromium&type=cs&rcl=1411964872&l=206 > > SPDY exposes 3 bits of priority per stream. > > > *Proposal* > Add a numeric priority property to XMLHttpRequest. It is a 3-bit integer > from 0 to 7. Default to 3. 0 is most important. Why integers and not > strings, as others have proposed? Because priority arithmetic is > convenient. For example, in our use case, we might say "The top bit is set > by whether an asset is high-resolution or low-resolution. Low-resolution > assets would be loaded first. The bottom two bits are used to group > request priorities by object. The 3D scene might be the most important > resource, followed by my avatar, followed by closer objects, followed by > farther objects." Note that, with a very simple use case, we've just > consumed all three bits. > > There's some vague argument that "having fewer priorities makes > implementing prioritization easier", but as we've seen, the browsers just > have a priority queue anyway. > > Allow priorities to change after send() is called. The browser may ignore > this change. It could also ignore the priority property entirely. > > I propose XMLHttpRequest priority not be artificially limited to a range of > priorities relative to other resources the browser might initiate. That > is, the API should expose the full set of priorities the browser supports. > If my application wants to prioritize an XHR over some browser-initiated > request, it should be allowed to do so. > > The more control over priority available, the better a customer experience > can be built. For example, at the logical extreme, fine-grained priority > levels and mutable priority values would allow dynamically streaming and > reprioritizing texture mip levels as objects approach the camera. If > there's enough precision, the application could set priority of an object > to the distance from the camera. Or, in a non-WebGL scenario, an image > load's priority could be set to the distance from the current viewport. > > I believe this proposal is very easy to implement: just plumb the priority > value through to the prioritizing network layer browsers already implement. > > What will it take to get this added to the spec? > > -- > Chad Austin > http://chadaustin.me >
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
For streaming video, where data is requested block-by-block, it would be nice to be able to set priority proportional to the time until the requested video block is needed for rendering. Or at least for relative priorities between requests to reflect this. I think this means that either priorities need to be mutable, so I can increase the priority as time passes and the need for the block becomes more urgent, or I need a large priority space, so that, for example, I can just give each block a fixed priority value equal to it's absolute position in the playback sequence. ...Mark On Wed, Oct 1, 2014 at 10:54 AM, Chad Austin wrote: > Hi all, > > I posted the following message to WebApps, but Anne van Kesteren suggested > that I instead post to WHATWG, and generalize my request to anything that > supports "Fetch". When reading below, feel free to interpret > XMLHttpRequest in the broadest sense. > > The proposal follows: > > *** > > I would like to see a priority field added to XMLHttpRequest. Mike > Belshe's proposal here is a great start: > http://www.mail-archive.com/public-webapps@w3.org/msg08218.html > > *Motivation* > > Browsers already prioritize network requests. By giving XMLHttpRequest > access to the same machinery, the page or application can reduce overall > latency and make better use of available bandwidth. I wrote about our > specific use case (efficiently streaming hundreds of 3D assets into WebGL) > in detail at > > http://chadaustin.me/2014/08/web-platform-limitations-xmlhttprequest-priority/ > > Gecko appears to support a general 32-bit priority: > > http://lxr.mozilla.org/mozilla-central/source/xpcom/threads/nsISupportsPriority.idl > and > > http://lxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp#45 > > Chrome appears to be limited to five priorities: > > https://code.google.com/p/chromium/codesearch#chromium/src/net/base/request_priority.h&sq=package:chromium&type=cs&rcl=1411964872 > but seems to have a fairly general priority queue implementation, so > increasing the number of priorities is likely straightforward. > > https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/resource_scheduler.cc&sq=package:chromium&type=cs&rcl=1411964872&l=206 > > SPDY exposes 3 bits of priority per stream. > > > *Proposal* > Add a numeric priority property to XMLHttpRequest. It is a 3-bit integer > from 0 to 7. Default to 3. 0 is most important. Why integers and not > strings, as others have proposed? Because priority arithmetic is > convenient. For example, in our use case, we might say "The top bit is set > by whether an asset is high-resolution or low-resolution. Low-resolution > assets would be loaded first. The bottom two bits are used to group > request priorities by object. The 3D scene might be the most important > resource, followed by my avatar, followed by closer objects, followed by > farther objects." Note that, with a very simple use case, we've just > consumed all three bits. > > There's some vague argument that "having fewer priorities makes > implementing prioritization easier", but as we've seen, the browsers just > have a priority queue anyway. > > Allow priorities to change after send() is called. The browser may ignore > this change. It could also ignore the priority property entirely. > > I propose XMLHttpRequest priority not be artificially limited to a range of > priorities relative to other resources the browser might initiate. That > is, the API should expose the full set of priorities the browser supports. > If my application wants to prioritize an XHR over some browser-initiated > request, it should be allowed to do so. > > The more control over priority available, the better a customer experience > can be built. For example, at the logical extreme, fine-grained priority > levels and mutable priority values would allow dynamically streaming and > reprioritizing texture mip levels as objects approach the camera. If > there's enough precision, the application could set priority of an object > to the distance from the camera. Or, in a non-WebGL scenario, an image > load's priority could be set to the distance from the current viewport. > > I believe this proposal is very easy to implement: just plumb the priority > value through to the prioritizing network layer browsers already implement. > > What will it take to get this added to the spec? > > -- > Chad Austin > http://chadaustin.me >
Re: [whatwg] Expose XMLHttpRequest [Fetch?] priority
All, FYI ... see below about priorities in XmlHttpRequest. Might be useful for Cadmium (seems some browsers support something already). In JS-ASE on NRDP, we are expressing priority through the model of "download tracks". Each request is prioritized relative to other requests on the same download track (the priority order is the same order as the requests are issued), but is not prioritized at all vs requests on other tracks. This aligns with the NRDP implementation. An ideal way to specify priority for streaming would be to have a large number of priority values and give each request the start PTS as its priority (or zero for headers). ... Mark -- Forwarded message -- From: Chad Austin Date: Wed, Oct 1, 2014 at 10:54 AM Subject: [whatwg] Expose XMLHttpRequest [Fetch?] priority To: wha...@whatwg.org Hi all, I posted the following message to WebApps, but Anne van Kesteren suggested that I instead post to WHATWG, and generalize my request to anything that supports "Fetch". When reading below, feel free to interpret XMLHttpRequest in the broadest sense. The proposal follows: *** I would like to see a priority field added to XMLHttpRequest. Mike Belshe's proposal here is a great start: http://www.mail-archive.com/public-webapps@w3.org/msg08218.html *Motivation* Browsers already prioritize network requests. By giving XMLHttpRequest access to the same machinery, the page or application can reduce overall latency and make better use of available bandwidth. I wrote about our specific use case (efficiently streaming hundreds of 3D assets into WebGL) in detail at http://chadaustin.me/2014/08/web-platform-limitations-xmlhttprequest-priority/ Gecko appears to support a general 32-bit priority: http://lxr.mozilla.org/mozilla-central/source/xpcom/threads/nsISupportsPriority.idl and http://lxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/HttpBaseChannel.cpp#45 Chrome appears to be limited to five priorities: https://code.google.com/p/chromium/codesearch#chromium/src/net/base/request_priority.h&sq=package:chromium&type=cs&rcl=1411964872 but seems to have a fairly general priority queue implementation, so increasing the number of priorities is likely straightforward. https://code.google.com/p/chromium/codesearch#chromium/src/content/browser/loader/resource_scheduler.cc&sq=package:chromium&type=cs&rcl=1411964872&l=206 SPDY exposes 3 bits of priority per stream. *Proposal* Add a numeric priority property to XMLHttpRequest. It is a 3-bit integer from 0 to 7. Default to 3. 0 is most important. Why integers and not strings, as others have proposed? Because priority arithmetic is convenient. For example, in our use case, we might say "The top bit is set by whether an asset is high-resolution or low-resolution. Low-resolution assets would be loaded first. The bottom two bits are used to group request priorities by object. The 3D scene might be the most important resource, followed by my avatar, followed by closer objects, followed by farther objects." Note that, with a very simple use case, we've just consumed all three bits. There's some vague argument that "having fewer priorities makes implementing prioritization easier", but as we've seen, the browsers just have a priority queue anyway. Allow priorities to change after send() is called. The browser may ignore this change. It could also ignore the priority property entirely. I propose XMLHttpRequest priority not be artificially limited to a range of priorities relative to other resources the browser might initiate. That is, the API should expose the full set of priorities the browser supports. If my application wants to prioritize an XHR over some browser-initiated request, it should be allowed to do so. The more control over priority available, the better a customer experience can be built. For example, at the logical extreme, fine-grained priority levels and mutable priority values would allow dynamically streaming and reprioritizing texture mip levels as objects approach the camera. If there's enough precision, the application could set priority of an object to the distance from the camera. Or, in a non-WebGL scenario, an image load's priority could be set to the distance from the current viewport. I believe this proposal is very easy to implement: just plumb the priority value through to the prioritizing network layer browsers already implement. What will it take to get this added to the spec? -- Chad Austin http://chadaustin.me
