Internet DRAFT - draft-samar-mptcp-socketapi
draft-samar-mptcp-socketapi
MPTCP Working Group Samar Shailendra
Internet-Draft Hemant Kumar Rath
Intended status: Informational Arpan Pal
Expires: February 6, 2020 TCS R&I
Abhijit Mondal
IIT Kharagpur
August 5, 2019
Extended Socket APIs to control subflow priority in Multipath TCP
draft-samar-mptcp-socketapi-03.txt
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), 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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 01, 2019.
Copyright Notice
Copyright (c) 2019 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
to this document. Code Components extracted from this document must
Shailendra, et al. February 2, 2020 [Page 1]
Internet-Draft Extended Socket API August 5, 2019
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.
Abstract
This document provides the extended Socket APIs to control subflow
priority for Multipath TCP. It also describes an additional data
structure for MPTCP to make the subflow priority persistent across
subflow disconnection.
Table of Contents
1. Introduction...................................................2
2. Socket APIs for subflow Priority...............................3
2.1. Control Subflow Priority..................................4
2.2. Remembering Subflow Priority..............................4
3. Security Considerations........................................5
4. IANA Considerations............................................5
5. Conclusions....................................................5
6. References.....................................................6
6.1. Normative References......................................6
6.2. Informative References....................................6
7. Authors' Addresses.............................................7
1. Introduction
Multipath TCP (MPTCP) [RFC6824, RFC6182] has been designed as a
successor to TCP [RFC0793] with complete backward compatibility i.e.
it is able to use the same TCP socket APIs as well as communicate
with the non-MPTCP enabled hosts. MPTCP is included in the mainline
Linux Kernel [MPLINUX]. It has also been used in various devices such
as iPhone [I-PHONE] to improve the reliability by concurrently
connecting the WiFi and the cellular interfaces. Currently, MPTCP has
implemented four path managers to effectively use multiple paths
between the source and the destination.
o Default: This path manager does nothing more than accepting the
passive creation of subflows.
o Full Mesh: This creates a full-mesh of subflows between all
available source and destination interfaces. Usually the subflows
are created by the client.
o Ndiffports: This path manager creates multiple subflows between
every source and destination pair.
Shailendra, et al. February 2, 2020 [Page 2]
Internet-Draft Extended Socket API August 5, 2019
o Binder: This is a relatively newer path manager included in the
list. It is based on Loose Source Routing [BOC2013].
MPTCP is completely backward compatible with the TCP socket APIs.
However, these socket APIs do not exploit the complete potential of
MPTCP as these functionality are not available in TCP [RFC6824].
Hence, it is not possible to provide fine grained control over MPTCP
and in some ways it restricts the usability of MPTCP. Since, defining
new system call is a big ask for MPTCP and application developers are
more used to controlling the behavior of TCP using socket option APIs
(setSockOpt and getSockopt), it is quite effective to develop new
socket APIs for MPTCP as well to control its behavior.
In their draft [HESID17], Hesmans et al. have proposed MPTCP socket
APIs to interact with the underlying socket and control the subflow
behavior e.g. getting the list of existing subflows, creation of new
subflow, termination of subflows etc.. In this draft, we use their
draft [HESID17] as the foundation and provide the extended socket
APIs to allow the application to mark a particular subflow as an
active or a backup subflow. Such a control is very helpful for the
applications which intend to send multiple data streams with
different Quality of Service (QoS) [SHA2017] requirements to another
application or end host.
By default MPTCP creates every new subflow as an active subflow.
Hence, if a backup or low priority subflow gets disconnected and
connects again, it becomes active i.e. it does not remember its
previous state. In this document we also provide a new data structure
to remember the states of subflows. Hence, if a particular subflow
between any source destination pair is restored after disconnection,
it restores with the same state.
The rest of the document is organized as follows: it gives the
details of the socket APIs and the corresponding getSockOpt and
setSockopt details. We than provide the details of data structure to
remember the subflow priority and the corresponding socket APIs and
the socket options.
2. Socket APIs for subflow Priority
In this section we present the new socket APIs for the subflow
priority control. Currently, MPTCP provides two possible priorities
for each subflow; high priority or active subflow, and low priority
or backup subflow. These socket APIs can enable the client or the
server to dynamically set the subflow priority.
For all socket APIs, the underlying connections are assumed to
Multipath TCP connections, otherwise these APIs return an error and
Shailendra, et al. February 2, 2020 [Page 3]
Internet-Draft Extended Socket API August 5, 2019
set the errono as "EOPNOTSUPP".
2.1. Control Subflow Priority
This document addresses a typical requirement for an application to
change the priority of a subflow without restarting the entire
connection.
The first important step to set the subflow priority is to get the
list of available subflows. This can be performed using the
"MPTCP_GET_SUB_IDS" socket option defined by Hensman et al.[ HESID17,
HES2017].
The next step is to set the priority of a particular subflow. The
"MPTCP_SET_SUB_PRIO" socket option can be used to set the subflow
priority identified by its subflow id. This can be called by using
"setsockopt" with "MPTCP_SET_SUB_PRIO" as the socket option and
passing a pointer to "mptcp_sub_prio" structure. The "mptcp_sub_prio"
structure is defined as follows:
struct mptcp_sub_prio {
__u8 id;
__u16 low_prio;
};
Here, "id" is the subflow id as returned by the get subflow socket
API and "low_prio" is priority value to be defined for the subflow.
Note that a subflow is an active subflow if the low_prio flag is set
to "0". A typical illustration of this API to set the sublfow
priority as backup is as follows:
struct mptcp_sub_prio fp = {5, 1}; //subflow id 5 is set to backup.
setsockopt(sockfd, IPPROTO_TCP, MPTCP_SET_SUB_PRIO,&fp, sizeof(fp));
On successful return of the above socket API, MPTCP protocol sends
this information to remote host using MP_PRIO flag.
2.2. Remembering Subflow Priority
A new subflow in MPTCP is in active state and immediately starts
sending the data. If the subflow between a particular source and
destination is marked as backup using "MPTCP_SET_SUB_PRIO", it
becomes active if the subflow gets disconnected and connects again or
a new subflow is created. To handle this situation, two new lists
"ActiveInterfaceList" and "BackupInterfaceList" are included in MPTCP
to remember the state of the subflows between two end hosts. To
resolve any inconsistency between the two lists, the former has been
Shailendra, et al. February 2, 2020 [Page 4]
Internet-Draft Extended Socket API August 5, 2019
assigned a higher priority than the later.
To populate the active and backup lists, setsockopt with
"MPTCP_SUB_PATH_ACTIVE_LIST" and "MPTCP_SUB_PATH_BACKUP_LIST"
respectively can be used. This requires the application to pass the
pointer to "MPTCP_SUB_PATH" structure. The "MPTCP_SUB_PATH" is
defined as follows:
struct mptcp_sub_path {
sa_family_t sa_family;
union {
struct in_addr sin_addr;
struct in6_addr sin6_addr;
};
union {
struct in_addr din_addr;
struct in6_addr din6_addr;
};
};
These lists can be updated any time; however the runtime update will
not change the state of an existing subflow. Hence, this socket APIs
must be called before the subflows are created.
3. Security Considerations
There are no new security considerations for this document.
4. IANA Considerations
There are no IANA considerations in this document.
5. Conclusions
This document provides extended socket APIs for MPTCP to control the
subflow priorities. These are expected to be very useful for those
applications which want a fine grained control over the data to be
sent over the available subflows between the end hosts. These APIs
can increase the versatility of MPTCP subflows and also provide an
opportunity to the application developers to select the subflows more
intelligently. This is expected to be useful for different scenarios
and devices e.g. drones [SHA2017, RAO2017] where it is important to
segregate control data from user data on different subflow.
Shailendra, et al. February 2, 2020 [Page 5]
Internet-Draft Extended Socket API August 5, 2019
6. References
6.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC793,
DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
[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>.
[HESID17] B. Hesmans and O. Bonaventure, "A socket API to control
Multipath TCP", Internet Draft, July 2017,
https://tools.ietf.org/html/draft-hesmans-mptcp-socket-02.
[MPLINUX] "Multipath TCP implementation in the Linux kernel",
<http://www.multipath-tcp.org>.
6.2. Informative References
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC6182, DOI 10.17487/RFC6182, March 2011,
<http://www.rfc-editor.org/info/rfc6182>.
[I-PHONE] Apple Inc, "iOS - Multipath TCP Support in iOS7",
<https://support.apple.com/en-us/HT201373>.
[BOC2013] L. Boccassi, M. M. Fayed, and M. K. Marina, "Binder: A
System to Aggregate Multiple Internet Gateways in Community
Networks," in Proceedings of the 2013 ACM MobiCom Workshop
on Lowest Cost Denominator Networking for Universal Access.
ACM, 2013, pp. 3-8.
[SHA2017] S. Shailendra, K. Aniruddh, B. Panigrahi, and A. Simha,
"Multipath TCP Path Scheduler for Drones - A Segregation of
Control and User Data," in Proceedings of the 18th ACM
International Symposium on Mobile Ad Hoc Networking and
Computing. ACM, 2017.
[RAO2017] A. Rao, M. Visali, S. Shailendra, B. Panigrahi, and A.
Simha, "Reliable Robotic Communication using MPTCP," in 9th
International Conference on Communication Systems and
Networks, Jan 2017, pp. 429-430.
Shailendra, et al. February 2, 2020 [Page 6]
Internet-Draft Extended Socket API August 5, 2019
[HES2017] B. Hesmans and O. Bonaventure, "An enhanced socket API for
Multipath TCP," in Proceedings of the 2016 Applied
Networking Research Workshop. ACM, 2016, pp. 1-6.
7. Authors' Addresses
Samar Shailendra
TCS Research & Innovation
Bangalore, India
Email: s.samar@tcs.com
Hemant Kumar Rath
TCS Research & Innovation
Bhubaneswar, India
Email: Hemant.rath@tcs.com
Arpan Pal
TCS Research & Innovation
Kolkata, India
Email: arpan.pal@tcs.com
Abhijit Mondal
Indian Institute of Technology Kharagpur
Kharagpur, India
Email: abhimondal@iitkgp.ac.in
Shailendra, et al. February 2, 2020 [Page 7]
