[tcpm] Re: About having reset reason in TCP option

[[e-mail]]

Hi Jason,

FWIW, you may find a proposal in https://datatracker.ietf.org/doc/html/draft-boucadair-tcpm-rst-diagnostic-payload-08, which does not require any new option at all. It uses existing TCP provisions (see RFC9293, section 3.5.3).

BTW, do you have in mind reasons other than those in draft-boucadair-tcpm-rst-diagnostic-payload-08#Section-5.2? Thanks.

Cheers,
Med

> -----Message d'origine-----
> De : Jason Xing <[e-mail]>
> Envoyé : jeudi 28 novembre 2024 02:19
> À : [e-mail]
> Cc : Eric Dumazet <[e-mail]>
> Objet : [tcpm] About having reset reason in TCP option
> 
> 
> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8684%23name-mp_tcprst-
> reason-
> codes&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca390029e9d2
> d4975768008dd0f4ad509%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C638683536268372165%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=o0bZ1HdsPosTzS5TCx1KmxU6k55nzYD5KMfGFh
> B2OGY%3D&reserved=0
> [2]:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2
> Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8684%23name-subflow-
> reset&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ca390029e9d2
> d4975768008dd0f4ad509%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%
> 7C638683536268409404%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRy
> dWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyf
> Q%3D%3D%7C0%7C%7C%7C&sdata=6TXZou1JJAEVdqwQBRRd%2Bg33gbiUKWEdNhif
> N5tEzLQ%3D&reserved=0
> 
> 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
> 
> _______________________________________________
> tcpm mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.