[tcpm] About having reset reason in TCP option

[Jason Xing <[e-mail]>]

Hello experts/tcpm-ers :)

I'd like to make a request to write the TCP reset reason feature as a
proposed standard RFC. It's my first time doing this, so if there is
something wrong or inappropriate, please let me know. Thanks in
advance.

The outline of the full draft would be like this:
1. explicitly define each possible reset reason with corresponding and
accurate meaning, say, TCP_LINGER_REASON, which stands for the socket
enables the linger option and then triggers the reset process.
2. negotiate first during a 3-way handshake, like the SACK permitted field.
3. If both sides enable this feature on, then let the sending side
that enters the reset process and puts the specific reset reason into the TCP
option in the RST packet. Then the other side will parse the TCP
option from the RST packet it receives and then detect what is going
on. Also, users
who use tcpdump can get benefits from this without guessing any more.
Default mode could be off.

MPTCP has already implemented this part in the kernel (please see
MPTCP_RST_EUNSPEC), which follows the RFC 8684[1].

I think the final format in TCP could be like [2].

[1]: https://datatracker.ietf.org/doc/html/rfc8684#name-mp_tcprst-reason-codes
[2]: https://datatracker.ietf.org/doc/html/rfc8684#name-subflow-reset

I've privately discussed with Eric, Neal, Yuchung (which are the TCP
maintainers in Linux kernel) before this. Then I'd like to hear more
opinions from this mailing list. Any suggestions are always welcome!!!

Thanks,
Jason