Over-eager servers can make poor use of HTTP/2 push: they might push low-priority resources interleaved with high-priority resources, or worse, they might push resources that are not needed at all. I propose guarding against such servers by updating priorities of push streams. Specifically:

1. On receiving a push promise for a resource that is not cached ( crbug.com/232040 ), the pushed stream will be assigned an IDLE priority. Chrome will communicate this to the server using an appropriate PRIORITY frame.

2. When a pushed stream is matched to a request, if the stream is still open, then the pushed stream's priority is updated to match the request's priority. Chrome will communicate this update using appropriate PRIORITY frames (one to reassign old children of the pushed stream, and another to move the pushed stream).

The basic idea is to split pushed streams into "speculative" and "desired" groups. A pushed stream starts as speculative, then becomes desired once it matches an actual request. Speculative streams have IDLE priority to discourage the server from scheduling them unless there are no other outstanding requests.

I pitched this idea (offline) to rdsmith and bnc, who agreed this idea sounds good. Note also that Firefox does something similar (to my knowledge), where pushed streams initially have "speculative" priority (defined here: http://bitsup.blogspot.com/2015/01/http2-dependency-priorities-in-firefox.html) but are upgraded once they match an actual request.

The implementation of parts 1 and 2 is roughly:

1. In OnPushPromise, we pass ConvertRequestPriorityToSpdyPriority(IDLE) to TryCreatePushedStream. Then, if the stream is created, TryCreatePushStream will update SpdySession::priority_dependency_state_ and send a PRIORITY update, similar to Http2PriorityDependencies::OnStreamSynSent.

2. In SpdySession::GetPushStream, if a matching pushed stream is found and the stream is still open, the stream's priority is updated and PRIORITY frames are sent.

This can be protected behind finch if desired, although given the relatively low usage of push in the wild, I doubt we'd get much meaningful performance data from a finch experiment. I do plan to run a few manual experiments.

This idea should apply to QUIC as well, although I'm less familiar with that code.
 

Over-eager servers can make poor use of HTTP/2 push: they might push low-priority resources interleaved with high-priority resources, or worse, they might push resources that are not needed at all. I propose guarding against such servers by updating priorities of push streams. Specifically:

1. On receiving a push promise for a resource that is not cached ( crbug.com/232040 ), the pushed stream will be assigned an IDLE priority. Chrome will communicate this to the server using an appropriate PRIORITY frame.

2. When a pushed stream is matched to a request, if the stream is still open, then the pushed stream's priority will be updated to match the request's priority. Chrome will communicate this update using appropriate PRIORITY frames (one to reassign old children of the pushed stream, and another to move the pushed stream).

The basic idea is to split pushed streams into "speculative" and "desired" groups. A pushed stream starts as speculative, then becomes desired once it matches an actual request. Speculative streams have IDLE priority to discourage the server from scheduling them unless there are no other outstanding requests.

I pitched this idea (offline) to rdsmith and bnc, who agreed this idea sounds good. Note also that Firefox does something similar (to my knowledge), where pushed streams initially have "speculative" priority (defined here: http://bitsup.blogspot.com/2015/01/http2-dependency-priorities-in-firefox.html) but are upgraded once they match an actual request.

The implementation of parts 1 and 2 is roughly:

1. In OnPushPromise, we pass ConvertRequestPriorityToSpdyPriority(IDLE) to TryCreatePushedStream. Then, if the stream is created, TryCreatePushStream will update SpdySession::priority_dependency_state_ and send a PRIORITY update, similar to Http2PriorityDependencies::OnStreamSynSent.

2. In SpdySession::GetPushStream, if a matching pushed stream is found and the stream is still open, the stream's priority is updated and PRIORITY frames are sent.

This can be protected behind finch if desired, although given the relatively low usage of push in the wild, I doubt we'd get much meaningful performance data from a finch experiment. I do plan to run a few manual experiments.

This idea should apply to QUIC as well, although I'm less familiar with that code.