CLOSE_WEBTRANSPORT_SESSION and connection termination

[LPardue]

Section 5 rightly points out the caveats with trying to close a session in unison with a connection

In some scenarios, an endpoint might want to send a CLOSE_WEBTRANSPORT_SESSION with detailed close information and then immediately close the underlying QUIC connection. If the endpoint were to do both of those simultaneously, the peer could potentially receive the CONNECTION_CLOSE before receiving the CLOSE_WEBTRANSPORT_SESSION, thus never receiving the application error data contained in the latter. To avoid this, the endpoint SHOULD wait until all of the data on the CONNECT stream is acknowledged before sending the CONNECTION_CLOSE; this gives CLOSE_WEBTRANSPORT_SESSION properties similar to that of the QUIC CONNECTION_CLOSE mechanism as a best-effort mechanism of delivering application close metadata.

This text has some problems though.

It seems to assume that implementations would surface QUIC stream data acknowledgments, that's not a strict requirement of QUIC.

I'm not sure it accomodates intermediaries. The capsule is end-to-end, so even if the data is delivered to the next hop, there is not guarantee that the end peer really received it.

Stream data transport acknowledgment does not guarantee that applications even read the data.

Are the recommendations really that useful for the use case stated? If an endpoint wants to close both things simultaneously, it could just send the CONNECTION_CLOSE with a Webtransport error code and the reason phrase can hold the details. The capsule is superfluous in this case. The capsulebis most useful when an endpoint wants to close the session independent of the connection.

[LPardue]

Or maybe, if we want solution that is fully intermediary safe, then there should be a close ack capsule?

[bwoebi]

Can we just require the peer to instead close the CONNECT stream upon receipt of the CLOSE_WEBTRANSPORT_SESSION capsule? That way the peer will definitely have received it on the application layer.
And the initiating side of the close may move ahead with closing the whole connection upon receipt of the stream close.

[ekinnear]

Discussed in editor's meeting:

• Can send CLOSE_WEBTRANSPORT_SESSION and not do anything more
• When you receive CLOSE_WT_SESSION, you close the CONNECT stream
• If you wanted to close the QUIC tunnel, you wait until all CONNECT streams are closed, then take down the tunnel

In other words, stream ending in both directions is sufficient.
We already have some similar text around session termination, we can probably pull that up and make it consistent.

Need to be careful since they could also have chosen to close the session independently. This is probably okay because if the other side went away, we may not care.