IETF Logo Mail Archive

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

Sayee Kompalli Chakravartula <sayee.kompalli.chakravartula@huawei.com> Sun, 09 April 2017 14:25 UTC

Return-Path: <sayee.kompalli.chakravartula@huawei.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95B128D19 for <multipathtcp@ietfa.amsl.com>; Sun, 9 Apr 2017 07:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.322
X-Spam-Level:
X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7erbRgUgoXGA for <multipathtcp@ietfa.amsl.com>; Sun, 9 Apr 2017 07:25:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 202F512785F for <multipathtcp@ietf.org>; Sun, 9 Apr 2017 07:25:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DKO47311; Sun, 09 Apr 2017 14:25:32 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 9 Apr 2017 15:25:32 +0100
Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0301.000; Sun, 9 Apr 2017 19:55:27 +0530
From: Sayee Kompalli Chakravartula <sayee.kompalli.chakravartula@huawei.com>
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] A question related to MPTCP control overhead
Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVgAruciAAHFvuLA=
Date: Sun, 09 Apr 2017 14:25:27 +0000
Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763CB68@blreml501-mbs>
References: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs> <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be>
In-Reply-To: <34b2d824-c13c-c50f-36f8-708fc463977e@uclouvain.be>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.213.198]
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.0A090206.58EA445D.0028, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 36dc4be7c02fd16e8af772bc154acd9d
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/l_Gm0SBa2gy7YTjK9hJoPQ9Qcls>
Subject: Re: [multipathtcp] A question related to MPTCP control overhead
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Apr 2017 14:25:37 -0000

Dear Olivier,
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.

Sayee


-----Original Message-----
From: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] 
Sent: Friday, April 07, 2017 9:41 PM
To: Sayee Kompalli Chakravartula; multipathtcp@ietf.org
Subject: Re: [multipathtcp] A question related to MPTCP control overhead

Hello,
>
> 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


Olivier

v2.23.0 | Report a Bug | By Email