Internet DRAFT - draft-kien-mptcp-init
draft-kien-mptcp-init
Multipath TCP K. Nguyen
Internet-Draft K. Ishizu
Intended status: Standards Track M. Kibria
Expires: May 3, 2017 F. Kojima
National Institute of Information and Communications Technology
October 30, 2016
An Improvement of MPTCP Initialization
draft-kien-mptcp-init-00
Abstract
This draft describes a new method of connection initialization for
Multipath TCP (MPTCP). In the current implementation, the MPTCP's
first subflow needs to be successfully initialized before an
additional flow takes its turn. This yields to a degradation of
MPTCP benefit in many use cases (e.g., transferring short flows). To
overcome the problem, we propose to duplicate the first SYN packet
and send the duplicating ones via multiple interfaces.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 3, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Nguyen, et al. Expires May 3, 2017 [Page 1]
Internet-Draft An Improvement of MPTCP Initialization October 2016
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. Problem Description . . . . . . . . . . . . . . . . . . . . . 3
3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
1. Introduction
MPTCP is an evolvable and efficient tool for link aggregation, e.g.,
on multi-homing hosts in mobile wireless networks. The flexibility
of adding and deleting subflows introduce MPTCP benefits in
aggregation and soft handover in many use cases. In the current
implementation, MPTCP shows several drawbacks including operations in
a scenario with imbalanced paths, especially handling short flows.
Since a large amount of Internet TCP traffic is short flows, MPTCP
should be improved to be more suitable with the traffic pattern. In
the such scenario, the problem of selection of initialization path
has big impacts on the MPTCP performance. It has been proven by the
theoretical analysis [analysis] and real measurements [measurement].
However, there are limited works on solving the problem.
In fact, MPTCP can not choose the initial path itself. MPTCP relies
on routing information to determine the destination for the
initialization. The routing is static in most cases. The host is
normally configured to route all the traffic through a default
gateway. As a result, the first SYN of initialization has to be sent
to the gateway associated network regardless of its quality. On the
other hand, the routing information is available on a host for
supporting beneficial operations of MPTCP. To solve the mentioned
problem, we propose to duplicate the first SYN packet. The available
routing information is leveraged in sending the duplications through
several networks. The first received SYN/ACK is determined the best
network (i.e., the one with the smallest RTT) to initialize the MPTCP
connection.
Nguyen, et al. Expires May 3, 2017 [Page 2]
Internet-Draft An Improvement of MPTCP Initialization October 2016
2. Problem Description
This section describes the limitation of the current implementation
of MPTCP. Consider an example scenario of MPTCP communication
between two host (host A and host B). MPTCP on host A with multiple
addresses (i.e., two addresses A1, A2) communicates with host B via
network A1, A2, respectively. In this scenario, the gateway
associated with address A1 is the default. Obviously, Host A send
the first SYN with MP_CAPABLE to Address B1 for MPTCP initialization.
After the successful initialization, the additional subflow will be
added to ongoing MPTCP transmissions following one of two methods.
The later subflow is initialized a new SYNC+MP_JOIN from A2 to B1 if
there is no NAT between them. In case of under NAT, the SYN+MP_JOIN
will be added after sending MP_ADDADDR.
For long flows, the standard mechanism works well, even the quality
of services provided by the network A1 and network A2 are different.
However, if the network A1 has longer Round Trip Time (RTT) than the
one of network A2. The MPTCP performance is degraded, especially in
the case of short flows. Besides, the similar scenario will become
popular since the different network technologies are emerging
especially for the next generation of mobile networks. Therefore, it
is necessary and important to solve the problem.
3. Proposal
Our proposal for solving the previous problem relies on the idea of
packet duplication, specifically SYN duplication. The first SYN in
initialization is duplicated. The newly created SYN packets are then
sent through the multiple gateways. The proposal only requires a
modifications in sending/receiving procedures of MPTCP.
We describe an beneficial use case of the proposal, which is similar
to the scenario mentioned in Section 3. Note that, the network A2
has shorter RTT than the one of network A1. Initially, the key is
generated on host A for the first SYN. The first SYN is constructed
just like as in the standard. The SYN is also included MP_CAPABLE
option. Additionally, the second SYN is newly constructed with the
same content. The only difference is on the layer 3 source
addresses. More specifically, the source-destination pair is (A1,
B1) on the first, and (A2, B1) on the second SYN, respectively.
Concurrently, the two SYNs are departed from host A to host B. This
task is feasible when the routing information is available for the
departures.
At the host B, the early arriving SYN (i.e., the one from A2 to B1)
is received. The host B then sends an acknowledgment (SYN/ACK with
MP_CAPABLE) to A2. We can observe that without modification of the
Nguyen, et al. Expires May 3, 2017 [Page 3]
Internet-Draft An Improvement of MPTCP Initialization October 2016
default gateway information, MPTCP has a good path selection via
Network A2 for initialization. Further consideration is that, the
later acknowledgment (SYN/ACK to B1) is used for an additional
subflow (i.e., similar to MP_JOIN). Following the further operation,
the whole period of MPTCP initialization is shortened comparing to
the one in current implementation. Another obvious benefit of SYN
duplications is enhancing the resilience of SYN transmission.
4. Acknowledgements
This research was conducted under a contract of Research and
Development for radio resource enhancement, organized by the Ministry
of Internal Affairs and Communications, Japan.
5. Security Considerations
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References
[analysis]
Chen, Y. and D. Towsley, "On bufferbloat and delay
analysis of multipath TCP in wireless networks", IEEE/IFIP
Networking, Trondheim, Norway p1-9, 2014.
[measurement]
Chen, Y., Lim, Y., Gibbens, R., Nahum, E., and D. Towsley,
"A measurement-based study of MultiPath TCP performance
over wireless network", IEEE Internet measurement
conference p110-117, 2013.
Authors' Addresses
Kien Nguyen
National Institute of Information and Communications Technology
YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
Kanagawa 239-0847
Japan
Email: kienng@nict.go.jp
Nguyen, et al. Expires May 3, 2017 [Page 4]
Internet-Draft An Improvement of MPTCP Initialization October 2016
Kentaro Ishizu
National Institute of Information and Communications Technology
YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
Kanagawa 239-0847
Japan
Email: ishidu@nict.go.jp
Mirza Golam Kibria
National Institute of Information and Communications Technology
YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
Kanagawa 239-0847
Japan
Email: mirza.kibria@nict.go.jp
Fumihide Kojima
National Institute of Information and Communications Technology
YRP Center No.1 Building 7F, 3-4 Hikarinooka, Yokosuka
Kanagawa 239-0847
Japan
Email: f-kojima@nict.go.jp
Nguyen, et al. Expires May 3, 2017 [Page 5]
