Re: [multipathtcp] 6824bis -11 review

[Rahul Arvind Jadhav <[e-mail]>]

> > > [RJ]: Since a MP_TCPRST should be associated with this RST, what should
> be the corresponding Reason Code that can be used in MP_TCPRST for this
> case? I checked existing reason codes in section 3.6 and none of those made
> sense (may be except for 0x0 ?).
> >
> > That’s an interesting one. There may be some benefit (maybe for
> middleboxes, or maybe for security) to sharing this information in the RST
> with an explicit reason code. We could add one - but I would be interested in
> hearing other opinions.
> 
> We could add one that indicates that the RST is upon a response of an
> incoming MPTCP-option (e.g., responding to a REMOVE_ADDR, a
> MP_FASTCLOSE,...).
> 

Some more points in context to MP_TCPRST:
1. There are several cases of MP_TCPRST where there is no mention of Reason Code to be used. Can the Reason Code be explicitly stated for known cases?  Consider foll sections:
	a. Section 3.2. Starting a New Subflow
	"If the token is unknown, or the host wants to refuse
	subflow establishment (for example, due to a limit on the number of
   	subflows it will permit), the receiver will send back a reset (RST)
   	signal, analogous to an unknown port in TCP, containing a MP_TCPRST
   	option (Section 3.6) with an appropriate reason code."

	-----[There is a duplicate sentence in the same section]----

	"If the token received at Host B is unknown or local policy prohibits
   	the acceptance of the new subflow, the recipient MUST respond with a
   	TCP RST for the subflow, with a MP_TCPRST option (Section 3.6) with
   	an appropriate reason code."

	b.  Section 3.3.2.
	"In this case, the MPTCP sender can decide to terminate the subflow 
	that is behaving badly by sending a RST, using an appropriate MP_TCPRST 
	(Section 3.6) error code."

	c. Section 3.3.6.
	"A RST for this purpose SHOULD be accompanied with
	an appropriate MP_TCPRST option"

	d. Section 3.7.
	"This RST SHOULD include the MP_TCPRST option
	 (Section 3.6) with an appropriate reason code."

	e. Section 3.7
	"The data would not be DATA_ACKed
   	(since there is no mapping for the data), and the subflow can be
   	closed with a RST, containing a MP_TCPRST option (Section 3.6) with
   	an appropriate reason code."

2. Can we have an user-defined Reason-Code block for implementations to define their own Reason-code within the block without worrying for future reason-code addons?