Proposal: FINAL_DATA

[bemasc]

This adds a FINAL_DATA capsule type to make clean shutdown explicit.

[DavidSchinazi]

I do think we should add a FINAL_DATA. It allows for example sending metadata after the stream is gracefully closed. I can imagine using that to send capsules that contain TCP performance info

[kazuho]

Thank you for opening the new issue dedicated to FINAL_DATA.

@DavidSchinazi

I do think we should add a FINAL_DATA. It allows for example sending metadata after the stream is gracefully closed. I can imagine using that to send capsules that contain TCP performance info

I think the question is if we would benefit from being able to observe the ordering between close and metadata; if there is, then it makes sense to have a frame indicating close. Otherwise, it is waste, considering that most underlying layers (HTTP/2, HTTP/3, TLS) already provide ways to distinguish between graceful shutdown and abrupt close.

For things like performance information, I don't think there would be material difference in sending them right before or after signalling the closure. I'd assume that we would allow such information to be sent at any moment during the lifetime of the tunnel, and that receivers would record whatever they receive. Senders that want to emit most recent information can send performance information at the moment they notice the TCP tunnel getting closed, and close the tunnel.

Separately, if we have the interest in sending metadata after closure, I am not sure if such interest applies only to graceful close and not to resets? To paraphrase, it might make more sense to define a frame that conveys closure and how it is closed (i.e., graceful or reset), rather than FINAL_DATA that only signals graceful shutdown.

[DavidSchinazi]

Otherwise, it is waste

What is wasted? This just requires registering a capsule type, which is a 2^62 registry. In most cases, the proxy will send the last bit of data inside a FINAL_DATA capsule. In the unusual scenario where it learns about the FIN after it sent its last DATA capsule, then it does need to send 2 bytes.

allow such information to be sent at any moment during the lifetime of the tunnel

FWIW, the lifetime of the tunnel is already somewhat disconnected from the TCP FIN since a FIN only closes one side of the connection. I see a value in telling the peer that TCP closed gracefully while reserving the right to send future capsules in response to something the peer sends.

it might make more sense to define a frame that conveys closure and how it is closed (i.e., graceful or reset), rather than FINAL_DATA that only signals graceful shutdown.

Having a third capsule like DATA_ABORTED doesn't seem unreasonable to me.

[PiotrSikora]

it might make more sense to define a frame that conveys closure and how it is closed (i.e., graceful or reset), rather than FINAL_DATA that only signals graceful shutdown.

+1