Clarification on HTTP/QUIC Unidirectional Streams

[Samuel Hurst <[e-mail]>]

Hi All,


Apologies if this question has been asked before, but I'd just like to 
check that my understanding of something is correct and searching back 
through the list has not answered my question.

Given that HTTP/QUIC requires each peer in a connection to open a 
unidirectional control stream when a connection begins, I think it's 
safe to assume that streams 2 and 3 will be the control streams.

Now, a client will make a request on Stream 0, which will include some 
QPACK HEADERS, and the odds are that some of those headers will be poked 
into the dynamic table (I'm thinking of the User-Agent as a prime 
candidate for this).

However, as I understand it, QPACK requires two unidirectional control 
streams for the encode (type 'H') and decode (type 'h'). And this is per 
encode-decode pair, so there will be another pair of unidirectional 
control streams for the encode and decode of the server's response headers.

So in my head, the current state of streams in use is thus:

Stream 0 - Client Request
Stream 2 - Client Control Stream
Stream 3 - Server Control Stream
Stream 6 - Client Headers QPACK Encoder Stream
Stream 7 - Client Headers QPACK Decoder Stream
Stream 10 - Server Headers QPACK Decoder Stream
Stream 11 - Server Headers QPACK Encoder Stream

So, if as part of the request made in stream 0, the server decides to 
send a PUSH_PROMISE frame, and then once acknowledged by the client the 
server begins the server push immediately, is is a safe assumption to 
make that the first server push stream will be on stream 15?

I also don't think there's anything to stop a server from sending a 
PUSH_PROMISE frame before it's even sent a HEADERS frame back for the 
initial request, so in that case would the server push end up on stream 
11, the server headers encoder stream ends up on stream 15 and the 
decoder stream stays on stream 10?

I'm just trying to get it into my head exactly what the expected lay of 
the land will be during a running HTTP/QUIC session. It's been a while 
since I last looked at the QUIC drafts and I'm jumping ahead through 
several revisions so it's possible that I've missed something.


Best Regards,
Sam