Re: Unreliable Stream Support for QUIC

["Philipp S. Tiesel" <[e-mail]>]

> On 5. Sep 2017, at 19:20, Lucas Pardue <[e-mail]> wrote:
> 
> Hi Philipp,
> 
> Thanks for publishing these. I've only had a chance to skim read so I only have a basic question right now.
> 
> For the HTTP/QUIC mapping, have you considered server push? The document doesn't mention anything but I wonder if you have some ideas. I'm thinking that the push promise includes your request header to indicate to the client that the pushed body will be unreliable. An alternative would be to have all pushed streams inherit the reliability of the parent stream. 

We have not thought about server push yet.

As the server knows from the QUIC handshake that the client, in principle, supports unreliable streams, HTTP/2 can use this knowledge.

For draft-04, I agree with your first proposal, as the push-promise headers should be the same as the request headers. The push stream is then opened as unreliable stream.
 
For draft-05, the Server push description looks kind of broken to me. It still references the request/response streams as used in -04 and the frames needed for reference are gone.
Assuming a sensible implementation with a new stream first carrying a PUSH_PROMISE frame, then a bunch of DATA frames, the server must open the push stream as unreliable and only retransmit the content of the PUSH_PROMISE and probably late HEADERS frames.

While I linke the design and will include it in the next version of the draft, I fear it might not work well over multicast.

AVE!
  Philipp S. Tiesel / phils…