MPTCP Working Group J.Zhu
Internet Draft J. Kang
Intended Category: Experimental F.Wang
Expires: August 22, 2019 T.Li
K.Zheng
Huawei
February 22, 2019
Initial-Path Selection for Connection Establishment in Multipath TCP
draft-kang-mptcp-initial-path-selection-00
Abstract
This draft presents an optimal mechanism for the selection of initial
path to address the problem caused by the sequential subflow
establishment defined in current MPTCP. We propose the general
architecture and procedures, along with the background analysis, use
cases and results of this proposal.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 2, 2019.
Copyright and License Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
J. Kang, et al Expires August 22, 2019 [Page 1]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Typical Flows . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Possibilities Analysis . . . . . . . . . . . . . . . . . . . . 7
6. Path decision information . . . . . . . . . . . . . . . . . . . 8
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. Compatibility Consideration . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Multipath TCP enables hosts to exchange packets belonging to a single
connection over several paths. Usually, these paths correspond to
different networks (such as cellular and WiFi) relying on the network
interfaces configured on a terminal. MPTCP initializes multiple
connections in sequence, that is, when one subflow is set up in the
manner of a three-way handshake, being as the initial subflow,
additional subsequent subflows can be created by a special four-way
handshake. These subflows are bound to MPTCP session. The data on the
sender can be selected for transmission on one of these subflows or
on all the subflows through the scheduler.
The path or network interface for the initial subflow is configured
by default for all connections in one system. For example, if LTE and
WiFi are offered in mobile phone, WiFi is the default path for the
initial subflow generally.
J. Kang, et al Expires August 22, 2019 [Page 2]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
Practically, this design falls short in some situations where the
default path goes through a highly lousy link. For example, if the
WLAN signal is weak or broken, the establishment of the subflow will
be delayed due to continuous tries of the master flow. This, in turn,
will be translated into longer startup delay for the initial
conversations of the applications above.
A similar problem was addressed by [Kien][Markus], via robust and
simultaneous connection establishment. However, they either require
the problem changes or introduce additional burden on the server
side. To avoid such problem, we propose a new solution by introducing
a function called "Initial-path Selection" during MPTCP connection
establishment, i.e., selecting the initial path based on measurement
of available paths.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. Architecture
Figure 1 provides the architecture for "Initial-path Selection". It
can be integrated in MPTCP stack or as an isolated module in the
terminal. It obtains transmission status information for each
available path when it receives a request from an application. Then
it makes decision on initial path to MPTCP stack to establish
connection with remote host.
J. Kang, et al Expires August 22, 2019 [Page 3]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
+--------------------+ +--------------------+
| Terminal | | Server |
| +--------------+ | | +--------------+ |
| |Application n | | | |Application n | |
| +--------------+ | | +--------------+ |
| | | | | |
| | | | | |
| +--------------+ | | | |
| | Initial-path +--+-----------+ | | |
| | Selection | | | | | |
| +--------------+ | +------+-----+ | | |
| | |----| |-----| | |
| | | | Internet | | | |
| +--------------+ |----| |-----| +--------------+ |
| | MPTCP stack | | +------------+ | | MPTCP stack | |
| +--------------+ | | +--------------+ |
+--------------------+ +--------------------+
Figure 1: Architecture for "Initial-path Selection"
4. Typical Flows
Two typical flows are listed here. Figure 2 shows that "Initial-path
Selection" will be executed for each MPTCP connection establishment.
Figure 3 describes that "Initial-path Selection" can be used from the
time that an application requests to set up a second MPTCP connection
after the first one is completed. Considering that no heuristics is
used for decision for the first MPTCP connection, default initial
path can be adopted. This is just one of possible specific scenarios
for this method.
J. Kang, et al Expires August 22, 2019 [Page 4]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
+----------------+
| Application |
| Request |
+----------------+
|
V
+----------------+
| Initial-path |
+--->| Selection |<--+
| +----------------+ |
| | |
| V |
| +----------------+ |
| | Set initial | |
| | path | |
| | for MPTCP | |
| +----------------+ |Info
| | |
| V |
| +----------------+ |
| | Establish MPTCP|---+
| | connection |
| +----------------+
| |
| V
|No +----------------+
+----+ Successfully? |
+----------------+
|Yes
V
Figure 2: "Initial-path Selection" for each connection establishment
J. Kang, et al Expires August 22, 2019 [Page 5]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
+---------------+
| Application |
| Request |
+---------------+
|
V
+---------------+ Yes
| First +-------------+
| Connection? | |
+---------------+ |
|No |
V V
+---------------+ +-------------+
| Initial- | | Default |
+------>| |<--+ | initial |
| |path Selection | | | path |
| +---------------+ | +------+------+
| | | |
| V | |
| +---------------+ | |
| | Set initial | |Info |
| |path for MPTCP | | |
| +---------------+ | |
| | | |
| V | |
| +---------------+ | |
| |Establish MPTCP|---+ |
| | connection | |
| +---------------+ |
| | |
| V |
| No +---------------+ |
+-------+ Successfully? |<------------+
+-------+-------+
|Yes
V
Figure 3: Default initial path for the first connection,
"Initial-path Selection" for subsequent connection establishment
Figure 4 shows the abstract implementation process for "Initial-path
Selection". Upon a request from an application, "Initial-path
Selection" module will acquire transmission status information which
represents the transmission performance of each available path or
network interface and evaluate it. The transmission status
information is characterized by at least one of the parameters:
J. Kang, et al Expires August 22, 2019 [Page 6]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
signal strength, throughput, round-trip time (RTT) and link success
rate. In this way, we can determine a path with better transmission
performance and use the network interface to it for connection
establishment.
|
V
+-----------------------+
| Acquire transmission |
| status info for |
| available paths |
+-----------------------+
|
V
+-----------------------+
| Evaluating the status |
| for available paths |
+-----------------------+
|
V
+-----------------------+
| Determining an |
| available path with |
| better transmission |
| performance |
+-----------------------+
|
V
+-----------------------+
| Using the network |
| interface |
| corresponding to the |
| path with better |
| transmission |
| performance for |
| connection |
| establishment |
+-----------------------+
|
V
Figure 4: Implementation process for "Initial-path Selection"
5. Possibilities Analysis
J. Kang, et al Expires August 22, 2019 [Page 7]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
Figure 5 describes the relationship of application, MPTCP connection
and network interface at a running time. It shows that:
o Multiple applications are running on the terminal at the same
time.
o Each application can start and maintain more than one MPTCP
connection.
o Applications share network interfaces, e.g. WiFi, LTE and 5G.
So before starting a new MPTCP session, a number of heuristics can be
integrated to estimate the performance of these existing connections.
The estimation results are used to select the best one from available
paths which are bound to different network interfaces.
+----------------------------------------------------------------+
| +----------------+ +-----------------+ +-----------------+ |
| | Application 1 | | Application 2 | | Application N | |
| +-------+--------+ +--------+--------+ +--------+--------+ |
| | | | |
| | | +--------+--------+ |
| +----+---+ +--------+-------+ | New Session | |
| | | | | | +--------+--------+ |
| | | | | | | |
| | | | | | V |
|+---+--------+---------+--------+-------+-----------------------+
||+--+---+ +--+---+ +---+--+ +---+--+ +--+---+ |
|||MPTCP | |MPTCP | |MPTCP | |MPTCP | |MPTCP | |
|||Conn 1| |Conn 2| |Conn 1| |Conn 2| |Conn 3| |
||+------+ +------+ +------+ +------+ +------+ |
|+----------------------+----------------+-----------------------+
| | | |
| +----+----+ +----+----+ |
+------------------+ WiFi +------+ LTE +------------------+
+---------+ +---------+
Figure 5: Relationship of application, MPTCP connection and network
interface
6. Path decision information
Such heuristics can be mainly divided into three levels: application
level, transport-layer level and network-interface level based on the
information acquisition method. For example, RTT is calculated for
J. Kang, et al Expires August 22, 2019 [Page 8]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
each subflow in one MPTCP connection, so it is one of transport-layer
level. The transmission status information for each available path
SHOULD be characterized by at least one of the parameters: signal
strength, throughput, RTT and link success rate. Information in
application level is used for statistics.
o Application level: application name, domain name, port number and
location.
o Transport-layer level: RTT for each subflow within one MPTCP
connection in running applications.
Figure 6 shows a flowchart for "Initial-path Selection" based on RTT.
Normally, path RTT can be determined by a time difference between
sending a package and an ACK. For the asymmetric downloading service,
shown in figure 7, the latest RTT for these subflows is calculated by
data sender, i.e. application server (RTT = Timestamp 2 - Timestamp
1) and transformed through some option in TCP Header to data
receiver. Besides "latest RTT", algorithm for estimating the mean RTT
by more than one RTT sent from data sender is also proposed.
+--------------------+
| New Session |
+--------------------+
|
V
+--------------------+ No
| Running connections+-------------+
| (LTE.RTT<WiFi.RTT) | |
+--------------------+ |
| Yes |
V V
+--------------------+ +--------------------+
| Set LTE as | | Set WiFi as |
| initial path | | initial path |
+--------------------+ +--------------------+
Figure 6: "Initial-path Selection" based on RTT
J. Kang, et al Expires August 22, 2019 [Page 9]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
+-------------------+ +-------------------+
|+-----------------+| |+-----------------+|
|| APP Client || || APP Server ||
|+-----------------+| |+-----------------+|
|+-----------------+| |+-----------------+|
|| MPTCP Stack || || MPTCP Stack ||
|+-----------------+| |+-----------------+|
+---------+---------+ +----------+--------+
| |
| Establish a transport layer connection|
|<------------------------------------->|
| |
| Data Transmission |
|<--------------------------------------|Timestamp 1
| |
| ACK |
|-------------------------------------->|Timestamp 2
| |
| +-------+-------+
| |Calculating RTT|
| +-------+-------+
| |
| Data transmission + RTT |
|<--------------------------------------|
| ACK |
|-------------------------------------->|
| |
Figure 7: RTT calculated by APP Server in asymmetric HTTP downloading
o Network-interface level: signal strength, throughput and link
success rate.
Some parameters can be detected by the terminal, such as signal
strength, throughput and RTT.
7. Examples
Examples of actual implementation are as follows and default initial
path is set to WiFi:
o If WiFi.signal < LTE.signal, then set initial path = LTE.
o If Running connections (LTE.latestRTT < WiFi.latestRTT), then set
initial path = LTE.
J. Kang, et al Expires August 22, 2019 [Page 10]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
o If WiFi.Throughput < LTE.Throughput, then set initial path = LTE.
Others are still in research:
o Calculating success rate by Probability Theory. For example, a
geographical solution can be: if Location A (WiFi.SuccessRate <
LTE.SucessRate), then set initial path = LTE.
8. Use Cases
This new proposal is effective for following actual service
scenarios:
Scenario 1:
For some HTTP download service, the application downloads or plays
videos through multiple short streams (<20MB per stream and 5MB for
some short videos), see in Figure 8. The process of establishing a
MPTCP connection frequently occurs during the use of the application.
This proposal can reduce video start delay significantly in the
scenario of "frequent connection establishment".
+------------------------------------------------------------+
|+----------------------------------------------------------+|
|| Application ||
|+-------+-------------+--------------+------------+--------+|
| | | | | |
| | | | +------+-------+ |
| | | | | New Session | |
| | | | +------+-------+ |
| | | | | |
| | | | V |
|+-------+-------------+--------------+---------------------+|
|| +-----+-----+ +-----+-----+ +------+----+ ||
|| | MPTCP | | MPTCP | | MPTCP | ||
|| |Connection1| |Connection2| |Connection3| ||
|| +-----------+ +-----------+ +-----------+ ||
|+-------------------+----------------+---------------------+|
| | | |
| +------+-----+ +------+------+ |
+-------------+ WiFi +---+ LTE +---------------+
+------------+ +-------------+
Figure 8: Scenario of "frequent connection establishment"
Scenario 2:
J. Kang, et al Expires August 22, 2019 [Page 11]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
Multiple applications start and are running on a terminal at the same
time, see in Figure 9. Each application has the requirement to
establish an MPTCP connection. Therefore, there is an opportunity on
the terminal to use both WiFi and the LTE. This proposal can help
load balancing between them.
+-------------------------------------------------------------+
|+--------------------------+ +-------------+ +--------------+|
|| Application 1 | |Application 2| | Application 3||
|+------+-------------+-----+ +-----+-------+ +------+-------+|
| | | | | |
| | | | +------+-------+|
| | | | | New Session ||
| | | | +------+-------+|
| | | | | |
| | | | V |
|+------+-------------+-------------+------------------------+|
||+-----+-----+ +-----+-----+ +-----+-----+ ||
||| MPTCP | | MPTCP | | MPTCP | ||
|||Connection1| |Connection2| |Connection1| ||
||+-----------+ +-----------+ +-----------+ ||
|+-------------------+----------------+----------------------+|
| | | |
| +------+-----+ +------+------+ |
+-------------+ WiFi +---+ LTE +----------------+
+------------+ +-------------+
Figure 9: Network interface shared by multiple applications
9. Result
For signal strength, in the case where the signal strength of default
path (i.e. WiFi) is weak, and the LTE signal is strong, two
conclusions can be drawn from testing:
1. The proposed mechanism selects LTE as the initial path, instead of
the default path over WiFi.
2. The proposed mechanism can achieve the same effect on start-up
delay as the case of turning on LTE only.
10. Compatibility Consideration
This solution makes no changes to the existing flows in MPTCP base
protocol because all its process is before connection establishment.
But for asymmetric HTTP downloading, only data sender can provide the
J. Kang, et al Expires August 22, 2019 [Page 12]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
accurate RTT data for reference, so it will result in the
modification in protocol parameter structure to carry it to data
receiver as above analysis.
11. Security Considerations
"Initial-path Selection" module is located at the terminal. The
design is to improve the robustness and reliability of connection
establishment, so there are no security issues.
12. IANA Considerations
Considering the asymmetric downloading service, a new kind of option
in TCP Header SHOULD be introduced for carrying RTT from data sender
to date receiver.
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and
J.Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<https://www.rfc-editor.org/info/rfc6182>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP
Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
13.2. Informative References
[Kien] Kien Nguyen, Kentaro Ishizu, Mirza Golam Kibria, and
Fumihide Kojima, "A proposal for improving MPTCP
initialization". 14 November 2016, Seoul, Korea,
<https://www.ietf.org/proceedings/97/slides/slides-97-
mptcp-a-proposal-for-improving-mptcp-initialization-00.pdf>
[Markus] Markus Amend, Eckard Bogenfeld, and Andreas Matz, "A
proposal for MPTCP Robust session Establishment (MPTCP
RobE)", 18 July 2017,
<https://datatracker.ietf.org/meeting/99/materials/slides-
99-mptcp-a-proposal-for-mptcp-robust-session-establishment-
mptcp-robe-01.pdf>
J. Kang, et al Expires August 22, 2019 [Page 13]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
[RobE] Markus Amend, Veselin Rakocevic, Andreas Philipp Matz, and
Eckard Bogenfeld, "RobE: Robust Connection Establishment
for Multipath TCP", ANRW '18, July 16, 2018.
J. Kang, et al Expires August 22, 2019 [Page 14]
INTERNET-DRAFT Initial-Path Selection February 22, 2019
Author's Addresses
Jianjian Zhu
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: zhujianjian1@huawei.com
Jiao Kang
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
EMail: kangjiao@huawei.com
Fanzhao Wang
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
Email: wangfanzhao@huawei.com
Tong Li
Huawei Technologies
Bantian, Longgang District
Shenzhen 518129
P.R. China
EMail: li.tong@huawei.com
Kai Zheng
Huawei Technologies
Information Road, Haidian District,
Beijing 100085
P.R. China
EMail: kai.zheng@huawei.com
J. Kang, et al Expires August 22, 2019 [Page 15]