[multipathtcp] A question related to MPTCP control overhead

Sayee Kompalli Chakravartula <sayee.kompalli.chakravartula@huawei.com> Thu, 06 April 2017 11:18 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 0A5D512785F for <multipathtcp@ietfa.amsl.com>; Thu, 6 Apr 2017 04:18:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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] 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 Wnm1c_k5nHho for <multipathtcp@ietfa.amsl.com>; Thu, 6 Apr 2017 04:18:53 -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 A3889129453 for <multipathtcp@ietf.org>; Thu, 6 Apr 2017 04:18:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEF87322; Thu, 06 Apr 2017 11:18:49 +0000 (GMT)
Received: from BLREML703-CAH.china.huawei.com (10.20.4.172) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 12:18:48 +0100
Received: from BLREML501-MBS.china.huawei.com ([10.20.5.199]) by blreml703-cah.china.huawei.com ([::1]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 16:48:44 +0530
From: Sayee Kompalli Chakravartula <sayee.kompalli.chakravartula@huawei.com>
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: A question related to MPTCP control overhead
Thread-Index: AdKux4amd3XFz/fSRoiWehKw99KRVg==
Date: Thu, 6 Apr 2017 11:18:45 +0000
Message-ID: <5C068B455EB58047BBD492DA2B0829FA3763ADD5@blreml501-mbs>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.213.198]
Content-Type: multipart/alternative; boundary="_000_5C068B455EB58047BBD492DA2B0829FA3763ADD5blreml501mbs_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.58E6241A.0024, 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: b78d7c405c4a2ef4396eed46f5b11330
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/lJzNHe-gPrGM0-FcMk1XrMRJtJc>
Subject: [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: Thu, 06 Apr 2017 11:18:57 -0000

Dear All,
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!


Problem Statement
MPTCP, by design, requires that transmitted data be identified at two levels, namely, the connection-level and the subflow-level, using sequence numbers drawn from the Data Sequence Space (DSS) and the Subflow Sequence Space (SSS), respectively. Sequence numbers from DSS and SSS are called, respectively, Data Sequence Numbers (DSN) and Subflow Sequence Numbers (SSN). This is necessitated because of potential ambiguity that may arise when different portions of the application data is scheduled on different subflows, and also when the same data is replicated on more than one subflow to achieve protection against packet losses. However the protocol, under certain limited specific scenarios, allows transmitted data to be identified using SNs from SSS only. For instance, when MTCP options fail to go through a subflow (either at the beginning or subsequent to the MPTCP connection establishment) or when payload gets modified by a middle box on the path. In other words, MPTCP semantics of the transport connection are replaced with traditional TCP semantics and the semantics change is conveyed, depending on the triggering event, using either Fallback (MP_FAIL) option or DSS Option with Infinite Mapping. In both the cases the transport connection cannot revert to MPTCP semantics later in the connection.

But there are situations which, not covered by above scenarios, require that data is identified using just one sequence space for protocol efficiency. For instance a mobile device, on account of its potential mobility, may see the number of subflows vary with time and whenever there is just one subflow associated with the MPTCP connection, it is generally expected, that efficiency of MPTCP should be at least as good as traditional TCP. Also, with just one subflow there is no data identification ambiguity present in the case in which more than one subflow is associated with the MPTCP connection. But MPTCP, by design, requires that data be identified and also acknowledged using two types sequence numbers in scenarios not covered by either loss of options or payload modification and there is just one subflow under the connection. In other words when triggers, different from loss of option or detection of payload modification, reduce the number of subflows from 2 to 1 MPTCP continues to employ both types of SNs which represents unnecessary control overhead.

The scenarios and the reasons alluded in the above paragraphs call for changes to the protocol behavior which can result in efficient protocol operation. In other words, what we need is seamless switching between traditional TCP semantics and MPTCP semantics for protocol efficiency.





Best Regards,
Sayee
________________________________
Dr. Sayee Kompalli
Lead Architect, 2012 Labs
Huawei Technologies India PVT. LTD.
Bangalore, India