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

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Thu, 6 Apr 2017 11:18:45 +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

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 7 Apr 2017 15:40:33 +0200

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

---

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Sun, 9 Apr 2017 14:25:27 +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:[email-masked]] 
Sent: Friday, April 07, 2017 9:41 PM
To: Sayee Kompalli Chakravartula; [email-masked]
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

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 10 Apr 2017 10:06:15 +0200

Hello,

> 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 feasibl…

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.

Olivier

---

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Mon, 10 Apr 2017 08:12:04 +0000

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

Sayee

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

Hello,

> 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 feasibl…

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.

Olivier

---

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Tue, 11 Apr 2017 13:33:51 +0000

Dear Olivier,
I read through the paper "Are TCP Extensions Middlebox-prrof?", and especially focused on the Section 3.3 on Multipath TCP and midleboxes. My comments are as follows:

1. Regarding middleboxes removing options from non-SYN segments:
Currently, MPTCP handles this issue by attaching MPTCP option to every segment in the first window worth of data. An appropriate behaviour is defined for the sender and receiver to fallback to TCP in case middlebox removes the MPTCP option.

In my proposal I say that, instead of appending MPTCP option to segments in the first window worth of data, we defer appending the MPTCP option to segments to a later time just before we establish the second flow and as described below.

We will define an additional state variable DSS_RCV at both the sender and the receiver. At the beginning, this state variable will be initialized to false at both the ends. Now assume that the state variable NUM_SUBFLOW = 1 and DSS_RCV = false at the sender side and that the sender has send the DSS option for the first time. When DSS option is received with its state variable NUM_SUBFLOW = 1 and DSS_RCVD = false, the receiver will understand that the sender has decided to utilize the DSS option, and so it will update its state variable DSS_RCV = true and will ACK the segment that carried the DSS option with its own DSS option. When the sender receives ACK containing DSS option it will update its state variable DSS_RCV = true. Assuming that middlebox removes the DSS option included by the sender, the receiver will acknowledge the segment without DSS option. Because the ACK segment does carry DSS option the sender will fall back.

2. To cope with sequence number randomizers:
The same approach works with my proposal too, but with one little observation. Whenever the state variable NUM_SUBFLOW transitions from two to one, all the DSS related information is discarded, i.e., the space of DSNs and the mapping are removed from the protocol control block. But, when the state variable NUM_SUBFLOW again transitions from one to two, the space of DSNs will be created to establish mapping between SSS and DSS with one little difference: unlike when the MPTCP connection is established, for the subflow 1 we will not map the first DSN to subflow sequence zero but to the running subflow SN at that time. 

3. Regarding middlebox performing segment splitting or coalescing:
This behaviour of middlebox poses as much risk to my way of doing things as it does to the existing MPTCP specification. Because the existing mitigation does not depend on whether we continue to support DSNs on MPTCP connection consisting of just one subflow, the same solution will continue to work whether or not we support DSS for MPTCP connection consisting of just one subflow.

4. ALG modifying the data stream by adding or removing bytes from the payload:
This issue is relevant when a MPTCP option is included in a segment, and the same protocol behaviour will work in my case too.

I haven't prepared a detailed write-up to share with IETF folks, which I will do once I am fairly confident that I have worked out all corner cases.

Sayee

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

Hello,

Olivier

---

From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <[email-masked]>
Date: Tue, 11 Apr 2017 14:02:50 +0000

Hi Sayee,

I am not quite sure I understand how you are keeping sequence numbers straight for the case where you drop from 2 subflows to 1 subflow and want to stop using the DSS. Could you provide some details? What do you do when there is outstanding data on the subflow that goes away?

Thanks,
Matt

> On Apr 11, 2017, at 9:33 AM, Sayee Kompalli Chakravartula <[email-masked]> wrote:
> 
> Dear Olivier,

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 12 Apr 2017 09:15:48 +0200

Sayee,

> We will define an additional state variable DSS_RCV at both the sender and the receiver. At the beginning, this state variable will be initialized to false at both the ends. Now assume that the sta…

MPTCP as defined in RFC6824 supports both make-before-break and 
break-before-make, i.e. the
second subflow can be established at any time, either before or after 
the failure of the initial one. With your design, you force a 
make-before-break, this means that something has to be done (namely 
start uses DSS) before being able to create the second subflow. This is 
annoying because failover is one of the nice features of Multipath TCP.

> The same approach works with my proposal too, but with one little observation. Whenever the state variable NUM_SUBFLOW transitions from two to one, all the DSS related information is discarded, i.e…

I fear that a solution that tries to avoid DSS when there is a single
subflow and uses DSS as soon as there are two subflows would be very 
difficult to use. How do the client and the server agree that there are 
one or more subflows ? At a given time, they might have a different view 
of the state of the Multipath TCP connection.

Olivier

---

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Wed, 12 Apr 2017 07:33:57 +0000

Olivier,
I think I started on the wrong foot discussing solution first before requesting the group to discuss merits of disabling the DSS Option.
A solution that I thought of will not work in all scenarios, so I need to think of a more robust solution. But before we can do that, I would love to hear others of their opinion on disabling the DSS Option. If there is consensus, we can certainly work out a solution. I'm yet to write up my not to elegant solution:(

Sayee

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2017 3:16 PM
To: Sayee Kompalli Chakravartula; [email-masked]
Subject: Re: [multipathtcp] A question related to MPTCP control overhead

Sayee,

> We will define an additional state variable DSS_RCV at both the sender and the receiver. At the beginning, this state variable will be initialized to false at both the ends. Now assume that the sta…

MPTCP as defined in RFC6824 supports both make-before-break and break-before-make, i.e. the second subflow can be established at any time, either before or after the failure of the initial one. With your design, you force a make-before-break, this means that something has to be done (namely start uses DSS) before being able to create the second subflow. This is annoying because failover is one of the nice features of Multipath TCP.

> The same approach works with my proposal too, but with one little observation. Whenever the state variable NUM_SUBFLOW transitions from two to one, all the DSS related information is discarded, i.e…

I fear that a solution that tries to avoid DSS when there is a single subflow and uses DSS as soon as there are two subflows would be very difficult to use. How do the client and the server agree that there are one or more subflows ? At a given time, they might have a different view of the state of the Multipath TCP connection.

Olivier

---

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Wed, 12 Apr 2017 13:03:24 +0000

Hi Matt,
I can think of two ways in which a TCP connection can go down: gracefully or ungracefully. Assume that there are two subflows, SF1 and SF2, and that SF2 is to be brought down. If SF2 goes down ungracefully, we have no cleaner way of informing the receiver that the sender is disabling DSS, and so this leaves us with two choices: (i) continue to use DSS on SF1, or (ii) define a new Option Subtype or a reserved bit of the DSS Option through which the sender can explicitly inform the receiver that it is disabling DSS. I believe that the later choice is the cleaner way of disabling the DSS option. When SF2 goes down ungracefully, we of course need to retransmit the outstanding bytes on SF1, similar to what the MPTCP specification requires.

The not-so-cleaner way of doing things is fragile and convoluted, so I would not want to discuss that here.

If the connection is closed using the RST bit: after sending RST, the sender immediately closes the socket, so the MPTCP sender has no way of knowing whether the receiver indeed received the RST bit. In fact, the RST bit may be lost in the transit. I would put this case in the category of ungraceful shutdown.

If the connection is closed using the FIN bit: Let us represent a SN as x_{i,j} where the subscript i denotes the type of sequence space (SSN or DSN) and the subscript j gives the subflow ID. Let x_{DSN, SF2} be the DSN of the last byte transmitted before FIN is sent on SF2 and that x_{DSN, SF1} be the last DSN mapped to SF1 before the DSS Option is disabled by the sender. In this context we need to consider two possibilities: x_{DSN, SF1} < x_{DSN, SF2} and x_{DSN, SF1} >= x_{DSN, SF2}. Now consider the case x_{DSN, SF1} < x_{DSN, SF2}. When a data byte is received on SF1 that is not covered by DSN we know where to place that data byte with respect to the data byte whose DSN is x_{DSN, SF1} using subflow sequence number of the data byte. Because, eventually, data bytes need to be ordered based on DSN before releasing to the application layer we still need to decide where to place this data byte at the connection-level with respect to x_{DSN, SF2}, and this is where the protocol will run into ambiguity: whether to place the data byte before or after x_{DSN, SF2}. This will lead to protocol dead-lock. Next, we consider the possibility x_{DSN, SF1} >= x_{DSN, SF2}. Here we do not have the ambiguity present in the previous context. The received data byte on SF1 will have to be placed to the right of both x_{DSN, SF1} as well as x_{DSN, SF2} and the actual placement on SF1 will be determined by the SSN of the data byte.

The above analysis helps us to decide how and when DSS Option can be disabled. After sending the FIN on SF2, continue sending the DSS option on SF1 until the largest DSN used on SF1 is at least as large as x_{DSN, SF2} and the state variable NUM_SUBFLOW has transitioned to 1, and then disable the DSS Option. To describe the receiver behaviour, the receiver expects to continue to receive data bytes covered with DS mapping on SF1 until the largest DSN mapped to SF1 is at least as large as x_{DSN, SF2}. After then, starting with the first received byte that is not covered with DSN, the receiver will understand that the sender has disabled DS mapping on SF1.

At this point, I like to believe that defining a new Option Subtype or utilizing an unused bit in the DSS option will be fruitful.

Except in some specific scenarios, like a data center, I don't think a device can know in advance if second interface becomes available during the connection. So if the users goes with TCP then he is at disadvantage because he cannot utilize additional interfaces when they become available. If he opens MPTCP connection hoping that new interfaces may become available in the future, until then the connection has to incur control overhead due to redundant DSS Option. 

As a first-cut solution I think we should allow a MPTCP connection not to use the DSS option until it opens the second subflow. To keep things simple, we may say that once DSS Option is enabled it will be enforced until the MPTCP connection is closed.

Sayee

-----Original Message-----
From: Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies] [mailto:[email-masked]] 
Sent: Tuesday, April 11, 2017 10:03 PM
To: Sayee Kompalli Chakravartula
Cc: [email-masked]; [email-masked]
Subject: Re: [multipathtcp] A question related to MPTCP control overhead

Hi Sayee,

Thanks,
Matt

---

From: "Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]" <[email-masked]>
Date: Wed, 12 Apr 2017 13:33:57 +0000

Hi Sayee,

Thanks for the response! What you are proposing is clearer to me now. I misunderstood part of a previous email:

> The same approach works with my proposal too, but with one little observation. Whenever the state variable NUM_SUBFLOW transitions from two to one, all the DSS related information is discarded, i.e., the space of DSNs and the mapping are removed from the protocol control block.
> 

I thought the proposal was originally to stop using the DSS as soon as a subflow goes away without any sort of signaling, which I could not grok. :-) I'm glad to see I was mistaken. I will try to think over your proposal in more depth beyond my quick reading of it just now.

Thanks,
Matt

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 12 Apr 2017 16:08:06 +0200

Hi Sayee,

> I can think of two ways in which a TCP connection can go down: gracefully or ungracefully. Assume that there are two subflows, SF1 and SF2, and that SF2 is to be brought down. If SF2 goes down ungr…

For a Multipath TCP connection, subflows can fail in other ways as well. 
It is also possible that the source IP address associated to a subflow 
is not assigned anymore to the host, this is the typical example of a 
smartphone that looses WiFi. Another subflow failure scenario is a 
subflow that stops after n retransmissions of the same data. These 
failures do not stop the MPTCP connection.

> If the connection is closed using the RST bit: after sending RST, the sender immediately closes the socket, so the MPTCP sender has no way of knowing whether the receiver indeed received the RST bi…

A subflow can fail due to RST sent by a middlebox. This should not close 
the corresponding MPTCP connection.

> As a first-cut solution I think we should allow a MPTCP connection not to use the DSS option until it opens the second subflow. To keep things simple, we may say that once DSS Option is enabled it…

On smartphones a solution would need to support break-before-make to be 
useful. This means that we cannot terminate the subflow with a FIN 
before deciding to switch to the utilisation of DSS. This fact, coupled 
with middleboxes that can transparently add/remove data from the 
bytestream make the problem difficult to solve

Olivier

---

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Thu, 13 Apr 2017 05:17:41 +0000

Hi Olivier,
My comments are inline. I couldn't find a cleaner way of embedding my comments inline using Outlook, sorry about that. My comments start with the tag <<Sayee>>. Soon I will try to switch to gmail.

Sayee

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Wednesday, April 12, 2017 10:08 PM
To: Sayee Kompalli Chakravartula; Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
Cc: [email-masked]
Subject: Re: [multipathtcp] A question related to MPTCP control overhead

Hi Sayee,

For a Multipath TCP connection, subflows can fail in other ways as well. 
It is also possible that the source IP address associated to a subflow is not assigned anymore to the host, this is the typical example of a smartphone that looses WiFi. Another subflow failure scenario is a subflow that stops after n retransmissions of the same data. These failures do not stop the MPTCP connection.

<<Sayee>> Agree with you that a subflow can fail in many more ways other than what I mentioned. I were only trying to bring out the observation that in not all scenarios the receiver and the sender can agree that a subflow went down and accordingly update the state variable NUM_SUBFLOW, because such a determination is fraught with unpredictable behavior.

> If the connection is closed using the RST bit: after sending RST, the sender immediately closes the socket, so the MPTCP sender has no way of knowing whether the receiver indeed received the RST bi…

A subflow can fail due to RST sent by a middlebox. This should not close the corresponding MPTCP connection.

<<Sayee>> I didn't say that RST will close the MPTCP connection. I should have, instead, said "if the subflow is closed using the RST bit:"

> As a first-cut solution I think we should allow a MPTCP connection not to use the DSS option until it opens the second subflow. To keep things simple, we may say that once DSS Option is enabled it…

On smartphones a solution would need to support break-before-make to be useful. This means that we cannot terminate the subflow with a FIN before deciding to switch to the utilisation of DSS. This fact, coupled with middleboxes that can transparently add/remove data from the bytestream make the problem difficult to solve

<<Sayee>> Can you please elaborate on this scenario, as I do not seems to get what you were implying?

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 14 Apr 2017 11:50:44 +0200

Sayee,

> <<Sayee>> Can you please elaborate on this scenario, as I do not seems to get what you were implying?

A very annoying corner case is the following one :

A smartphone creates an MPTCP connection over WiFi. The 
three-way-handshake is done correctly. After a few seconds, the 
smartphone sends some data but it has moved out of reach of the WiFi 
network and it does not receive acknowledgements for this data. From the 
information exchanged over the WiFi, the smartphone cannot know whether 
the data has been received by the server or not.

The smartphone then opens a subflow over the LTE interface. Once the 
subflow is established, it can be used to send data with the DSS option. 
Note that during the three-way handshake for the initial subflow, the 
client and the server have agreed on the initial sequence numbers for 
the two directions of the transfer. This means that when the first data 
arrives on the LTE subflow with a DSS option, the server can determine 
whether this is the first data of the bytestream or other data and then 
it would need to wait for the first data before delivering it to its 
application.

If you remove the DSS on the initial subflow, then I do not see any way 
for the server to cope correctly with this scenario. Note that sequence 
number randomisation affects the sequence numbers that the smartphones 
and the server see.

Olivier

---

From: Sayee Kompalli Chakravartula <[email-masked]>
Date: Fri, 14 Apr 2017 11:33:02 +0000

Olivier,
I got the point, and thanks for the clarification. I were under the impression that existence of MPTCP connection implies that existence of at least one subflow, which clearly cannot be true always as your corner case illustrates.

Sayee

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Friday, April 14, 2017 3:21 PM
To: Sayee Kompalli Chakravartula; Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
Cc: [email-masked]
Subject: Re: [multipathtcp] A question related to MPTCP control overhead

Sayee,

> On smartphones a solution would need to support break-before-make to 
> be useful. This means that we cannot terminate the subflow with a FIN 
> before deciding to switch to the utilisation of DSS. This fact, 
> coupled with middleboxes that can transparently add/remove data from 
> the bytestream make the problem difficult to solve
>
>
>

A smartphone creates an MPTCP connection over WiFi. The three-way-handshake is done correctly. After a few seconds, the smartphone sends some data but it has moved out of reach of the WiFi network and it does not receive acknowledgements for this data. From the information exchanged over the WiFi, the smartphone cannot know whether the data has been received by the server or not.

The smartphone then opens a subflow over the LTE interface. Once the subflow is established, it can be used to send data with the DSS option. 
Note that during the three-way handshake for the initial subflow, the client and the server have agreed on the initial sequence numbers for the two directions of the transfer. This means that when the first data arrives on the LTE subflow with a DSS option, the server can determine whether this is the first data of the bytestream or other data and then it would need to wait for the first data before delivering it to its application.

If you remove the DSS on the initial subflow, then I do not see any way for the server to cope correctly with this scenario. Note that sequence number randomisation affects the sequence numbers that the smartphones and the server see.

Olivier