[multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE)

[<[e-mail]>]

Hi all,

My name is Markus Amend from Deutsche Telekom Research & Innovation and I want to propose an idea how to make MPTCP robust against outages during establishment process of the initial flow. I want to start the discussion right now in advance to the IETF 99 meeting, where I will present this topic for discussion. It would be appreciated to receive some feedback in advance.

--- Let's start with a short motivation ---

A proposal for MPTCP Robust session Establishment (MPTCP RobE), related to the real world problem: What happens if the default gateway (GW) does not provide end-to-end connectivity, but an additional route is available? 

I guess, all of you already faced the problem with your smartphone (or any other device with more than one interface), connected to a bad WiFi, where you manually switched off the WiFi interface to have at least connectivity or a more stable connection over cellular network. This happens, because your smartphone decides for you to use the cheaper way, the WiFi way, but it doesn't take care about reachability and stability. So, whenever a physical WiFi connectivity is given, the smartphone puts the default GW to it. In the worst case, the WiFi is not able to establish an end-to-end connectivity and it will fail, even if a proper cellular connectivity is available at the same time. The problem is not just related to smartphone implementations, it is related to any device with more than one interface available!

MPTCP implementations struggle with this as well and even more aggravated, because MPTCP promises apparently redundancy if more the one path to destination is available. But this isn't the case all the time, why?

MPTCP relies on a concept of an initial flow, which has to be established first, to negotiate MP capability and afterwards proceeds to establish subsequent flows to enable redundancy or even capacity aggregation. If the initial flow fails to establish a (MP-)TCP connection, MPTCP will never make use of other available paths and from an application view, there is no connection possible.

To summarize at this point again, first we need a proper initial flow establishment before subsequent flows can be established and exploit multipath capabilities. Also in a scenario where we have a lot of working paths available, but the path used for the initial flow (mostly the default GW, or more generic: default route) is unable to finish handshaking, we end in a zero connectivity scenario.

We demand:

"If there is at least one functional path, a connection must be possible"

With the idea of MPTCP Robust Establishment "MPTCP RobE" we try to solve or mitigate the challenge of blocked or unstable path during initial flow establishment and it would shift the full multipath capabilities to the very beginning of a MPTCP session.

--- stop motivation ---


--- start rough description ---

Over the last year we developed three proposals, to tackle the challenge. We tried to meet the following criteria:

1. Robustness: If there is at least one functional path, a connection must be possible

2. Overhead and latency: The solution should not introduce excessive amounts of overhead and latency compared to standard MPTCP 

3. Standard compliance: A solution should use and integrate with existing standards and work around limitations

In general, all proposals make use of redefining the initial flow towards a >potential< initial flow. That gives the freedom to use several potential initial flows at the very beginning of a session or shift the potential flows between different path. Technically it is based on duplicating the MP_CAPABLE option.

Following the proposals (which will be explained in detail first during the IETF 99 session), which all includes at least the first criteria:

1. "Downgrade" approach:
   Start on all available path potential initial flows, the first successful one remains as the initial flow the others are "downgraded" to subsequent ones.

2. "Break before Make" approach:
   Start on all available path potential initial flows, first successful one remains as the initial flow the others are reset. Standard MPTCP procedure follows to establish subsequent flows

3. "Timer" approach:
   One potential initial flow is started, if during a defined time slot no establishment becomes apparent, a separate potential initial flow is started on another path. 

Currently the "Downgrade" approach is preferred from our side, because it provides beside robustness the benefit of reducing handshaking time and sub flows are created simultaneously and not delayed by initial flow establishment -> The path providing the lowest latency determined the overall connection latency.
But there are still some minor drawbacks which needs to be solved. The solution of potential initial flows leads to the problem, that the SYN-Receiver cannot distinguish anymore between a valid Key A connection request or an invalid one, which is accidentally used by a foreign requester or deliberately by an attacker (e.g. brute force). MPTCP RobE tries to mitigate this challenge by reducing the time frame of accepting new SYN-Key A requests for a specific connection to the duration until the first initial flow is set up. But this is still not perfect and may be discussed in terms of security aspects. Also the question of how to handle Address IDs in the context of potential initial flows, needs to be discussed.

On the other hand the "Timer" approach can integrate with the existing standard best, but doesn't exploit the full potential of a possible MPTCP RobE standard/implementation and may be delay connection establishment for a long while. Whereas the "Break before Make" approach behaves like the first one but will not speed up the overall latency in the same way, but incorporates better with the MPTCP standard.

--- end rough description ---

--- start outlook ---

A first reference implementation was already done by us, based on MPTCP v0.90 and the "Downgrade" approach and is currently under lab investigation and optimization.

Btw., we know the presentation from NICT (https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-synduplication-00.pdf), but we see fundamental differences, because robustness wasn't addressed there. 

--- end outlook ---

I'm looking forward to your comments.

Kind regards
Markus Amend

DEUTSCHE TELEKOM AG
T-Labs (Research & Innovation)
Markus Amend

LIFE IS FOR SHARING.  

You can find the obligatory information on www.telekom.com/compulsory-statement

BIG CHANGES START SMALL - CONSERVE RESOURCES BY NOT PRINTING EVERY E-MAIL.