Jump to content

Multipath TCP: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous edit
Content deleted Content added
VisualWikitext
m Added non-breaking space to non-template file size, bitrate, and bandwidth values (via WP:JWB)
 
(36 intermediate revisions by 23 users not shown)
Line 1: Line 1:
{{Short description|Transmission Control Protocol technology}}
{{Update|date=January 2020}}
{{Infobox networking protocol
| title = Multipath TCP (MPTCP)
| logo = [[File:MPTCP logo.svg]]
| logo alt = MPTCP logo
| is stack = no
| purpose = General Purpose
| developer = [[Internet Engineering Task Force|IETF]]
| date = {{Start date and age|2009}}
| based on = [[Internet Protocol|IP]], normally layered with [[Transmission Control Protocol|TCP]]
| influenced =
| osilayer = [[Transport layer]]
| rfcs = {{IETF RFC|8684}}
}}
{{IPstack}}
{{IPstack}}
'''Multipath TCP''' ('''MPTCP''') is an ongoing effort of the [[Internet Engineering Task Force]]'s (IETF) Multipath TCP working group, that aims at allowing a [[Transmission Control Protocol]] (TCP) connection to use multiple paths to maximize resource usage and increase redundancy.<ref>[http://datatracker.ietf.org/wg/mptcp/ Multipath TCP working group]</ref>
'''Multipath TCP''' ('''MPTCP''') is an ongoing effort of the [[Internet Engineering Task Force]]'s (IETF) Multipath TCP working group, that aims at allowing a [[Transmission Control Protocol]] (TCP) connection to use multiple paths to maximize [[Network throughput|throughput]] and increase redundancy.<ref>[http://datatracker.ietf.org/wg/mptcp/ Multipath TCP working group]</ref>


In January 2013, the IETF published the Multipath specification as an Experimental standard in RFC 6824. Currently, the IETF works on an update to version 1 of the MPTCP protocol which will obsolete RFC 6824 if approved in 2019.[https://tools.ietf.org/html/draft-ietf-mptcp-rfc6824bis-12]
In January 2013, the IETF published the Multipath specification as an Experimental standard in {{IETF RFC|6824}}. It was replaced in March 2020 by the Multipath TCP v1 specification in {{IETF RFC|8684|link=no}}.


==Benefits==
==Benefits==
The redundancy offered by Multipath TCP enables [[inverse multiplexing]] of resources, and thus increases TCP throughput to the sum of all available [[link layer|link-level]] channels instead of using a single one as required by plain TCP. Multipath TCP is backward compatible with plain TCP.
The redundancy offered by Multipath TCP enables [[inverse multiplexing]] of resources, and thus increases TCP throughput to the sum of all available [[link layer|link-level]] channels instead of using a single one as required by standard TCP. Multipath TCP is backward compatible with standard TCP.


Multipath TCP is particularly useful in the context of wireless networks<ref name="PaaschDetal2012">{{cite conference|last1=Paasch|first1=Christoph|conference=ACM SIGCOMM workshop on Cellular Networks (Cellnet'12)|last2=Detal|first2=Gregory|last3=Duchene|first3=Fabien|last4=Raiciu|first4=Costin|last5=Bonaventure|first5=Olivier|year=2012|pages=31|doi=10.1145/2342468.2342476|url=http://inl.info.ucl.ac.be/publications/exploring-mobilewifi-handover-multipath-tcp|title=Exploring mobile/WiFi handover with multipath TCP|isbn=9781450314756}}</ref>; using both [[Wi-Fi]] and a [[mobile network]] is a typical [[use case]].<ref name="shivaetal2017">{{cite journal|title=Analytical Modeling of Multipath TCP Over Last-Mile Wireless |journal=IEEE/ACM Transactions on Networking |volume=25 |issue=3 |pages=1876–1891 |author1=S. Pokhrel |author2=M. Panda |author3=H. Vu |date=2017-02-24|doi=10.1109/TNET.2017.2663524 }}</ref> In addition to the gains in throughput from inverse multiplexing, links may be added or dropped as the user moves in or out of coverage without disrupting the end-to-end TCP connection.<ref name=" pokhrel2018improving ">{{cite journal|title= Improving Multipath TCP Performance over WiFi and Cellular Networks: an Analytical Approach |journal= IEEE Transactions on Mobile Computing |volume=25 |issue=3 |pages=1876–1891 |author1=S. Pokhrel |author2=M. Mandjes |date=2019-03-24|doi=10.1109/TMC.2018.2876366}}</ref>
Multipath TCP is particularly useful in the context of wireless networks;<ref name="PaaschDetal2012">{{cite conference|last1=Paasch|first1=Christoph|conference=ACM SIGCOMM workshop on Cellular Networks (Cellnet'12)|last2=Detal|first2=Gregory|last3=Duchene|first3=Fabien|last4=Raiciu|first4=Costin|last5=Bonaventure|first5=Olivier| title=Proceedings of the 2012 ACM SIGCOMM workshop on Cellular networks: Operations, challenges, and future design - Cell ''Net'' '12 |year=2012|pages=31|doi=10.1145/2342468.2342476|chapter-url=http://inl.info.ucl.ac.be/publications/exploring-mobilewifi-handover-multipath-tcp|chapter=Exploring mobile/WiFi handover with multipath TCP|isbn=9781450314756|doi-access=free}}</ref> using both [[Wi-Fi]] and a [[mobile network]] is a typical [[use case]].<ref name="shivaetal2017">{{cite journal|title=Analytical Modeling of Multipath TCP Over Last-Mile Wireless |journal=IEEE/ACM Transactions on Networking |volume=25 |issue=3 |pages=1876–1891 |author1=S. Pokhrel |author2=M. Panda |author3=H. Vu |date=2017-02-24|doi=10.1109/TNET.2017.2663524 |s2cid=21518823 }}</ref> In addition to the gains in throughput from inverse multiplexing, links may be added or dropped as the user moves in or out of coverage without disrupting the end-to-end TCP connection.<ref name=" pokhrel2018improving ">{{cite journal|title= Improving Multipath TCP Performance over WiFi and Cellular Networks: an Analytical Approach |journal= IEEE Transactions on Mobile Computing |volume=25 |issue=3 |pages=1876–1891 |author1=S. Pokhrel |author2=M. Mandjes |date=2019-03-24|doi=10.1109/TMC.2018.2876366|s2cid= 69263415 }}</ref>


The problem of link [[handover]] is thus solved by abstraction in the [[transport layer]], without any special mechanisms at the [[network layer|network]] or [[link layer|link]] level. Handover functionality can then be implemented at the endpoints without requiring special functionality in the [[subnetwork]]s - in accordance to the Internet's [[end-to-end principle]].
The problem of link [[handover]] is thus solved by abstraction in the [[transport layer]], without any special mechanisms at the [[network layer|network]] or [[link layer]]s. Handover functionality can then be implemented at the endpoints without requiring special functionality in the [[subnetwork]]s - in accordance to the Internet's [[end-to-end principle]].


Multipath TCP also brings performance benefits in [[datacenter]] environments.<ref name=":1">{{Cite journal | last1=Raiciu |last2=Barre |last3=Pluntke |last4=Greenhalgh |last5=Wischik |last6=Handley | title=Improving datacenter performance and robustness with multipath TCP | journal= ACM SIGCOMM Computer Communication Review|volume=41 |issue=4 |pages=266 | year=2011 | url=http://inl.info.ucl.ac.be/publications/improving-datacenter-performance-and-robustness-multipath-tcp | postscript=<!--None--> |doi=10.1145/2043164.2018467 |citeseerx=10.1.1.306.3863 }}</ref> In contrast to [[Ethernet]] channel bonding using [[802.3ad]] link aggregation, Multipath TCP can balance a single TCP connection across multiple interfaces and reach very high throughput.<ref>{{cite web|url=http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps
Multipath TCP also brings performance benefits in [[datacenter]] environments.<ref name=":1">{{Cite journal | last1=Raiciu |last2=Barre |last3=Pluntke |last4=Greenhalgh |last5=Wischik |last6=Handley | title=Improving datacenter performance and robustness with multipath TCP | journal= ACM SIGCOMM Computer Communication Review|volume=41 |issue=4 |pages=266 | year=2011 | url=http://inl.info.ucl.ac.be/publications/improving-datacenter-performance-and-robustness-multipath-tcp |doi=10.1145/2043164.2018467 |citeseerx=10.1.1.306.3863 |s2cid=61962047 }}</ref> In contrast to [[Ethernet]] channel bonding using [[802.3ad]] link aggregation, Multipath TCP can balance a single TCP connection across multiple interfaces and reach very high throughput.<ref>{{cite web|url=http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps
|accessdate=2013-09-20
|access-date=2013-09-20
|title=The fastest TCP connection with Multipath TCP
|title=The fastest TCP connection with Multipath TCP
|author1=C. Paasch |author2=G. Detal |author3=S. Barré |author4=F. Duchêne |author5=O. Bonaventure }}</ref>
|author1=C. Paasch |author2=G. Detal |author3=S. Barré |author4=F. Duchêne |author5=O. Bonaventure }}</ref>


Multipath TCP causes a number of new issues. From a network security perspective, multipath routing causes cross-path data fragmentation that results in firewalls and malware scanners becoming inefficient when they only see one path's traffic. In addition, SSL decryption will become inefficient by way of the end-to-end encryption protocols<ref>{{cite thesis|type=PhD|title=Life of a Security Middlebox Challenges with Emerging Protocols and Technologies|date=2020|isbn=978-91-7867-103-8|oclc=1139703033|last=Afzal|first=Zeeshan}}</ref>.
Multipath TCP causes a number of new issues. From a network security perspective, multipath routing causes cross-path data fragmentation that results in firewalls and malware scanners becoming inefficient when they only see one path's traffic. In addition, SSL decryption will become inefficient by way of the end-to-end encryption protocols.<ref>{{cite thesis|type=PhD|title=Life of a Security Middlebox Challenges with Emerging Protocols and Technologies|date=2020|isbn=978-91-7867-103-8|oclc=1139703033|last=Afzal|first=Zeeshan}}</ref>


==User interface==
==User interface==

In order to facilitate its deployment, Multipath TCP presents the same socket interface as TCP. This implies that any standard TCP application can be used above Multipath TCP while in fact spreading data across several subflows.<ref name="linux-kernel-multipath-tcp-project">{{cite web|url=http://www.multipath-tcp.org/
In order to facilitate its deployment, Multipath TCP presents the same socket interface as TCP. This implies that any standard TCP application can be used above Multipath TCP while in fact spreading data across several subflows.<ref name="linux-kernel-multipath-tcp-project">{{cite web|url=http://www.multipath-tcp.org/
|accessdate=2014-11-28
|access-date=2014-11-28
|title=The Linux kernel MultiPath TCP project
|title=The Linux kernel MultiPath TCP project
}}
}}
Line 29: Line 41:
[[File:Multipath TCP architecture.jpg|thumb|Multipath TCP in the protocol stack]]
[[File:Multipath TCP architecture.jpg|thumb|Multipath TCP in the protocol stack]]


Some applications could benefit from an enhanced API to control the underlying Multipath TCP stack. Two different APIs have been proposed to expose some of features of the Multipath TCP stack to applications: an API that extends [[Netlink]] on Linux<ref name="HesmansDetal2015">{{cite book|last1=Hesmans|first1=B.|last2=Detal|first2=G.|last3=Barre|first3=S.|last4=Bauduin|first4=R.|last5=Bonaventure|first5=O.|title= SMAPP towards smart Multipath TCP-enabled applications|year=2015|pages=1–7|doi=10.1145/2716281.2836113|chapter=SMAPP|isbn=9781450334129}}</ref> and an enhanced socket API.<ref name="HesmansBonaventure2016">{{cite book|last1=Hesmans|first1=Benjamin|title=Proceedings of the 2016 workshop on Applied Networking Research Workshop - ANRW 16|last2=Bonaventure|first2=Olivier|chapter=An enhanced socket API for Multipath TCP|year=2016|pages=1–6|doi=10.1145/2959424.2959433|isbn=9781450344432}}</ref>
Some applications could benefit from an enhanced API to control the underlying Multipath TCP stack. Two different APIs have been proposed to expose some of features of the Multipath TCP stack to applications: an API that extends [[Netlink]] on Linux<ref name="HesmansDetal2015">{{cite book|last1=Hesmans|first1=B.|last2=Detal|first2=G.|last3=Barre|first3=S.|last4=Bauduin|first4=R.|last5=Bonaventure|first5=O.|title= SMAPP towards smart Multipath TCP-enabled applications|year=2015|pages=1–7|doi=10.1145/2716281.2836113|chapter=SMAPP|isbn=9781450334129|s2cid=9940025}}</ref> and an enhanced socket API.<ref name="HesmansBonaventure2016">{{cite book|last1=Hesmans|first1=Benjamin|title=Proceedings of the 2016 workshop on Applied Networking Research Workshop - ANRW 16|last2=Bonaventure|first2=Olivier|chapter=An enhanced socket API for Multipath TCP|year=2016|pages=1–6|doi=10.1145/2959424.2959433|isbn=9781450344432|s2cid=13799560}}</ref>


==Implementation==
==Implementations==
In July 2013, the MPTCP working group reported five independent implementations of Multipath TCP,<ref>{{cite web|url=http://datatracker.ietf.org/doc/draft-eardley-mptcp-implementations-survey/?include_text=1
In July 2013, the MPTCP working group reported five independent implementations of Multipath TCP,<ref>{{cite web|url=http://datatracker.ietf.org/doc/draft-eardley-mptcp-implementations-survey/?include_text=1
|accessdate=2013-09-20
|access-date=2013-09-20
|title=Survey of MPTCP Implementations (Internet-Draft, 2013)
|title=Survey of MPTCP Implementations (Internet-Draft, 2013)
}}</ref> including the reference implementation<ref name="linux-kernel-multipath-tcp-project"/> in the Linux kernel.<ref>{{Cite journal |last1=Barre |last2=Paasch |last3=Bonaventure | title=MultiPath TCP: From Theory to Practice | journal=IFIP Networking | year=2011 | url=http://inl.info.ucl.ac.be/publications/multipath-tcp-theory-practice | postscript=<!--None--> }}</ref><ref>{{Cite journal |last1=Raiciu |last2=Paasch |last3=Barre |last4=Ford | last5= Honda |last6=Duchene |last7=Bonaventure | last8=Handley| title=How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP | journal=Usenix Nsdi |pages=399–412 | year=2012 | url=https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp | postscript=<!--None--> }}</ref>
}}</ref> including the initial reference implementation<ref name="linux-kernel-multipath-tcp-project"/> in the Linux kernel.<ref>{{Cite journal |last1=Barre |last2=Paasch |last3=Bonaventure | title=MultiPath TCP: From Theory to Practice | journal=IFIP Networking | year=2011 | url=http://inl.info.ucl.ac.be/publications/multipath-tcp-theory-practice }}</ref><ref>{{Cite journal |last1=Raiciu |last2=Paasch |last3=Barre |last4=Ford | last5= Honda |last6=Duchene |last7=Bonaventure | last8=Handley| title=How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP | journal=Usenix NSDI |pages=399–412 | year=2012 | url=https://www.usenix.org/conference/nsdi12/how-hard-can-it-be-designing-and-implementing-deployable-multipath-tcp }}</ref>


The currently available [[implementation]]s are:
The currently available [[implementation]]s are:
* [[Linux kernel]] (reference implementation) from [[Université catholique de Louvain]] researchers and other collaborators ,<ref name="linux-kernel-multipath-tcp-project" />
* [[Linux kernel]] (new reference implementation) introduced in the mainlined kernel in v5.6<ref>{{cite web|url=https://www.mptcp.dev|title=Linux MPTCP Upstream Project}}</ref>
* [[Linux kernel]] (initial reference implementation) [[Fork (software development)|fork]] from [[Université catholique de Louvain]] researchers and other collaborators<ref name="linux-kernel-multipath-tcp-project" />
* [[FreeBSD]] (IPv4 only) from [[Swinburne University of Technology]],<ref>{{cite web|url=http://lists.freebsd.org/pipermail/freebsd-net/2013-March/034882.html|accessdate=2013-09-23|title=Multipath TCP for FreeBSD v0.1}}</ref>
* [[F5 Networks]] BIG-IP LTM,<ref name="f5-big-ip">{{cite web|url=http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-ltm-11-5-0.html#rn_new|accessdate=2014-05-30|title=Release Note: BIG-IP LTM and TMOS 11.5.0|publisher=f5 Networks|date=2014-05-30}}</ref>
* [[FreeBSD]] (IPv4 only) from [[Swinburne University of Technology]]<ref>{{cite web|url=http://lists.freebsd.org/pipermail/freebsd-net/2013-March/034882.html|access-date=2013-09-23|title=Multipath TCP for FreeBSD v0.1}}</ref>
* [[F5 Networks]] BIG-IP LTM<ref name="f5-big-ip">{{cite web|url=http://support.f5.com/kb/en-us/products/big-ip_ltm/releasenotes/product/relnote-ltm-11-5-0.html#rn_new|access-date=2014-05-30|title=Release Note: BIG-IP LTM and TMOS 11.5.0|publisher=f5 Networks|date=2014-05-30}}</ref>
* [[Citrix Systems|Citrix]] Netscaler,<ref name="citrix-netscaler">{{cite web|url=http://blogs.citrix.com/2013/05/28/maximize-mobile-user-experience-with-netscaler-multipath-tcp/
* [[Citrix Systems|Citrix]] Netscaler<ref name="citrix-netscaler">{{cite web|url=http://blogs.citrix.com/2013/05/28/maximize-mobile-user-experience-with-netscaler-multipath-tcp/
|accessdate=2013-09-20
|access-date=2013-09-20
|title=Maximize mobile user experience with NetScaler Multipath TCP
|title=Maximize mobile user experience with NetScaler Multipath TCP
|author=John Gudmundson
|author=John Gudmundson
Line 48: Line 61:
|date=2013-05-28
|date=2013-05-28
}}</ref>
}}</ref>
* [[Apple Inc.|Apple]] [[iOS 7]], released on September 18, 2013 is the first large scale commercial deployment of Multipath TCP.<ref>{{cite web|url=http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mptcp.html|accessdate=2013-09-20|title=Apple seems to also believe in Multipath TCP}}</ref>. Since [[iOS 7]], any application can use Multipath TCP.
* [[Apple Inc.|Apple]] [[iOS 7]], released on September 18, 2013 is the first large scale commercial deployment of Multipath TCP.<ref>{{cite web|url=http://perso.uclouvain.be/olivier.bonaventure/blog/html/2013/09/18/mptcp.html|access-date=2013-09-20|title=Apple seems to also believe in Multipath TCP}}</ref> Since [[iOS 7]], any application can use Multipath TCP.
* [[Apple Inc.|Apple]] [[Mac OS X 10.10]], released on October 16, 2014.<ref>{{cite web|url=http://labs.neohapsis.com/2014/10/20/mptcp-roams-free-by-default-os-x-yosemite/|accessdate=2015-09-16|title=MPTCP ROAMS FREE (BY DEFAULT!) – OS X YOSEMITE|date=2014-10-20}}</ref>
* [[Apple Inc.|Apple]] [[Mac OS X 10.10]], released on October 16, 2014<ref>{{cite web|url=http://labs.neohapsis.com/2014/10/20/mptcp-roams-free-by-default-os-x-yosemite/|access-date=2015-09-16|title=MPTCP ROAMS FREE (BY DEFAULT!) – OS X YOSEMITE|date=2014-10-20}}</ref>
* [[Alcatel-Lucent]] released MPTCP proxy version 0.9 source code on October 26, 2012.<ref>{{cite web|url=https://www.ietf.org/mail-archive/web/multipathtcp/current/msg01934.html|accessdate=2016-12-28|title=code release for MPTCP Proxy|date=2012-10-26|author=Georg Hampel|publisher=Alcatel-Lucent}}</ref><ref>{{cite web|url=https://www.ietf.org/proceedings/85/slides/slides-85-mptcp-0.pdf|title=MPTCP PROXY|accessdate=2016-12-28|date=2012-10-26|author=Georg Hampel|author2=Anil Rana|publisher=[[Bell Labs]]/[[Alcatel-Lucent]]}}</ref>
* [[Alcatel-Lucent]] released MPTCP proxy version 0.9 source code on October 26, 2012<ref>{{cite web|url=https://www.ietf.org/mail-archive/web/multipathtcp/current/msg01934.html|access-date=2016-12-28|title=code release for MPTCP Proxy|date=2012-10-26|author=Georg Hampel|publisher=Alcatel-Lucent}}</ref><ref>{{cite web|url=https://www.ietf.org/proceedings/85/slides/slides-85-mptcp-0.pdf|title=MPTCP PROXY|access-date=2016-12-28|date=2012-10-26|author=Georg Hampel|author2=Anil Rana|publisher=[[Bell Labs]]/[[Alcatel-Lucent]]}}</ref>


In July 2014, Oracle reported that an implementation on [[Solaris (operating system)|Solaris]] was being developed. In June 2015, work is in progress.<ref>{{cite web|last1=Rao|first1=Shoaib|title=Some comments on RFC 6824|url=https://mailarchive.ietf.org/arch/msg/multipathtcp/ugMIu566McQMn8YCju-CTjW9beY|accessdate=25 June 2015}}</ref>
In July 2014, Oracle reported that an implementation on [[Solaris (operating system)|Solaris]] was being developed. In June 2015, work is in progress.<ref>{{cite web|last1=Rao|first1=Shoaib|title=Some comments on RFC 6824|url=https://mailarchive.ietf.org/arch/msg/multipathtcp/ugMIu566McQMn8YCju-CTjW9beY|access-date=25 June 2015}}</ref> There is also an ongoing effort to push a new Multipath TCP implementation in the mainline Linux kernel.<ref>{{cite web|url=https://www.tessares.net/open-source/mptcp-upstream-project|access-date=2020-01-10|title=MPTCP Upstream Project|date=2019-12-17}}</ref>


During the MPTCP WG meeting at IETF 93, SungHoon Seo announced that KT had deployed since mid June a commercial service that allows smartphone users to reach 1 Gbit/s using a MPTCP proxy service.<ref>{{cite web|url=https://www.ietf.org/proceedings/93/slides/slides-93-mptcp-3.pdf|title=KT's GiGA LTE}}</ref>. Tessares uses the Linux kernel implementation to deploy [[Hybrid Access Networks]]
During the MPTCP WG meeting at IETF 93, SungHoon Seo announced that KT had deployed since mid June a commercial service that allows smartphone users to reach 1&nbsp;Gbit/s using a MPTCP proxy service.<ref>{{cite web|url=https://www.ietf.org/proceedings/93/slides/slides-93-mptcp-3.pdf|title=KT's GiGA LTE}}</ref> Tessares uses the Linux kernel implementation to deploy [[Hybrid Access Networks]].

There is an ongoing effort to push a new Multipath TCP implementation in the mainline Linux kernel, <ref>{{cite web|url=https://www.tessares.net/open-source/mptcp-upstream-project|accessdate=2020-01-10|title=MPTCP Upstream Project|date=2019-12-17}}</ref>


== Use cases ==
== Use cases ==


Multipath TCP was designed to be backward compatible with regular TCP. As such, it can support any application. However, some specific deployments<ref>{{Cite journal|last=Bonaventure|first=Olivier|last2=See|first2=SungHoon|year=2016|title=Multipath TCP Deployments|url=https://www.ietfjournal.org/multipath-tcp-deployments/|journal=IETF Journal|volume=|pages=|via=}}</ref> leverage the ability of simultaneously using different paths.
Multipath TCP was designed to be backward compatible with regular TCP. As such, it can support any application. However, some specific deployments<ref>{{Cite journal|last1=Bonaventure|first1=Olivier|last2=See|first2=SungHoon|year=2016|title=Multipath TCP Deployments|url=https://www.ietfjournal.org/multipath-tcp-deployments/|journal=IETF Journal}}</ref> leverage the ability of simultaneously using different paths.


[[Apple Inc.|Apple]] uses Multipath TCP to support the [[Siri]] application on [[iPhone]]. [[Siri]] sends voice samples over an [[HTTPS]] session to Apple servers. Those servers reply with the information requested by the users. According to [[Apple Inc.|Apple]] engineers, the main benefits<ref>C. Paasch, iOS & Linux Implementation Updates, IETF-99, https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-ios-linux-implementation-updates/</ref> of Multipath TCP with this application are :
[[Apple Inc.|Apple]] uses Multipath TCP to support the [[Siri]] application on [[iPhone]]. Siri sends voice samples over an [[HTTPS]] session to Apple servers. Those servers reply with the information requested by the users. According to Apple engineers, the main benefits<ref>C. Paasch, iOS & Linux Implementation Updates, IETF-99, https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-ios-linux-implementation-updates/</ref> of Multipath TCP with this application are:
* User-feedback (Time-to-First-Word) 20% faster in the 95th percentile
* User-feedback (Time-to-First-Word) 20% faster in the 95th percentile
* 5x reduction of network failures
* 5x reduction of network failures


Other deployment use Multipath TCP to aggregate the bandwidth of different networks. For example, several types of smartphones, notably in Korea, use Multipath TCP to bond WiFi and 4G through SOCKS proxies<ref>S. Seo, KT’s GiGA LTE - Mobile MPTCP Proxy Deployment, IETF-97, https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-01.pdf</ref>. Another example are the [[Hybrid Access Networks]] that are deployed by network operators willing to combine xDSL and LTE networks. In this deployment, Multipath TCP is used to efficiently balance the traffic over the xDSL and the LTE network<ref>Gregory Detal, Sebastien Barre, Bart Peirens, Olivier Bonaventure, "Leveraging Multipath TCP to create Hybrid Access Networks ", SIGCOMM'17 (Industrial demo), http://conferences.sigcomm.org/sigcomm/2017/files/program-industrial-demos/sigcomm17industrialdemos-paper4.pdf</ref>.
Other deployment use Multipath TCP to aggregate the bandwidth of different networks. For example, several types of smartphones, notably in Korea, use Multipath TCP to bond WiFi and 4G through SOCKS proxies.<ref>S. Seo, KT’s GiGA LTE - Mobile MPTCP Proxy Deployment, IETF-97, https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-01.pdf</ref> Another example are the [[Hybrid Access Networks]] that are deployed by network operators willing to combine [[xDSL]] and [[LTE (telecommunication)|LTE]] networks. In this deployment, Multipath TCP is used to efficiently balance the traffic over the xDSL and the LTE network.<ref>Gregory Detal, Sebastien Barre, Bart Peirens, Olivier Bonaventure, "Leveraging Multipath TCP to create Hybrid Access Networks ", SIGCOMM'17 (Industrial demo), http://conferences.sigcomm.org/sigcomm/2017/files/program-industrial-demos/sigcomm17industrialdemos-paper4.pdf</ref>

In the standardisation of converged fixed and mobile communication networks, [[3GPP]] and [[Broadband Forum|BBF]] are interoperating to provide an ATSSS (Access Traffic Selection, Switching, Splitting) feature to support multipath sessions, e.g, by applying Multipath TCP both in the User Equipment (UE) or Residential Gateway (RG) and on the network side.<ref>3GPP TR 23.793, "Study on access traffic steering, switch and splitting support in the 5G system architecture (Release 16)", https://www.3gpp.org/ftp/Specs/latest/Rel-16/23_series/23793-g00.zip</ref>


==Multipath TCP options==
==Multipath TCP options==


Multipath TCP uses options that are described in detail in RFC 6824. All Multipath TCP options are encoded as TCP options with Option Kind is 30, as reserved by IANA.<ref>{{cite web|url=http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1
Multipath TCP uses options that are described in detail in {{IETF RFC|8684|link=no}}. All Multipath TCP options are encoded as TCP options with Option Kind 30, as reserved by IANA.<ref>{{cite web|url=https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1
|accessdate=2013-09-24
|access-date=2013-09-24
|title=IANA Protocol Registry TCP Option Kind Numbers
|title=IANA Protocol Registry TCP Option Kind Numbers
}}</ref>
}}</ref>


The Multipath TCP option has the Kind (30), length (variable) and the remainder of the content begins with a 4-bit subtype field, for which [[Internet Assigned Numbers Authority|IANA]] has created and will maintain a sub-registry entitled "MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry. Those subtype fields are defined as follows:
The Multipath TCP option consists of the standard Option-Kind (in this case 30) and Length values, followed by a 4-bit subtype field, for which the [[Internet Assigned Numbers Authority|IANA]] maintains a sub-registry entitled "MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry. This subtype field indicates the MPTCP header type, and its values are defined as follows:
{| class="wikitable"
{| class="wikitable"
|-
|-
Line 84: Line 97:
| 0x1 || MP_JOIN || Join Connection
| 0x1 || MP_JOIN || Join Connection
|-
|-
| 0x2 || DSS || Data Sequence Signal (Data ACK and data sequence mapping)
| 0x2 || DSS || Data Sequence Signal (Data ACK and Data Sequence Mapping)
|-
|-
| 0x3 || ADD_ADDR || Add Address
| 0x3 || ADD_ADDR || Add Address
Line 96: Line 109:
| 0x7 || MP_FASTCLOSE || Fast Close
| 0x7 || MP_FASTCLOSE || Fast Close
|-
|-
| 0x8 || MP_TCPRST || Subflow Reset
| 0xf || (PRIVATE) || Private Use within controlled testbeds
|-
| 0xf || MP_EXPERIMENTAL || Reserved for Private Use
|}
|}


Values 0x8 through 0xe are currently unassigned.
Values 0x9 through 0xe are currently unassigned.


==Protocol operation==
==Protocol operation==
Line 109: Line 124:
For instance, Alice has a smartphone with 3G and WiFi interfaces (with IP addresses 10.11.12.13 and 10.11.12.14) and Bob has a computer with an Ethernet interface (with IP address 20.21.22.23).
For instance, Alice has a smartphone with 3G and WiFi interfaces (with IP addresses 10.11.12.13 and 10.11.12.14) and Bob has a computer with an Ethernet interface (with IP address 20.21.22.23).


In standard TCP, the connection should be established between two IP addresses. Each TCP connection is identified by a four-tuple (source and destination addresses and ports). Given this restriction, an application can only create one TCP connection through a single link. Multipath TCP allows the connection to use several paths simultaneously. For this, Multipath TCP creates one TCP connection, called subflow, over each path that needs to be used.
In standard TCP, the connection should be established between two IP addresses. Each TCP connection is identified by a four-tuple (source and destination addresses and ports). Given this restriction, an application can only create one TCP connection through a single link. Multipath TCP allows the connection to use several paths simultaneously. For this, Multipath TCP creates one TCP connection, called subflow, over each path that needs to be used.


The purpose of the different protocol operations (defined in RFC 6824) are:
The purpose of the different protocol operations (defined in RFC 6824) are:


* to handle when and how to add/remove paths (for instance if there's a connection lost of some congestion control)
* to handle when and how to add/remove paths (for instance if there's a connection lost or some congestion control)
* to be compatible with legacy TCP hardware (such as some firewalls that can automatically reject TCP connections if the sequence number aren't successive)
* to be compatible with legacy TCP hardware (such as some firewalls that can automatically reject TCP connections if the sequence number aren't successive)
* to define a fair congestion control strategy between the different links and the different hosts (especially with those that doesn't support MPTCP)
* to define a fair congestion control strategy between the different links and the different hosts (especially with those that don't support MPTCP)
[[File:MPTCP-session-en.png|thumb|Example of a full MPTCP session]]
[[File:MPTCP-session-en.png|thumb|Example of a full MPTCP session]]
Multipath TCP adds new mechanisms to TCP transmissions:
Multipath TCP adds new mechanisms to TCP transmissions:


* The subflow system, used to gather multiple standard TCP connections (the paths from one host to another). Subflows are identified during the TCP three-way handshake. After the handshake, an application can add or remove some subflows (subtypes 0x3 and 0x4).
* The subflow system, used to gather multiple standard TCP connections (the paths from one host to another). Subflows are identified during the TCP three-way handshake. After the handshake, an application can add or remove some subflows (subtypes 0x3 and 0x4).
* The MPTCP DSS option contains a data sequence number and an acknowledgement number. These allow receiving data from multiple subflows in the original order, without any corruption (message subtype 0x2)
* The MPTCP DSS option contains a data sequence number and an acknowledgement number. These allow receiving data from multiple subflows in the original order, without any corruption (message subtype 0x2)
* A modified retransmission protocol handles congestion control and reliability.
* A modified retransmission protocol handles congestion control and reliability.


=== Detailed specification ===
=== Detailed specification ===


The detailed protocol specification is provided in RFC 6824. Several survey articles provide an introduction to the protocol.<ref name="mptcp-queue">{{cite journal|last2=Bonaventure|first2=Olivier|date=April 2014|title=Multipath TCP|url=http://queue.acm.org/detail.cfm?id=2591369|journal=Communications of the ACM|volume=57|issue=4|pages=51–57|doi=10.1145/2578901|last1=Paasch|first1=Christoph}}</ref><ref name="mptcp-ebook">{{cite book|url=http://www.sigcomm.org/content/ebook|title=Recent Advances in Reliable Transport Protocols|last2=Iyengar|first2=Janardhan|last3=Bonaventure|first3=Olivier|date=2013|publisher=ACM SIGCOMM|ref=mptcp-ebook|last1=Raiciu|first1=Costin|editor1-last=Haddadi|editor1-first=Hamed|editor2-last=Bonaventure|editor2-first=Olivier}}</ref>
The detailed protocol specification is provided in RFC 8684. Several survey articles provide an introduction to the protocol.<ref name="mptcp-queue">{{cite journal|last2=Bonaventure|first2=Olivier|date=April 2014|title=Multipath TCP|url=http://queue.acm.org/detail.cfm?id=2591369|journal=Communications of the ACM|volume=57|issue=4|pages=51–57|doi=10.1145/2578901|last1=Paasch|first1=Christoph|s2cid=17581886}}</ref><ref name="mptcp-ebook">{{cite book|url=http://www.sigcomm.org/content/ebook|title=Recent Advances in Reliable Transport Protocols|last2=Iyengar|first2=Janardhan|last3=Bonaventure|first3=Olivier|date=2013|publisher=ACM SIGCOMM|ref=mptcp-ebook|last1=Raiciu|first1=Costin|editor1-last=Haddadi|editor1-first=Hamed|editor2-last=Bonaventure|editor2-first=Olivier}}</ref>


==Congestion control==
==Congestion control==
Line 132: Line 147:


* The Linked Increase Algorithm defined in <nowiki>RFC 6356</nowiki>
* The Linked Increase Algorithm defined in <nowiki>RFC 6356</nowiki>
* The Opportunistic Linked Increase Algorithm<ref name="KhaliliGast2012">{{cite book|last1=Khalili|first1=Ramin|journal=Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies - CoNEXT '12|last2=Gast|first2=Nicolas|last3=Popovic|first3=Miroslav|last4=Upadhyay|first4=Utkarsh|last5=Le Boudec|first5=Jean-Yves|year=2012|pages=1|doi=10.1145/2413176.2413178|title=MPTCP is not pareto-optimal|isbn=9781450317757}}</ref>
* The Opportunistic Linked Increase Algorithm<ref name="KhaliliGast2012">{{cite book|last1=Khalili|first1=Ramin|last2=Gast|first2=Nicolas|last3=Popovic|first3=Miroslav|last4=Upadhyay|first4=Utkarsh|last5=Le Boudec|first5=Jean-Yves|title=Proceedings of the 8th international conference on Emerging networking experiments and technologies |chapter=MPTCP is not pareto-optimal |year=2012|pages=1–12|doi=10.1145/2413176.2413178|isbn=9781450317757|s2cid=14210629| url=http://infoscience.epfl.ch/record/182920 }}</ref>
* The wVegas delay based congestion control algorithm
* The wVegas delay based congestion control algorithm
* The Balanced Linked Increase Algorithm<ref name="balia">{{cite journal |last1=Peng|first1=Qiuyu|title=Multipath TCP: Analysis, Design and Implementation|journal=IEEE/ACM Transactions on Networking|volume=24|pages=596–609|last2=Walid|first2=Anwar|last3=Hwang|first3=Jaehyun|last4= Low|first4=Steven H.|year=2013|arxiv=1308.3119|bibcode=2013arXiv1308.3119P|doi=10.1109/TNET.2014.2379698}}</ref>
* The Balanced Linked Increase Algorithm<ref name="balia">{{cite journal |last1=Peng|first1=Qiuyu|title=Multipath TCP: Analysis, Design and Implementation|journal=IEEE/ACM Transactions on Networking|volume=24|pages=596–609|last2=Walid|first2=Anwar|last3=Hwang|first3=Jaehyun|last4= Low|first4=Steven H.|year=2013|arxiv=1308.3119|bibcode=2013arXiv1308.3119P|doi=10.1109/TNET.2014.2379698|s2cid=250322}}</ref>


==Alternatives==
==Alternatives==
Line 140: Line 155:
===Stream Control Transmission Protocol===
===Stream Control Transmission Protocol===
{{main article|Stream Control Transmission Protocol}}
{{main article|Stream Control Transmission Protocol}}
[[Stream Control Transmission Protocol]] (SCTP) is a reliable in-order [[datagram]] stream transport protocol originally intended for telecommunication signaling. It supports concurrent use of multiple access links and allows the application to influence the access interface selections on a datagram stream basis. It also supports mobility via access renegotiation. Hence, SCTP is also a transport layer solution. It offers type 3 flow granularity with concurrency, but with more flow scheduling control than Multipath TCP. It also fully supports mobility in a fashion similar to Multipath TCP.<ref name=":10">{{cite web
[[Stream Control Transmission Protocol]] (SCTP) is a reliable in-order [[datagram]] stream transport protocol originally intended for telecommunication signaling. It supports concurrent use of multiple access links and allows the application to influence the access interface selections on a datagram stream basis. It also supports mobility via access renegotiation. Hence, SCTP is also a transport layer solution. It offers type 3 flow granularity with concurrency, but with more flow scheduling control than Multipath TCP. It also fully supports mobility in a fashion similar to Multipath TCP.<ref name=":10">{{cite web
|url = http://www-csag.ucsd.edu/projects/Optiputer/papers/2002-rodriguez.pdf
|url = http://www-csag.ucsd.edu/projects/Optiputer/papers/2002-rodriguez.pdf
|title = Dynamic parallel access to replicated content in the Internet
|title = Dynamic parallel access to replicated content in the Internet
Line 148: Line 163:
|date = 2002-07-01
|date = 2002-07-01
|url-status = dead
|url-status = dead
|archiveurl = https://web.archive.org/web/20130927012704/http://www-csag.ucsd.edu/projects/Optiputer/papers/2002-rodriguez.pdf
|archive-url = https://web.archive.org/web/20130927012704/http://www-csag.ucsd.edu/projects/Optiputer/papers/2002-rodriguez.pdf
|archivedate = 2013-09-27
|archive-date = 2013-09-27
}}</ref>
}}</ref>


===IMS SIP===
===IMS SIP===
{{main article|Session Initiation Protocol|IP Multimedia Subsystem}}
{{main article|Session Initiation Protocol|IP Multimedia Subsystem}}
Within the [[IP Multimedia Subsystem]] (IMS) architecture, [[Session Initiation Protocol]] (SIP) can support the concurrent use of multiple contact IP addresses for the registration of one or more IMS user agents. This allows for the creation of multiple IMS signaling paths. On these signaling paths, signaling messages carry [[Session Description Protocol]] (SDP) messaging to negotiate media streams. SDP allows for the (re-)negotiation of the streams of one media session over multiple paths. In turn, this enables application layer multipath transport. From this point of view, IMS can therefore offer application layer multipath support with flow granularity and concurrent access. A multipath extension to [[Real-time Transport Protocol]] (RTP) is currently under discussion within the IETF. Multipath RTP can offer flow granularity with concurrent access and mobility (via IMS, SDP signaling or the RTP control protocol).<ref name=":10" />
Within the [[IP Multimedia Subsystem]] (IMS) architecture, [[Session Initiation Protocol]] (SIP) can support the concurrent use of multiple contact IP addresses for the registration of one or more IMS user agents. This allows for the creation of multiple IMS signaling paths. On these signaling paths, signaling messages carry [[Session Description Protocol]] (SDP) messaging to negotiate media streams. SDP allows for the (re-)negotiation of the streams of one media session over multiple paths. In turn, this enables application layer multipath transport. From this point of view, IMS can therefore offer application layer multipath support with flow granularity and concurrent access. A multipath extension to [[Real-time Transport Protocol]] (RTP) has been under discussion within the IETF.<ref>{{Cite web | url=https://tools.ietf.org/html/draft-ietf-avtcore-mprtp | title=Draft-ietf-avtcore-MPRTP-03 }}</ref> Multipath RTP can offer flow granularity with concurrent access and mobility (via IMS, SDP signaling or the RTP control protocol).<ref name=":10" /> Very recently in addition a proposal to extend also [[Datagram Congestion Control Protocol|DCCP]] (Datagram Congestion Control Protocol) by a multipath feature is discussed at IETF in TSVWG (Transport Area Working Group) <ref>{{Cite web | url=https://tools.ietf.org/html/draft-ietf-tsvwg-multipath-dccp | title=Draft-ietf-TSVWG-multipath-DCCP-04 }}</ref> dubbed as [[Multipath DCCP|MP-DCCP]].


=== Multipath QUIC ===
=== Multipath QUIC ===


The [[IETF]] is currently developing the [[QUIC]] protocol that integrates the features that are traditionally found in the [[Transmission Control Protocol|TCP]], [[Transport Layer Security|TLS]] and [[HTTP]] protocols. Thanks to the flexibility and extensibility of QUIC, it is possible to extend it to support multiple paths and address the same use cases as Multipath TCP. A first design for Multipath QUIC has been proposed<ref>{{cite web|url=https://tools.ietf.org/html/draft-deconinck-multipath-quic-00
The [[IETF]] is currently developing the [[QUIC]] protocol that integrates the features that are traditionally found in the [[Transmission Control Protocol|TCP]], [[Transport Layer Security|TLS]] and [[HTTP]] protocols. It can be extended to support the same use cases as Multipath TCP. A first design for Multipath QUIC has been proposed,<ref>{{cite web|url=https://tools.ietf.org/html/draft-deconinck-multipath-quic-00
|title=Multipath Extension for QUIC
|title=Multipath Extension for QUIC
|author1=Q. De Coninck |author2=O. Bonaventure |publisher= IETF Internet draft
|author1=Q. De Coninck |author2=O. Bonaventure |publisher=[[IETF]]
|date=2010-10-30
|date=2010-10-30
}}</ref>, implemented and evaluated<ref>{{cite web|url=http://multipath-quic.org/conext17-deconinck.pdf
}}</ref> implemented and evaluated.<ref>{{cite web|url=http://multipath-quic.org/conext17-deconinck.pdf
|title=Multipath QUIC: Design and Evaluation
|title=Multipath QUIC: Design and Evaluation
|author1=Q. De Coninck |author2=O. Bonaventure |publisher= Proc. Conext'2017, Seoul, Korea
|author1=Q. De Coninck |author2=O. Bonaventure |publisher= Proc. Conext'2017, Seoul, Korea
|date=2010-12-12
|date=2010-12-12
}}</ref>.
}}</ref>


===Other protocols and experiments===
===Other protocols and experiments===
Line 178: Line 193:


==RFC==
==RFC==
* RFC 6181 - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
* {{IETF RFC|6181|link=no}} - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
* RFC 6182 - Architectural Guidelines for Multipath TCP Development
* {{IETF RFC|6182|link=no}} - Architectural Guidelines for Multipath TCP Development
* RFC 6356 - Coupled Congestion Control for Multipath Transport Protocols
* {{IETF RFC|6356|link=no}} - Coupled Congestion Control for Multipath Transport Protocols
* RFC 6824 - TCP Extensions for Multipath Operation with Multiple Addresses
* {{IETF RFC|6824|link=no}} - TCP Extensions for Multipath Operation with Multiple Addresses (v0; replaced by RFC 8684)
* RFC 6897 - Multipath TCP (MPTCP) Application Interface Considerations
* {{IETF RFC|6897|link=no}} - Multipath TCP (MPTCP) Application Interface Considerations
* RFC 7430 - Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)
* {{IETF RFC|7430|link=no}} - Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)
* RFC 8041 - Use Cases and Operational Experience with Multipath TCP
* {{IETF RFC|8041|link=no}} - Use Cases and Operational Experience with Multipath TCP
* {{IETF RFC|8684|link=no}} - TCP Extensions for Multipath Operation with Multiple Addresses (v1)
* {{IETF RFC|8803|link=no}} - 0-RTT TCP Convert Protocol


==See also==
==See also==
* [[Transport Layer#Comparison of transport layer protocols|Transport protocol comparison table]]
* [[Transport layer#Comparison of transport layer protocols|Transport protocol comparison table]]


==References==
==References==
Line 194: Line 211:
==External links==
==External links==
{{Wikiversity | Transmission Control Protocol}}
{{Wikiversity | Transmission Control Protocol}}
* [http://www.multipath-tcp.org The Linux Kernel MultiPath TCP project]
* [https://www.mptcp.dev The Linux Kernel MultiPath TCP project]
* [http://www.multipath-tcp.org The Linux Kernel MultiPath TCP project] (former website)
* [https://lwn.net/Articles/544399/ A clear article explaining the Linux MPTCP implementation]
* [https://lwn.net/Articles/544399/ A clear article explaining the Linux MPTCP implementation]


[[Category:Transmission Control Protocol| ]]
[[Category:TCP extensions]]

Latest revision as of 17:22, 23 April 2024

Multipath TCP (MPTCP)
Communication protocol
PurposeGeneral Purpose
Developer(s)IETF
Introduction2009; 15 years ago (2009)
Based onIP, normally layered with TCP
OSI layerTransport layer
RFC(s)RFC 8684
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

Multipath TCP (MPTCP) is an ongoing effort of the Internet Engineering Task Force's (IETF) Multipath TCP working group, that aims at allowing a Transmission Control Protocol (TCP) connection to use multiple paths to maximize throughput and increase redundancy.[1]

In January 2013, the IETF published the Multipath specification as an Experimental standard in RFC 6824. It was replaced in March 2020 by the Multipath TCP v1 specification in RFC 8684.

Benefits

[edit]

The redundancy offered by Multipath TCP enables inverse multiplexing of resources, and thus increases TCP throughput to the sum of all available link-level channels instead of using a single one as required by standard TCP. Multipath TCP is backward compatible with standard TCP.

Multipath TCP is particularly useful in the context of wireless networks;[2] using both Wi-Fi and a mobile network is a typical use case.[3] In addition to the gains in throughput from inverse multiplexing, links may be added or dropped as the user moves in or out of coverage without disrupting the end-to-end TCP connection.[4]

The problem of link handover is thus solved by abstraction in the transport layer, without any special mechanisms at the network or link layers. Handover functionality can then be implemented at the endpoints without requiring special functionality in the subnetworks - in accordance to the Internet's end-to-end principle.

Multipath TCP also brings performance benefits in datacenter environments.[5] In contrast to Ethernet channel bonding using 802.3ad link aggregation, Multipath TCP can balance a single TCP connection across multiple interfaces and reach very high throughput.[6]

Multipath TCP causes a number of new issues. From a network security perspective, multipath routing causes cross-path data fragmentation that results in firewalls and malware scanners becoming inefficient when they only see one path's traffic. In addition, SSL decryption will become inefficient by way of the end-to-end encryption protocols.[7]

User interface

[edit]

In order to facilitate its deployment, Multipath TCP presents the same socket interface as TCP. This implies that any standard TCP application can be used above Multipath TCP while in fact spreading data across several subflows.[8]

Multipath TCP in the protocol stack

Some applications could benefit from an enhanced API to control the underlying Multipath TCP stack. Two different APIs have been proposed to expose some of features of the Multipath TCP stack to applications: an API that extends Netlink on Linux[9] and an enhanced socket API.[10]

Implementations

[edit]

In July 2013, the MPTCP working group reported five independent implementations of Multipath TCP,[11] including the initial reference implementation[8] in the Linux kernel.[12][13]

The currently available implementations are:

In July 2014, Oracle reported that an implementation on Solaris was being developed. In June 2015, work is in progress.[22] There is also an ongoing effort to push a new Multipath TCP implementation in the mainline Linux kernel.[23]

During the MPTCP WG meeting at IETF 93, SungHoon Seo announced that KT had deployed since mid June a commercial service that allows smartphone users to reach 1 Gbit/s using a MPTCP proxy service.[24] Tessares uses the Linux kernel implementation to deploy Hybrid Access Networks.

Use cases

[edit]

Multipath TCP was designed to be backward compatible with regular TCP. As such, it can support any application. However, some specific deployments[25] leverage the ability of simultaneously using different paths.

Apple uses Multipath TCP to support the Siri application on iPhone. Siri sends voice samples over an HTTPS session to Apple servers. Those servers reply with the information requested by the users. According to Apple engineers, the main benefits[26] of Multipath TCP with this application are:

  • User-feedback (Time-to-First-Word) 20% faster in the 95th percentile
  • 5x reduction of network failures

Other deployment use Multipath TCP to aggregate the bandwidth of different networks. For example, several types of smartphones, notably in Korea, use Multipath TCP to bond WiFi and 4G through SOCKS proxies.[27] Another example are the Hybrid Access Networks that are deployed by network operators willing to combine xDSL and LTE networks. In this deployment, Multipath TCP is used to efficiently balance the traffic over the xDSL and the LTE network.[28]

In the standardisation of converged fixed and mobile communication networks, 3GPP and BBF are interoperating to provide an ATSSS (Access Traffic Selection, Switching, Splitting) feature to support multipath sessions, e.g, by applying Multipath TCP both in the User Equipment (UE) or Residential Gateway (RG) and on the network side.[29]

Multipath TCP options

[edit]

Multipath TCP uses options that are described in detail in RFC 8684. All Multipath TCP options are encoded as TCP options with Option Kind 30, as reserved by IANA.[30]

The Multipath TCP option consists of the standard Option-Kind (in this case 30) and Length values, followed by a 4-bit subtype field, for which the IANA maintains a sub-registry entitled "MPTCP Option Subtypes" under the "Transmission Control Protocol (TCP) Parameters" registry. This subtype field indicates the MPTCP header type, and its values are defined as follows:

Value Symbol Name
0x0 MP_CAPABLE Multipath Capable
0x1 MP_JOIN Join Connection
0x2 DSS Data Sequence Signal (Data ACK and Data Sequence Mapping)
0x3 ADD_ADDR Add Address
0x4 REMOVE_ADDR Remove Address
0x5 MP_PRIO Change Subflow Priority
0x6 MP_FAIL Fallback
0x7 MP_FASTCLOSE Fast Close
0x8 MP_TCPRST Subflow Reset
0xf MP_EXPERIMENTAL Reserved for Private Use

Values 0x9 through 0xe are currently unassigned.

Protocol operation

[edit]

Simplified description

[edit]
Difference between TCP and MPTCP

The core idea of multipath TCP is to define a way to build a connection between two hosts and not between two interfaces (as standard TCP does).

For instance, Alice has a smartphone with 3G and WiFi interfaces (with IP addresses 10.11.12.13 and 10.11.12.14) and Bob has a computer with an Ethernet interface (with IP address 20.21.22.23).

In standard TCP, the connection should be established between two IP addresses. Each TCP connection is identified by a four-tuple (source and destination addresses and ports). Given this restriction, an application can only create one TCP connection through a single link. Multipath TCP allows the connection to use several paths simultaneously. For this, Multipath TCP creates one TCP connection, called subflow, over each path that needs to be used.

The purpose of the different protocol operations (defined in RFC 6824) are:

  • to handle when and how to add/remove paths (for instance if there's a connection lost or some congestion control)
  • to be compatible with legacy TCP hardware (such as some firewalls that can automatically reject TCP connections if the sequence number aren't successive)
  • to define a fair congestion control strategy between the different links and the different hosts (especially with those that don't support MPTCP)
Example of a full MPTCP session

Multipath TCP adds new mechanisms to TCP transmissions:

  • The subflow system, used to gather multiple standard TCP connections (the paths from one host to another). Subflows are identified during the TCP three-way handshake. After the handshake, an application can add or remove some subflows (subtypes 0x3 and 0x4).
  • The MPTCP DSS option contains a data sequence number and an acknowledgement number. These allow receiving data from multiple subflows in the original order, without any corruption (message subtype 0x2)
  • A modified retransmission protocol handles congestion control and reliability.

Detailed specification

[edit]

The detailed protocol specification is provided in RFC 8684. Several survey articles provide an introduction to the protocol.[31][32]

Congestion control

[edit]

Several congestion control mechanisms have been defined for Multipath TCP. Their main difference with classical TCP congestion control schemes is that they need to react to congestion on the different paths without being unfair with single path TCP sources that could compete with them on one of the paths.[3] Four Multipath TCP congestion control schemes are currently supported by the Multipath TCP implementation in the Linux kernel.

  • The Linked Increase Algorithm defined in RFC 6356
  • The Opportunistic Linked Increase Algorithm[33]
  • The wVegas delay based congestion control algorithm
  • The Balanced Linked Increase Algorithm[34]

Alternatives

[edit]

Stream Control Transmission Protocol

[edit]
Main article: Stream Control Transmission Protocol

Stream Control Transmission Protocol (SCTP) is a reliable in-order datagram stream transport protocol originally intended for telecommunication signaling. It supports concurrent use of multiple access links and allows the application to influence the access interface selections on a datagram stream basis. It also supports mobility via access renegotiation. Hence, SCTP is also a transport layer solution. It offers type 3 flow granularity with concurrency, but with more flow scheduling control than Multipath TCP. It also fully supports mobility in a fashion similar to Multipath TCP.[35]

IMS SIP

[edit]
Main articles: Session Initiation Protocol and IP Multimedia Subsystem

Within the IP Multimedia Subsystem (IMS) architecture, Session Initiation Protocol (SIP) can support the concurrent use of multiple contact IP addresses for the registration of one or more IMS user agents. This allows for the creation of multiple IMS signaling paths. On these signaling paths, signaling messages carry Session Description Protocol (SDP) messaging to negotiate media streams. SDP allows for the (re-)negotiation of the streams of one media session over multiple paths. In turn, this enables application layer multipath transport. From this point of view, IMS can therefore offer application layer multipath support with flow granularity and concurrent access. A multipath extension to Real-time Transport Protocol (RTP) has been under discussion within the IETF.[36] Multipath RTP can offer flow granularity with concurrent access and mobility (via IMS, SDP signaling or the RTP control protocol).[35] Very recently in addition a proposal to extend also DCCP (Datagram Congestion Control Protocol) by a multipath feature is discussed at IETF in TSVWG (Transport Area Working Group) [37] dubbed as MP-DCCP.

Multipath QUIC

[edit]

The IETF is currently developing the QUIC protocol that integrates the features that are traditionally found in the TCP, TLS and HTTP protocols. It can be extended to support the same use cases as Multipath TCP. A first design for Multipath QUIC has been proposed,[38] implemented and evaluated.[39]

Other protocols and experiments

[edit]

At the session layer, the Mobile Access Router project experimented in 2003 with the aggregation of multiple wireless accesses with heterogeneous technologies, transparently balancing traffic between them in response to the perceived performance of each of them.[40]

Parallel access schemes[35] used to accelerate transfers by taking advantage of HTTP range requests to initiate connections to multiple servers of a replicated content, are not equivalent to Multipath TCP as they involve the application layer and are limited to content of known size.

RFC

[edit]
  • RFC 6181 - Threat Analysis for TCP Extensions for Multipath Operation with Multiple Addresses
  • RFC 6182 - Architectural Guidelines for Multipath TCP Development
  • RFC 6356 - Coupled Congestion Control for Multipath Transport Protocols
  • RFC 6824 - TCP Extensions for Multipath Operation with Multiple Addresses (v0; replaced by RFC 8684)
  • RFC 6897 - Multipath TCP (MPTCP) Application Interface Considerations
  • RFC 7430 - Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP)
  • RFC 8041 - Use Cases and Operational Experience with Multipath TCP
  • RFC 8684 - TCP Extensions for Multipath Operation with Multiple Addresses (v1)
  • RFC 8803 - 0-RTT TCP Convert Protocol

See also

[edit]

References

[edit]
  1. ^ Multipath TCP working group
  2. ^ Paasch, Christoph; Detal, Gregory; Duchene, Fabien; Raiciu, Costin; Bonaventure, Olivier (2012). "Exploring mobile/WiFi handover with multipath TCP". Proceedings of the 2012 ACM SIGCOMM workshop on Cellular networks: Operations, challenges, and future design - Cell Net '12. ACM SIGCOMM workshop on Cellular Networks (Cellnet'12). p. 31. doi:10.1145/2342468.2342476. ISBN 9781450314756.
  3. ^ a b S. Pokhrel; M. Panda; H. Vu (2017-02-24). "Analytical Modeling of Multipath TCP Over Last-Mile Wireless". IEEE/ACM Transactions on Networking. 25 (3): 1876–1891. doi:10.1109/TNET.2017.2663524. S2CID 21518823.
  4. ^ S. Pokhrel; M. Mandjes (2019-03-24). "Improving Multipath TCP Performance over WiFi and Cellular Networks: an Analytical Approach". IEEE Transactions on Mobile Computing. 25 (3): 1876–1891. doi:10.1109/TMC.2018.2876366. S2CID 69263415.
  5. ^ Raiciu; Barre; Pluntke; Greenhalgh; Wischik; Handley (2011). "Improving datacenter performance and robustness with multipath TCP". ACM SIGCOMM Computer Communication Review. 41 (4): 266. CiteSeerX 10.1.1.306.3863. doi:10.1145/2043164.2018467. S2CID 61962047.
  6. ^ C. Paasch; G. Detal; S. Barré; F. Duchêne; O. Bonaventure. "The fastest TCP connection with Multipath TCP". Retrieved 2013-09-20.
  7. ^ Afzal, Zeeshan (2020). Life of a Security Middlebox Challenges with Emerging Protocols and Technologies (PhD). ISBN 978-91-7867-103-8. OCLC 1139703033.
  8. ^ a b c "The Linux kernel MultiPath TCP project". Retrieved 2014-11-28.
  9. ^ Hesmans, B.; Detal, G.; Barre, S.; Bauduin, R.; Bonaventure, O. (2015). "SMAPP". SMAPP towards smart Multipath TCP-enabled applications. pp. 1–7. doi:10.1145/2716281.2836113. ISBN 9781450334129. S2CID 9940025.
  10. ^ Hesmans, Benjamin; Bonaventure, Olivier (2016). "An enhanced socket API for Multipath TCP". Proceedings of the 2016 workshop on Applied Networking Research Workshop - ANRW 16. pp. 1–6. doi:10.1145/2959424.2959433. ISBN 9781450344432. S2CID 13799560.
  11. ^ "Survey of MPTCP Implementations (Internet-Draft, 2013)". Retrieved 2013-09-20.
  12. ^ Barre; Paasch; Bonaventure (2011). "MultiPath TCP: From Theory to Practice". IFIP Networking.
  13. ^ Raiciu; Paasch; Barre; Ford; Honda; Duchene; Bonaventure; Handley (2012). "How Hard Can It Be? Designing and Implementing a Deployable Multipath TCP". Usenix NSDI: 399–412.
  14. ^ "Linux MPTCP Upstream Project".
  15. ^ "Multipath TCP for FreeBSD v0.1". Retrieved 2013-09-23.
  16. ^ "Release Note: BIG-IP LTM and TMOS 11.5.0". f5 Networks. 2014-05-30. Retrieved 2014-05-30.
  17. ^ John Gudmundson (2013-05-28). "Maximize mobile user experience with NetScaler Multipath TCP". Citrix. Retrieved 2013-09-20.
  18. ^ "Apple seems to also believe in Multipath TCP". Retrieved 2013-09-20.
  19. ^ "MPTCP ROAMS FREE (BY DEFAULT!) – OS X YOSEMITE". 2014-10-20. Retrieved 2015-09-16.
  20. ^ Georg Hampel (2012-10-26). "code release for MPTCP Proxy". Alcatel-Lucent. Retrieved 2016-12-28.
  21. ^ Georg Hampel; Anil Rana (2012-10-26). "MPTCP PROXY" (PDF). Bell Labs/Alcatel-Lucent. Retrieved 2016-12-28.
  22. ^ Rao, Shoaib. "Some comments on RFC 6824". Retrieved 25 June 2015.
  23. ^ "MPTCP Upstream Project". 2019-12-17. Retrieved 2020-01-10.
  24. ^ "KT's GiGA LTE" (PDF).
  25. ^ Bonaventure, Olivier; See, SungHoon (2016). "Multipath TCP Deployments". IETF Journal.
  26. ^ C. Paasch, iOS & Linux Implementation Updates, IETF-99, https://datatracker.ietf.org/meeting/99/materials/slides-99-mptcp-sessa-ios-linux-implementation-updates/
  27. ^ S. Seo, KT’s GiGA LTE - Mobile MPTCP Proxy Deployment, IETF-97, https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-01.pdf
  28. ^ Gregory Detal, Sebastien Barre, Bart Peirens, Olivier Bonaventure, "Leveraging Multipath TCP to create Hybrid Access Networks ", SIGCOMM'17 (Industrial demo), http://conferences.sigcomm.org/sigcomm/2017/files/program-industrial-demos/sigcomm17industrialdemos-paper4.pdf
  29. ^ 3GPP TR 23.793, "Study on access traffic steering, switch and splitting support in the 5G system architecture (Release 16)", https://www.3gpp.org/ftp/Specs/latest/Rel-16/23_series/23793-g00.zip
  30. ^ "IANA Protocol Registry TCP Option Kind Numbers". Retrieved 2013-09-24.
  31. ^ Paasch, Christoph; Bonaventure, Olivier (April 2014). "Multipath TCP". Communications of the ACM. 57 (4): 51–57. doi:10.1145/2578901. S2CID 17581886.
  32. ^ Raiciu, Costin; Iyengar, Janardhan; Bonaventure, Olivier (2013). Haddadi, Hamed; Bonaventure, Olivier (eds.). Recent Advances in Reliable Transport Protocols. ACM SIGCOMM.
  33. ^ Khalili, Ramin; Gast, Nicolas; Popovic, Miroslav; Upadhyay, Utkarsh; Le Boudec, Jean-Yves (2012). "MPTCP is not pareto-optimal". Proceedings of the 8th international conference on Emerging networking experiments and technologies. pp. 1–12. doi:10.1145/2413176.2413178. ISBN 9781450317757. S2CID 14210629.
  34. ^ Peng, Qiuyu; Walid, Anwar; Hwang, Jaehyun; Low, Steven H. (2013). "Multipath TCP: Analysis, Design and Implementation". IEEE/ACM Transactions on Networking. 24: 596–609. arXiv:1308.3119. Bibcode:2013arXiv1308.3119P. doi:10.1109/TNET.2014.2379698. S2CID 250322.
  35. ^ a b c P. Rodriguez; E. Biersack (2002-07-01). "Dynamic parallel access to replicated content in the Internet" (PDF). IEEE/ACM Transactions on Networking. Archived from the original (PDF) on 2013-09-27.
  36. ^ "Draft-ietf-avtcore-MPRTP-03".
  37. ^ "Draft-ietf-TSVWG-multipath-DCCP-04".
  38. ^ Q. De Coninck; O. Bonaventure (2010-10-30). "Multipath Extension for QUIC". IETF.
  39. ^ Q. De Coninck; O. Bonaventure (2010-12-12). "Multipath QUIC: Design and Evaluation" (PDF). Proc. Conext'2017, Seoul, Korea.
  40. ^ R. Chakravorty; I. Pratt; P. Rodriguez (2003-07-01). "Mobile Access Router". University of Cambridge, Microsoft Research.
[edit]
Wikiversity has learning resources about Transmission Control Protocol
Retrieved from "https://en.wikipedia.org/w/index.php?title=Multipath_TCP&oldid=1220417775"