HTTP/3 websockets and RESET_STREAM/STOP_SENDING

[martinthomson]

The draft currently says how TCP RST is propagated to HTTP/3, but not how RESET_STREAM and STOP_SENDING are propagated to TCP.

Unlike HTTP/2, we have two independent actions here. I think that the answer is to advise a server to send a TCP RST if it gets either. I would also suggest that we recommend that servers send RESET_STREAM in response to RESET_STREAM and STOP_SENDING in response to STOP_SENDING (in addition to the required RESET_STREAM in that case) to maintain that consistency at the HTTP/3 side.

[LPardue]

We need to say something, but does that something need to be distinctly different than what HTTP/3 already says in https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34#section-4.2?

[martinthomson]

Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection. If the underlying TCP implementation permits it, the proxy SHOULD send a TCP segment with the RST bit set.

I think that could be improved in h3, frankly. Not the TCP RST part, but to ensure that this results in correct behaviour. If the proxy just closes the connection in response to RESET_STREAM, it might result in sending FIN on the stream, which would be wrong.

Correspondingly, if a proxy detects an error with the stream or the QUIC connection, it MUST close the TCP connection. Similarly, if the proxy receives a QUIC RESET_STREAM frame or STOP_SENDING frame, it MUST close the TCP connection. A proxy that receives RESET_STREAM or STOP_SENDING MUST also send the same frame so that both sending directions of the stream are cancelled. In all these cases, if the underlying TCP implementation [...]

Probably something for the still-open QUIC-patient to manage though, if you would prefer that.

[RyanTheOptimist]

I definitely agree that clarifying the expected usage of STOP_SENDING/RESET_STREAM in HTTP/3 seems like a clearly good idea. Since this doc references 4.2 of HTTP/3, if that happens do we think we'll still need to include some of that language here? (I don't mind doing that but also don't want to be redundant)

[mnot]

Can we close this issue, then (regarding THIS spec)?

[LPardue]

WRT to HTTP/3. We'll be issuing a consensus call on the proposed change quicwg/base-drafts#4939 soon.

Should that confirm consensus the editors will be directed to incorporate the changes during AUTH48. Should it fail consensus, that would place this issue is a strange predicament.

[mnot]

@LPardue any update on 4939?

[LPardue]

We declared consensus on the proposed resolution on Nov 22 - https://mailarchive.ietf.org/arch/msg/quic/SJvp7IRV7otLI2wDuf4jjPvi0aU/

I'd be happy with this issue getting closed since QUIC has it in hand.

[RyanTheOptimist]

Excellent! I'll close this then.