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

Olivier Bonaventure <> Mon, 10 April 2017 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22503129447 for <>; Mon, 10 Apr 2017 01:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 fiCIBGnJ3y4y for <>; Mon, 10 Apr 2017 01:06:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02A39129423 for <>; Mon, 10 Apr 2017 01:06:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id A8D8167DCE3; Mon, 10 Apr 2017 10:06:12 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 A8D8167DCE3
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1491811572; bh=MVW9Fqx5pm/x+hMQzqcuplNVX0LO9eYJP7yqNfxxTPE=; h=Reply-To:Subject:References:To:From:Date:In-Reply-To; b=MvCJeul3HhoTBoqoRxlyuvcTI0AVqJrdT25fIIyuxy4i+MmzqxwAkfkpiM8bp1xd/ TncEwTkprQtc0k7ZKCg6wRj1R6T/mXJUqhRvixdQUFYvMkSu3wqAmDcwRI/I78X2VU TqC6SBE/QdXa3oGvYkE22eEyEwXSW9KEDxotS524=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2
References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs>
To: Sayee Kompalli Chakravartula <>, "" <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Mon, 10 Apr 2017 10:06:15 +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: <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: A8D8167DCE3.A4BEA
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: Mon, 10 Apr 2017 08:06:23 -0000


> Thanks for the response. While preparing reply to your observation, I came across your 2013 Sigcomm paper "Are TCP Extensions Middlebox-proof?", and I believe that I should read that paper before I reply you.
> I thought of a rough sketch of solution without regard to what middleboxes can do, which essentially assumes a state-machine at both ends. Before I embark on designing a solution, if at all feasible, I wanted to know how others think of such an issue. Hope to reply you soon.

My fear is that any solution would introduce a significant change to 
Multipath TCP. We have evidence from the widespread utilisation of 
Multipath TCP by Apple for Siri that the current design (DSS in all 
segments, including initial subflow) works well in today's Internet. 
Changing this part for rfc6824bis looks very risky to me.