Priority Placeholders in HTTP/2 and HTTP/QUIC

This regards issue 441 in HTTP/QUIC.  For background, HTTP/2 allows the use of closed streams in the priority tree.  While not formally specified, a pattern has emerged in HTTP/2 of using placeholders – implicitly-closed streams, RFC 7540 section 5.1.1 – as root nodes for priority groups.  This is less-easily done in HTTP/QUIC, since the use of streams is supposed to be in sequence, and has no implicit-close rule.  (QUIC really can’t have an implicit-close rule, since STREAM frames might arrive out of order.  Instead, QUIC currently has an implicit-open rule, though that too is currently under discussion.)  It gets even worse that you can chain up to/through actual requests that have already been fulfilled, and you don’t know how long you need to maintain those states.  If the server discards state the client was expecting to keep, the peers can get into really divergent views of what the priority tree is.

I see two paths forward, depending how aggressive we want to be.  If we want to just keep the HTTP/2 model as-is, we could make it explicitly legal for a client to close a stream with no data.  Implementations can informally prioritize maintaining priority state for these as likely placeholders.  Leaves the same potential state explosion, but since it’s all advisory, servers can still discard any of these that aren’t being used if the client goes overboard.

We discussed this briefly in Prague, and concluded that we didn’t want to do a wholesale replacement of the priority scheme, but were interested in a solution of some kind.  There was also some sadness expressed about the unbounded state commitment in the above situations.  We talked about allowing the server to specify a number of placeholders it’s willing to permit the client, and add a flag to the PRIORITY frame saying that the ID given is a placeholder ID rather than a Stream ID.  This is more of a departure, but bounds the state explosion and allows the server to be more aggressive about pruning closed streams.  Our principle, reaffirmed in Prague, was that departures from HTTP/2 which aren’t forced by QUIC need to come from the HTTPbis WG.

I wrote a quick draft casting the second option as an HTTP/2 extension.  Because HTTP/2 implies the stream to be prioritized by sending the PRIORITY frame on that stream, I needed to mint a separate frame to prioritize the placeholders themselves.  Not coincidentally, it’s the HTTP/QUIC PRIORITY frame.  😊  The HTTP/QUIC incarnation of this would add an additional flag to the PRIORITY frame indicating whether the prioritized stream is a placeholder, just as this extension adds to the dependency.

What do folks think?

-----Original Message-----
From: [] 
Sent: Tuesday, July 25, 2017 11:58 AM
To: Mike Bishop <>
Subject: New Version Notification for draft-bishop-httpbis-priority-placeholder-00.txt

A new version of I-D, draft-bishop-httpbis-priority-placeholder-00.txt
has been successfully submitted by Mike Bishop and posted to the IETF repository.

Name:  draft-bishop-httpbis-priority-placeholder
Revision: 00
Title:  Priority Placeholders in HTTP/2
Document date: 2017-07-25
Group:  Individual Submission
Pages:  7



   [RFC7540] defines HTTP/2, including a method for communicating
   priorities.  Some implementations have begun using closed streams as
   placeholders when constructing their priority tree, but this has
   unbounded state commitments and interacts poorly with HTTP/QUIC
   ([I-D.ietf-quic-http]).  This document proposes an extension to the
   HTTP/2 priority scheme for both protocols.


Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at

The IETF Secretariat

Received on Tuesday, 25 July 2017 19:18:49 UTC