Internet DRAFT - draft-qian-mptcp-predict
draft-qian-mptcp-predict
Internet Engineering Task Force Q.W. Wu
Internet-Draft H.L. Li
Intended status: Informational Q.Z. Zhang
Expires: 17 March 2022 J.L. Liu
Tsinghua University
13 September 2021
Predictable Multipath TCP (MPTCP) extension
draft-qian-mptcp-predict-01
Abstract
Multipath TCP (MPTCP) adds the capability of using multiple paths to
a regular TCP session, which is quite suitable for integrated network
scenarios where multiple paths almost always exist. However, link
handover and link on-off switching happen frequently in network
systems that integrate different systems (especially the systems that
continually move), which defeats the quality of MPTCP connections.
Information about the link handover and on-off switching in above-
mentioned scenarios can be predicted in advance, but MPTCP is not
capable of utilizing the prediction information. This document
suggests MPTCP be extended with the capacity of obtaining and
utilizing the prediction information. Furthermore, the document
describes one possible way to enhance MPTCP with prediction
information, which proposes a modified MPTCP scheduler utilizing link
on-off prediction information.
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 https://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 17 March 2022.
Wu, et al. Expires 17 March 2022 [Page 1]
Internet-Draft Predictable MPTCP extension September 2021
Copyright Notice
Copyright (c) 2021 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 (https://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. Problem: How do handover and on-off switching weaken
MPTCP? . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. How Link Handover weakens MPTCP . . . . . . . . . . . . . 4
3.2. How Link On-off switching weakens MPTCP . . . . . . . . . 4
4. Prediction Information . . . . . . . . . . . . . . . . . . . 5
4.1. Predictability . . . . . . . . . . . . . . . . . . . . . 5
4.2. Predictable Information . . . . . . . . . . . . . . . . . 5
5. An example: Scheduler Utilizing Prediction Information . . . 5
5.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Modification to Scheduler: How to utilize Prediction
Information . . . . . . . . . . . . . . . . . . . . . . . 5
5.3. Enhancement . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Corresponding extension for path management . . . . . . . 6
5.5. Supplemental suggestions for scenario deployment . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Multipath TCP (MPTCP) adds the capability of using multiple paths to
a regular TCP session [RFC793]. The motivations for this extension
include increasing throughput, overall resource utilization, and
resilience to network failure, and these motivations are discussed,
along with high-level design decisions, as part of the multipath TCP
architecture [RFC6182].
Wu, et al. Expires 17 March 2022 [Page 2]
Internet-Draft Predictable MPTCP extension September 2021
In integrated networks that integrate different systems (especially
the systems that continually move), like Integrated Satellite-
Territorial Network (ISTN) and aviation aircrafts network that
simultaneously using satellite communications and ATG (Air to Ground)
Broadband, multiple paths between different hosts almost always exist
and therefore it is quite suitable to apply MPTCP in such scenarios
to increase throughput and resilience to network failure. However,
link handover and link on-off switching happen frequently in those
scenarios and they severely decrease the quality of MPTCP
transmission connections.
On the other hand, some information about the link handover and on-
off switching in above-mentioned scenarios can be predicted in
advance according to prior knowledge including satellite orbit,
preset route of airlines, the fixed position of the ATG ground
stations and so on. But MPTCP is not capable of obtaining or
utilizing the prediction information, which leads to a contradiction
between the existence of prediction information and the disability of
utilizing the information in MPTCP.
The main idea of this document is to suggest that MPTCP be extended
with the capacity of obtaining and utilizing the prediction
information. This document first describes how link handover and on-
off switching weaken MPTCP and how some information about the link
changes can be predicted. Finally, this document shows an example of
utilizing prediction information in MPTCP.
The target readers of this document are protocol designers and
network researchers who work on MPTCP.
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 [RFC2119].
This document uses the MPTCP terminology introduced in
[I-D.ietf-mptcp-rfc6824bis] [RFC6824].
RTT: Round-Trip Time;
ISTN: Integrated Satellite-Territorial Network;
QoS: Quality of Service;
LEO: Low Earth Orbit;
GEO: Geostationary Orbit;
Wu, et al. Expires 17 March 2022 [Page 3]
Internet-Draft Predictable MPTCP extension September 2021
ATG: Air To Ground.
3. Problem: How do handover and on-off switching weaken MPTCP?
In integrated networks, multiple and heterogeneous paths almost
always exist between different hosts. However, link handover and on-
off switching happen frequently in these networks. This part
describes how link handover and on-off switching weaken MPTCP
performance.
3.1. How Link Handover weakens MPTCP
QoS including bandwidth, RTT of paths exist in different network
systems are quite different from each other. In integrated networks,
link handover between different systems often happen. For example,
when the satellite link of an aircraft handovers from a LEO satellite
to a GEO satellite, the end-to-end delay will increase from tens of
milliseconds (ms) to more than 500 ms. If the size of congestion
window doesn't increase with the end-to-end delay, it will limit and
decrease the transmission rate of the sender. What's more, the large
delay results in a slow congestion window increase, which means the
sender will stay at low transmission rate for a long period. On the
other hand, MPTCP scheduler usually schedules packets to different
paths based on the paths' RTT, therefore the end-to-end delay changes
will also result in more out-of-order packets at the receiver.
3.2. How Link On-off switching weakens MPTCP
On-off switching of links also happen in integrated networks. For
example, when an aviation aircraft connects to Internet with
satellite communications and ATG (Air to Ground) Broadband link
simultaneously, the ATG link may switch between on and off states as
the aircraft flies, due to the discontinuity of ATG Broadband
resulted from complicated topography (like mountains and lakes). As
a transport layer protocol, the only way that MPTCP detects
disconnection and reconnection of links is to analyze the packets
that the receiver replied based on timers. Therefore, it usually
takes MPTCP a long time to detects link disconnection and
reconnection. When a link suddenly disconnects, the unsent data
scheduled to that link will not be transmitted in time and it will
take MPTCP scheduler a long time to find the link off and retransmit
the data, which results in out-of-order packets at the receiver.
What's more, if the sender can't receive ACKs for quite a long time,
the send window of all the sub-flows will get exhausted. When a link
reconnects, it will also take MPTCP a period to find the link on and
schedule some data to the link.
Wu, et al. Expires 17 March 2022 [Page 4]
Internet-Draft Predictable MPTCP extension September 2021
4. Prediction Information
4.1. Predictability
In emerging integrated networks, some new nodes including LEO
satellites, GEO satellites, aviation aircrafts, ground base stations,
ships on the ocean and high-speed railways are involved. They are
different: some of them, like ground base stations, are at fixed
positions on the earth while others keep moving at expectable speed
on their pre-defined orbits or routines on earth, on ocean or in the
space. These characteristics mean that the relative positions
between them are predictable and furthermore, the state of the
network links between them are predictable.
4.2. Predictable Information
For link handover, predictable information include the time handover
happens, link bandwidth and end-to-end delay changes after handover
and so on. For on-off switching, predictable information include the
time link disconnection and reconnection happens, link bandwidth and
end-to-end delay when link reconnects and so on.
5. An example: Scheduler Utilizing Prediction Information
This part shows an example of utilizing prediction information to
enhance MPTCP under a link on-off switching scenario.
5.1. Scenario
It's suitable for Aviation aircrafts to connect to Internet with
MPTCP, where ATG Broadband and Satellite Communications are
simultaneously available. However, the complicated topography (like
mountains and lakes) leads to the discontinuity of ATG Broadband, and
therefore defeats the quality of aircraft network service (Refer to
Section 3.2). On the other hand, the on-off connection state of the
ATG Broadband access link of the aircrafts can be predicted from the
preset route of airlines and the position of the ATG ground stations
in advance of the conversion of link connection states.
5.2. Modification to Scheduler: How to utilize Prediction Information
The default scheduling principle of MPTCP scheduler is "min-RTT"
principle, which schedules each packet to the path with minimum RTT
within the paths whose send window is not full. The modified version
is called "MPTCP-P", which introduces prediction information to
calculate a modified round trip time called "RTT-P" and the
calculating details are as follows:
Wu, et al. Expires 17 March 2022 [Page 5]
Internet-Draft Predictable MPTCP extension September 2021
The prediction information that MPTCP-P requests include a) the time
when the next disconnection of the ATG link happens, b) the time when
the next reconnection of the ATG link happens, which are respectively
denoted as time_down and time_up. The current time is denoted as
time_now. The RTT calculated by default method of TCP is denoted as
RTT_Orignal.
When the ATG link of the aircraft is connected (i.e. time_now <
time_down):
RTT-P = RTT_Orignal;
When the ATG link of the aircraft is disconnected (i.e. time_down <
time_now < time_up):
RTT-P = RTT_Orignal + time_up - time_now;
MPTCP-P schedules packets in "min-RTT-P" principle, which schedules
each packet to the path with minimum RTT-P within the paths whose
send window is not full.
5.3. Enhancement
Without prediction information about link on-off switching, original
MPTCP detects link connection state based on received packets and
timers. Therefore, it takes time for MPTCP to find link disconnected
or reconnected and then accordingly schedule packets to different
paths.
With prediction information about link on-off switching, MPTCP-P
could a) reduce the packets to be allocated to a path and cancel
timers for the packets sent through a path when the predictable link
of the path is going to disconnect, b) allocate packets to a
reconnecting path at the moment it gets reconnected according to the
prediction information.
5.4. Corresponding extension for path management
In order to keep the temporarily disconnected subflow valid in case
it is in a quite long disconnected period, it might be necessary to
a) setting it into backup state [I-D.ietf-mptcp-rfc6824bis] [RFC6824]
or b) inform the other end the link on-off state through newly
extended MPTCP option. What's more, some extension to TCP might be
needed to keep the corresponding paths valid.
Wu, et al. Expires 17 March 2022 [Page 6]
Internet-Draft Predictable MPTCP extension September 2021
5.5. Supplemental suggestions for scenario deployment
As it's hardly feasible for a user's device(e.g. smartphone, laptop,
etc.) to directly connect to satellites or ATG network, a better
choice is to connect to the Internet with Satellite Communication and
ATG simultaneously with the air-borne antennas and run MPTCP at
aircraft-level. We also suggest adopting PEP(TCP-split
proxy)[RFC3135] at the aircraft-level, so that a user's device can
directly connect to the aircraft (e.g. through on-board Wi-Fi) and
then enjoy Internet services through the proxy. Another two
considerations for adopting PEP are : a) it's a common way to adopt
TCP-split proxy at the transition point between satellite and non-
satellite links to improve TCP performance, especially for GEO
satellite communication, b) a common user could connect to the
aircraft with his/her unmodified device, which does not necessarily
support MPTCP(which is largely true) and enjoy the benefits of MPTCP
(and MPTCP-P suggested in this draft) through the proxy.
6. Acknowledgements
7. IANA Considerations
This memo includes no request to IANA.
8. Security Considerations
9. Informative References
[I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", June 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-
rfc6824bis-18>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001,
<https://www.rfc-editor.org/info/rfc3135>.
Wu, et al. Expires 17 March 2022 [Page 7]
Internet-Draft Predictable MPTCP extension September 2021
[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,
<https://www.rfc-editor.org/info/rfc6824>.
[RFC793] Information Sciences Institute,University of Southern
California, "Transmission Control Protocol", September
1981, <https://datatracker.ietf.org/doc/rfc793/>.
Authors' Addresses
Qian Wu
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing
100084
China
Email: wuqian@cernet.edu.cn
Hewu Li
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing
100084
China
Email: lihewu@cernet.edu.cn
Qi Zhang
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing
100084
China
Email: qi-zhang19@mails.tsinghua.edu.cn
Wu, et al. Expires 17 March 2022 [Page 8]
Internet-Draft Predictable MPTCP extension September 2021
Jun Liu
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing
100084
China
Email: juneliu@tsinghua.edu.cn
Wu, et al. Expires 17 March 2022 [Page 9]
