[multipathtcp] A question related to MPTCP control overhead

[Sayee Kompalli Chakravartula <[e-mail]>]

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