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

Sayee Kompalli Chakravartula <> Mon, 10 April 2017 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2547129458 for <>; Mon, 10 Apr 2017 01:12:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0EOK6Xb8zSXL for <>; Mon, 10 Apr 2017 01:12:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3EF90129423 for <>; Mon, 10 Apr 2017 01:12:16 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DEK88775; Mon, 10 Apr 2017 08:12:13 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 10 Apr 2017 09:12:09 +0100
Received: from ([]) by ([::1]) with mapi id 14.03.0301.000; Mon, 10 Apr 2017 13:42:04 +0530
From: Sayee Kompalli Chakravartula <>
To: "" <>
Thread-Topic: [multipathtcp] A question related to MPTCP control overhead
Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLAAGcM3gAALlJIA
Date: Mon, 10 Apr 2017 08:12:04 +0000
Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763CE4B@blreml501-mbs>
References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <> <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58EB3E5E.0030, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: a0463539eab111a4ad5997dd5aeeadcd
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:12:19 -0000

I do not intend to suggest any change to rfc6824bis in the immediate future! Nevertheless, I will try to design a solution and, when confident, I will bring it to IETF's attention.


-----Original Message-----
From: Olivier Bonaventure [] 
Sent: Monday, April 10, 2017 4:06 PM
To: Sayee Kompalli Chakravartula;
Subject: Re: [multipathtcp] A question related to MPTCP control overhead


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