Subject: [quicwg/base-drafts] Unidirectional streams (#175)

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Jan 2017 15:12:30 -0800

QUIC borrows the HTTP/2 state machine, or tries to replicate it as much as it can.  Part of that replication is the idea that a stream is bidirectional.  The state related to outgoing data and the state related to inbound data are tied.

#174 suggests a simplification that could open up a more dramatic simplification: independent state for each direction.  #171 moves in that direction also.

The state machine that results from that is dramatically simpler: idle -> open -> closed.  That is, before packets, packets and after packets.

The consequence for the HTTP mapping is largely that it needs a different method for correlating request and response.

## Correlating request and response

Currently, request and response are correlated by matching the stream identifier.  However, unidirectional streams would allow for cases where streams are not created symmetrically.  For instance, server push would only require streams from the server.  Similarly, the server would not be obligated to respond to requests in the order in which they were received (if at all, since it could reset request streams).

That implies that this would add a requirement for the server to identify which request a given stream is answering.  This is an extension of the requirement in #174, which only required that the server identify a push promise (actually, it's less onerous, because you only have one request per stream).

I can imagine an arrangement where a stream containing headers identifies the stream containing the request headers from the client.  Then the stream containing the body identifies the stream that contained the headers.

## Saving stream identifiers

This is a minor point, though it could be relevant for very long-lived connections.

QUIC currently insists on a strictly monotonically increasing stream identifier: stream N is followed by stream N+2 always, no skipping of streams is permitted.  Aside from wasting every other stream identifier, other streams are wasted by the mapping. 

GET requests don't include a body, but nonetheless require that the client send a HEADERS on stream N, then a FIN on stream N+2.  Including a reference to the initiating stream at the start of the body of a message would use some octets, but potentially fewer than would be used otherwise (particularly if the reference was a varlen encoding of the difference in stream numbers, which would rarely be anything other than 1).

Obviously, this is an optimization for the case where there are no bodies, but that is a case where the optimization is particularly valuable.  Making more requests (which more frequently have no bodies) during the early stages of a connection is critical to performance.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/175

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Jan 2017 22:09:45 -0800

Discussed in Tokyo; people need to see a more concrete proposal. @martinthomson to noodle on it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/175#issuecomment-275027676