Re: [multipathtcp] 6824bis -11 review

Rahul Arvind Jadhav <> Thu, 02 August 2018 00:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54A97130ECA for <>; Wed, 1 Aug 2018 17:58:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8JnwqBi3ReUa for <>; Wed, 1 Aug 2018 17:58:16 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BEDE128CF3 for <>; Wed, 1 Aug 2018 17:58:16 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 4D01EDBC3B3C for <>; Thu, 2 Aug 2018 01:58:11 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 2 Aug 2018 01:58:12 +0100
Received: from ([]) by ([::1]) with mapi id 14.03.0399.000; Thu, 2 Aug 2018 06:27:57 +0530
From: Rahul Arvind Jadhav <>
To: "" <>, Alan Ford <>
CC: multipathtcp <>
Thread-Topic: [multipathtcp] 6824bis -11 review
Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgARMycAAMlvQQAAGrSboA==
Date: Thu, 02 Aug 2018 00:57:56 +0000
Message-ID: <>
References: <> <> <20180801172658.GF1362@MacBook-Pro-19.local>
In-Reply-To: <20180801172658.GF1362@MacBook-Pro-19.local>
Accept-Language: en-IN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [multipathtcp] 6824bis -11 review
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Aug 2018 00:58:18 -0000

> > > [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

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?