Re: [multipathtcp] A question related to MPTCP control overhead

Olivier Bonaventure <> Fri, 07 April 2017 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 118B112420B for <>; Fri, 7 Apr 2017 11:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.729
X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sriI34RZgy10 for <>; Fri, 7 Apr 2017 11:59:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADAEE12704B for <>; Fri, 7 Apr 2017 11:59:09 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 3522B67DE95; Fri, 7 Apr 2017 20:59:02 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 3522B67DE95
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1491591542; bh=96zzEwb1Jt6aLhzyyd3woFceWFjcP2n1dhl2yHSw2YU=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=ip0Xt06iiDAx8Juf4if4e6FrWfzhkQj0k1J9oKLI+3eH0uVRBrxX1VwuGkofu2wTR pipDPv5DI7xd5sYOVZ24+CQfgwNOQ0/RSJBE5VNgI6ZviJbQ1ffww8oODFmg1ag0Lh bXA2VWXSC+c8kz9eo4+re1kCtX/dMdXzOQSU2ZJ0=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-5
References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs>
To: Sayee Kompalli Chakravartula <>, "" <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Fri, 07 Apr 2017 15:40:33 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 3522B67DE95.A20D7
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Subject: Re: [multipathtcp] A question related to MPTCP control overhead
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Apr 2017 18:59:12 -0000

> This is the first time I’m posting a question to the group!! I work for
> Huawei Technologies, India at Bangalore. For quite some time I’ve been
> reading material on MPTCP, and of late, I have been thinking of a
> potential issue related to MPTCP control overhead. I’m wondering whether
> the issue I articulated in the following is worth considering, and if
> so, I would love to hear opinion from the members of the group. I thank
> you all in advance!

Thanks for your email. Bascially, you would like to have a Multipath TCP 
connection that starts without DSS on this initial subflow and then 
enables the DSS when a second subflow has been established.

This would reduce the overhead when MPTCP connections are composed of a 
single subflow. However, in the presence of middleboxes, it looks very 
difficult to design a solution that would preserve connectivity under 
all circumstances.

Assume that MPTCP starts without any DSS option and only uses them after 
the establishment of the second subflow. If the bytestream has been 
affected by a middlebox (e.g. a NAT with an FTP ALG) that adds or remove 
bytes in the payload, when MPTCP will switch to using the DSS? they will 
be desynchronised with the actual sequence numbers that the receiver 
observers. There are other corner cases where DSS options are removed 
from packets with data but not from SYNs that could also result in 
various problems.

The idea looks nice, but there are unfortunately many devils hidden in 
the details