Re: [quicwg/base-drafts] Handling of a lost push signal (#4930)

[Kazuho Oku <[e-mail]>]

To fix the issue, we have to meet the following two requirements:
1. PUSH_PROMISE never gets lost, and
2. Require either of the following two:
  a. servers to make sure that Push Stream Headers are delivered to the client and clients never send STOP_SENDING frames for push streams until it receives Push Stream Headers, or
  b. change the push identifier to a value that can be guaranteed to be delivered even when the push stream is reset at any moment.

We can meet requirement 1 by sending PUSH_PROMISE on the control stream.

For requirement 2, the difficulty of _a_ is that there's no way of HTTP/3 stacks telling if something is delivered to the client at the transport level. We could introduce an HTTP/3-level acknowledgement frame much like we do in QPACK, but that's going to be complicated.

For option _b_, we might consider getting rid of Push ID and send the stream ID of the push stream on the PUSH_PROMISE frames. We require QUIC stacks to either guarantee the delivery of FIN or RESET_STREAM for the streams that have been used by the sender. The problem here would be that, at the moment, we do not require QUIC stacks have an API to notify HTTP/3 stacks that a stream has been reset when not a single byte of data have been received (we can assume that HTTP/3 stacks would be notified of resets once some bytes have been received and provided to the HTTP/3 stacks). But maybe fixing this would be easier than option _a_.

-- 
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/4930#issuecomment-888818310