draft-ietf-mptcp-experience-05.txt   draft-ietf-mptcp-experience-06.txt 
MPTCP Working Group O. Bonaventure MPTCP Working Group O. Bonaventure
Internet-Draft UCLouvain Internet-Draft UCLouvain
Intended status: Informational C. Paasch Intended status: Informational C. Paasch
Expires: January 9, 2017 Apple, Inc. Expires: March 2, 2017 Apple, Inc.
G. Detal G. Detal
Tessares Tessares
July 08, 2016 August 29, 2016
Use Cases and Operational Experience with Multipath TCP Use Cases and Operational Experience with Multipath TCP
draft-ietf-mptcp-experience-05 draft-ietf-mptcp-experience-06
Abstract Abstract
This document discusses both use cases and operational experience This document discusses both use cases and operational experience
with Multipath TCP in real world networks. It lists several with Multipath TCP in real world networks. It lists several
prominent use cases for which Multipath TCP has been considered and prominent use cases for which Multipath TCP has been considered and
is being used. It also gives insight to some heuristics and is being used. It also gives insight to some heuristics and
decisions that have helped to realize these use cases. decisions that have helped to realize these use cases.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2017. This Internet-Draft will expire on March 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 30 skipping to change at page 2, line 30
3.5. Subflow destination port . . . . . . . . . . . . . . . . . 16 3.5. Subflow destination port . . . . . . . . . . . . . . . . . 16
3.6. Closing subflows . . . . . . . . . . . . . . . . . . . . . 17 3.6. Closing subflows . . . . . . . . . . . . . . . . . . . . . 17
3.7. Packet schedulers . . . . . . . . . . . . . . . . . . . . 18 3.7. Packet schedulers . . . . . . . . . . . . . . . . . . . . 18
3.8. Segment size selection . . . . . . . . . . . . . . . . . . 19 3.8. Segment size selection . . . . . . . . . . . . . . . . . . 19
3.9. Interactions with the Domain Name System . . . . . . . . . 19 3.9. Interactions with the Domain Name System . . . . . . . . . 19
3.10. Captive portals . . . . . . . . . . . . . . . . . . . . . 20 3.10. Captive portals . . . . . . . . . . . . . . . . . . . . . 20
3.11. Stateless webservers . . . . . . . . . . . . . . . . . . . 21 3.11. Stateless webservers . . . . . . . . . . . . . . . . . . . 21
3.12. Loadbalanced serverfarms . . . . . . . . . . . . . . . . . 22 3.12. Loadbalanced serverfarms . . . . . . . . . . . . . . . . . 22
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 7. Informative References . . . . . . . . . . . . . . . . . . . . 26
8. Informative References . . . . . . . . . . . . . . . . . . . . 27 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 33
Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Multipath TCP was standardized in [RFC6824] and five independent Multipath TCP was standardized in [RFC6824] and five independent
implementations have been developed implementations have been developed. As of September 2015, Multipath
[I-D.eardley-mptcp-implementations-survey]. As of September 2015, TCP has been or is being implemented on the following platforms:
Multipath TCP has been or is being implemented on the following
platforms:
o Linux kernel [MultipathTCP-Linux] o Linux kernel [MultipathTCP-Linux]
o Apple iOS and MacOS [Apple-MPTCP] o Apple iOS and MacOS [Apple-MPTCP]
o Citrix load balancers o Citrix load balancers
o FreeBSD [FreeBSD-MPTCP] o FreeBSD [FreeBSD-MPTCP]
o Oracle o Oracle
The first three implementations The first three implementations are known to interoperate. The last
[I-D.eardley-mptcp-implementations-survey] are known to interoperate. two are currently being tested and improved against the Linux
The last two are currently being tested and improved against the implementation. Three of these implementations are open-source.
Linux implementation. Three of these implementations are open- Apple's implementation is widely deployed.
source. Apple's implementation is widely deployed.
Since the publication of [RFC6824], experience has been gathered by Since the publication of [RFC6824], experience has been gathered by
various network researchers and users about the operational issues various network researchers and users about the operational issues
that arise when Multipath TCP is used in today's Internet. that arise when Multipath TCP is used in today's Internet.
When the MPTCP working group was created, several use cases for When the MPTCP working group was created, several use cases for
Multipath TCP were identified [RFC6182]. Since then, other use cases Multipath TCP were identified [RFC6182]. Since then, other use cases
have been proposed and some have been tested and even deployed. We have been proposed and some have been tested and even deployed. We
describe these use cases in Section 2. describe these use cases in Section 2.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
from the packet trace discussed in [CACM14]. from the packet trace discussed in [CACM14].
Many cellular networks use volume-based pricing and users often Many cellular networks use volume-based pricing and users often
prefer to use unmetered WiFi networks when available instead of prefer to use unmetered WiFi networks when available instead of
metered cellular networks. [Cellnet12] implements support for the metered cellular networks. [Cellnet12] implements support for the
MP_PRIO option to explore two other modes of operation. MP_PRIO option to explore two other modes of operation.
In the backup mode, Multipath TCP opens a TCP subflow over each In the backup mode, Multipath TCP opens a TCP subflow over each
interface, but the cellular interface is configured in backup mode. interface, but the cellular interface is configured in backup mode.
This implies that data only flows over only the WiFi interface when This implies that data flows only over the WiFi interface when both
both interfaces are considered to be active. If the WiFi interface interfaces are considered to be active. If the WiFi interface fails,
fails, then the traffic switches quickly to the cellular interface, then the traffic switches quickly to the cellular interface, ensuring
ensuring a smooth handover from the user's viewpoint [Cellnet12]. a smooth handover from the user's viewpoint [Cellnet12]. The cost of
The cost of this approach is that the WiFi and cellular interfaces this approach is that the WiFi and cellular interfaces are likely to
are likely to remain active all the time since all subflows are remain active all the time since all subflows are established over
established over the two interfaces. the two interfaces.
The single-path mode is slightly different. This mode benefits from The single-path mode is slightly different. This mode benefits from
the break-before-make capability of Multipath TCP. When an MPTCP the break-before-make capability of Multipath TCP. When an MPTCP
session is established, a subflow is created over the WiFi interface. session is established, a subflow is created over the WiFi interface.
No packet is sent over the cellular interface as long as the WiFi No packet is sent over the cellular interface as long as the WiFi
interface remains up [Cellnet12]. This implies that the cellular interface remains up [Cellnet12]. This implies that the cellular
interface can remain idle and battery capacity is preserved. When interface can remain idle and battery capacity is preserved. When
the WiFi interface fails, a new subflow is established over the the WiFi interface fails, a new subflow is established over the
cellular interface in order to preserve the established Multipath TCP cellular interface in order to preserve the established Multipath TCP
sessions. Compared to the backup mode described earlier, sessions. Compared to the backup mode described earlier,
skipping to change at page 9, line 9 skipping to change at page 9, line 9
used by regular users. This analysis reveals that short connections used by regular users. This analysis reveals that short connections
are important on smartphones and that the main benefit of using are important on smartphones and that the main benefit of using
Multipath TCP on smartphones is the ability to perform seamless Multipath TCP on smartphones is the ability to perform seamless
handovers between different wireless networks. Long connections handovers between different wireless networks. Long connections
benefit from these handovers. benefit from these handovers.
2.3. Multipath TCP proxies 2.3. Multipath TCP proxies
As Multipath TCP is not yet widely deployed on both clients and As Multipath TCP is not yet widely deployed on both clients and
servers, several deployments have used various forms of proxies. Two servers, several deployments have used various forms of proxies. Two
families of solutions are currently being used or tested families of solutions are currently being used or tested.
[I-D.deng-mptcp-proxy].
A first use case is when a Multipath TCP enabled client wants to use A first use case is when a Multipath TCP enabled client wants to use
several interfaces to reach a regular TCP server. A typical use case several interfaces to reach a regular TCP server. A typical use case
is a smartphone that needs to use both its WiFi and its cellular is a smartphone that needs to use both its WiFi and its cellular
interface to transfer data. Several types of proxies are possible interface to transfer data. Several types of proxies are possible
for this use case. An HTTP proxy deployed on a Multipath TCP capable for this use case. An HTTP proxy deployed on a Multipath TCP capable
server would enable the smartphone to use Multipath TCP to access server would enable the smartphone to use Multipath TCP to access
regular web servers. Obviously, this solution only works for regular web servers. Obviously, this solution only works for
applications that rely on HTTP. Another possibility is to use a applications that rely on HTTP. Another possibility is to use a
proxy that can convert any Multipath TCP connection into a regular proxy that can convert any Multipath TCP connection into a regular
TCP connection. Multipath TCP-specific proxies have been proposed TCP connection. Multipath TCP-specific proxies have been proposed
[I-D.wei-mptcp-proxy-mechanism] [HotMiddlebox13b] [HotMiddlebox13b] [HAMPEL].
[I-D.hampel-mptcp-proxies-anchors].
Another possibility leverages the SOCKS protocol [RFC1928]. SOCKS is Another possibility leverages the SOCKS protocol [RFC1928]. SOCKS is
often used in enterprise networks to allow clients to reach external often used in enterprise networks to allow clients to reach external
servers. For this, the client opens a TCP connection to the SOCKS servers. For this, the client opens a TCP connection to the SOCKS
server that relays it to the final destination. If both the client server that relays it to the final destination. If both the client
and the SOCKS server use Multipath TCP, but not the final and the SOCKS server use Multipath TCP, but not the final
destination, then Multipath TCP can still be used on the path between destination, then Multipath TCP can still be used on the path between
the client and the SOCKS server. At IETF'93, Korea Telecom announced the client and the SOCKS server. At IETF'93, Korea Telecom announced
that they have deployed in June 2015 a commercial service that uses that they have deployed in June 2015 a commercial service that uses
Multipath TCP on smartphones. These smartphones access regular TCP Multipath TCP on smartphones. These smartphones access regular TCP
skipping to change at page 11, line 34 skipping to change at page 11, line 34
o split or coalesce segments o split or coalesce segments
o remove TCP options o remove TCP options
o modify the payload of TCP segments o modify the payload of TCP segments
These middlebox interferences have all been included in the MBtest These middlebox interferences have all been included in the MBtest
suite [MBTest]. This test suite is used in [HotMiddlebox13] to suite [MBTest]. This test suite is used in [HotMiddlebox13] to
verify the reaction of the Multipath TCP implementation in the Linux verify the reaction of the Multipath TCP implementation in the Linux
kernel when faced with middlebox interference. The test environment kernel [MultipathTCP-Linux] when faced with middlebox interference.
used for this evaluation is a dual-homed client connected to a The test environment used for this evaluation is a dual-homed client
single-homed server. The middlebox behavior can be activated on any connected to a single-homed server. The middlebox behavior can be
of the paths. The main results of this analysis are : activated on any of the paths. The main results of this analysis are
:
o the Multipath TCP implementation in the Linux kernel is not o the v0.87 Multipath TCP implementation in the Linux kernel is not
affected by a middlebox that performs NAT or modifies TCP sequence affected by a middlebox that performs NAT or modifies TCP sequence
numbers numbers
o when a middlebox removes the MP_CAPABLE option from the initial o when a middlebox removes the MP_CAPABLE option from the initial
SYN segment, the Multipath TCP implementation in the Linux kernel SYN segment, the v0.87 Multipath TCP implementation in the Linux
falls back correctly to regular TCP kernel falls back correctly to regular TCP
o when a middlebox removes the DSS option from all data segments, o when a middlebox removes the DSS option from all data segments,
the Multipath TCP implementation in the Linux kernel falls back the v0.87 Multipath TCP implementation in the Linux kernel falls
correctly to regular TCP back correctly to regular TCP
o when a middlebox performs segment coalescing, the Multipath TCP o when a middlebox performs segment coalescing, the v0.87 Multipath
implementation in the Linux kernel is still able to accurately TCP implementation in the Linux kernel is still able to accurately
extract the data corresponding to the indicated mapping extract the data corresponding to the indicated mapping
o when a middlebox performs segment splitting, the Multipath TCP o when a middlebox performs segment splitting, the v0.87 Multipath
implementation in the Linux kernel correctly reassembles the data TCP implementation in the Linux kernel correctly reassembles the
corresponding to the indicated mapping. [HotMiddlebox13] shows on data corresponding to the indicated mapping. [HotMiddlebox13]
figure 4 in section 3.3 a corner case with segment splitting that shows on figure 4 in section 3.3 a corner case with segment
may lead to a desynchronisation between the two hosts. splitting that may lead to a desynchronisation between the two
hosts.
The interactions between Multipath TCP and real deployed middleboxes The interactions between Multipath TCP and real deployed middleboxes
is also analyzed in [HotMiddlebox13] and a particular scenario with is also analyzed in [HotMiddlebox13] and a particular scenario with
the FTP application level gateway running on a NAT is described. the FTP application level gateway running on a NAT is described.
Middlebox interference can also be detected by analysing packet Middlebox interference can also be detected by analysing packet
traces on Multipath TCP enabled servers. A closer look at the traces on Multipath TCP enabled servers. A closer look at the
packets received on the multipath-tcp.org server [TMA2015] shows that packets received on the multipath-tcp.org server [TMA2015] shows that
among the 184,000 Multipath TCP connections, only 125 of them were among the 184,000 Multipath TCP connections, only 125 of them were
falling back to regular TCP. These connections originated from 28 falling back to regular TCP. These connections originated from 28
skipping to change at page 12, line 37 skipping to change at page 12, line 41
similar conclusions about the middlebox interference are provided. similar conclusions about the middlebox interference are provided.
From an operational viewpoint, knowing that Multipath TCP can cope From an operational viewpoint, knowing that Multipath TCP can cope
with various types of middlebox interference is important. However, with various types of middlebox interference is important. However,
there are situations where the network operators need to gather there are situations where the network operators need to gather
information about where a particular middlebox interference occurs. information about where a particular middlebox interference occurs.
The tracebox software [tracebox] described in [IMC13a] is an The tracebox software [tracebox] described in [IMC13a] is an
extension of the popular traceroute software that enables network extension of the popular traceroute software that enables network
operators to check at which hop a particular field of the TCP header operators to check at which hop a particular field of the TCP header
(including options) is modified. It has been used by several network (including options) is modified. It has been used by several network
operators to debug various middlebox interference problems. tracebox operators to debug various middlebox interference problems.
includes a scripting language that enables its user to specify Experience with tracebox indicates that supporting the ICMP extension
precisely which packet (including IP and TCP options) is sent by the defined in [RFC1812] makes it easier to debug middlebox problems in
source. tracebox sends packets with an increasing TTL/HopLimit and IPv4 networks.
compares the information returned in the ICMP messages with the
packet that it sent. This enables tracebox to detect any
interference caused by middleboxes on a given path. tracebox works
better when routers implement the ICMP extension defined in
[RFC1812].
Users of the Multipath TCP implementation have reported some Users of the Multipath TCP implementation have reported some
experience with middlebox interference. The strangest scenario has experience with middlebox interference. The strangest scenario has
been a middlebox that accepts the Multipath TCP options in the SYN been a middlebox that accepts the Multipath TCP options in the SYN
segment but later replaces Multipath TCP options with a TCP EOL segment but later replaces Multipath TCP options with a TCP EOL
option [StrangeMbox]. This causes Multipath TCP to perform a option [StrangeMbox]. This causes Multipath TCP to perform a
fallback to regular TCP without any impact on the application. fallback to regular TCP without any impact on the application.
3.2. Congestion control 3.2. Congestion control
Congestion control has been an important problem for Multipath TCP. Congestion control has been an important challenge for Multipath TCP.
The standardised congestion control scheme for Multipath TCP is The standardised congestion control scheme for Multipath TCP is
defined in [RFC6356] and [NSDI11]. This congestion control scheme defined in [RFC6356]. A detailed description of this algorithm is
has been implemented in the Linux implementation of Multipath TCP. provided in [NSDI11]. This congestion control scheme has been
Linux uses a modular architecture to support various congestion implemented in the Linux implementation of Multipath TCP. Linux uses
control schemes. This architecture is applicable for both regular a modular architecture to support various congestion control schemes.
TCP and Multipath TCP. While the coupled congestion control scheme This architecture is applicable for both regular TCP and Multipath
defined in [RFC6356] is the default congestion control scheme in the TCP. While the coupled congestion control scheme defined in
Linux implementation, other congestion control schemes have been [RFC6356] is the default congestion control scheme in the Linux
added. The second congestion control scheme is OLIA [CONEXT12]. implementation, other congestion control schemes have been added.
This congestion control scheme is also an adaptation of the NewReno The second congestion control scheme is OLIA [CONEXT12]. This
single path congestion control scheme to support multiple paths. congestion control scheme is also an adaptation of the NewReno single
path congestion control scheme to support multiple paths.
Simulations and measurements have shown that it provides some Simulations and measurements have shown that it provides some
performance benefits compared to the the default congestion control performance benefits compared to the the default congestion control
scheme [CONEXT12]. Measurements over a wide range of parameters scheme [CONEXT12]. Measurements over a wide range of parameters
reported in [CONEXT13] also indicate some benefits with the OLIA reported in [CONEXT13] also indicate some benefits with the OLIA
congestion control scheme. Recently, a delay-based congestion congestion control scheme. Recently, a delay-based congestion
control scheme has been ported to the Multipath TCP implementation in control scheme has been ported to the Multipath TCP implementation in
the Linux kernel. This congestion control scheme has been evaluated the Linux kernel. This congestion control scheme has been evaluated
by using simulations in [ICNP12]. The fourth congestion control by using simulations in [ICNP12]. The fourth congestion control
scheme that has been included in the Linux implementation of scheme that has been included in the Linux implementation of
Multipath TCP is the BALIA scheme Multipath TCP is the BALIA scheme that provides a better balance
[I-D.walid-mptcp-congestion-control]. between TCP friendliness, responsiveness, and window oscillation
[BALIA].
These different congestion control schemes have been compared in These different congestion control schemes have been compared in
several articles. [CONEXT13] and [PaaschPhD] compare these several articles. [CONEXT13] and [PaaschPhD] compare these
algorithms in an emulated environment. The evaluation showed that algorithms in an emulated environment. The evaluation showed that
the delay-based congestion control scheme is less able to efficiently the delay-based congestion control scheme is less able to efficiently
use the available links than the three other schemes. Reports from use the available links than the three other schemes. Reports from
some users indicate that they seem to favor OLIA. some users indicate that they seem to favor OLIA.
3.3. Subflow management 3.3. Subflow management
skipping to change at page 14, line 8 skipping to change at page 14, line 8
and terminate them. However, there are no guidelines on how subflows and terminate them. However, there are no guidelines on how subflows
are used during the lifetime of a Multipath TCP session. Most of the are used during the lifetime of a Multipath TCP session. Most of the
published experiments with Multipath TCP have been performed in published experiments with Multipath TCP have been performed in
controlled environments. Still, based on the experience running them controlled environments. Still, based on the experience running them
and discussions on the mptcp-dev mailing list, interesting lessons and discussions on the mptcp-dev mailing list, interesting lessons
have been learned about the management of these subflows. have been learned about the management of these subflows.
From a subflow viewpoint, the Multipath TCP protocol is completely From a subflow viewpoint, the Multipath TCP protocol is completely
symmetrical. Both the clients and the server have the capability to symmetrical. Both the clients and the server have the capability to
create subflows. However in practice the existing Multipath TCP create subflows. However in practice the existing Multipath TCP
implementations [I-D.eardley-mptcp-implementations-survey] have opted implementations have opted for a strategy where only the client
for a strategy where only the client creates new subflows. The main creates new subflows. The main motivation for this strategy is that
motivation for this strategy is that often the client resides behind often the client resides behind a NAT or a firewall, preventing
a NAT or a firewall, preventing passive subflow openings on the passive subflow openings on the client. Although there are
client. Although there are environments such as datacenters where environments such as datacenters where this problem does not occur,
this problem does not occur, as of this writing, no precise as of this writing, no precise requirement has emerged for allowing
requirement has emerged for allowing the server to create new the server to create new subflows.
subflows.
3.4. Implemented subflow managers 3.4. Implemented subflow managers
The Multipath TCP implementation in the Linux kernel includes several The Multipath TCP implementation in the Linux kernel includes several
strategies to manage the subflows that compose a Multipath TCP strategies to manage the subflows that compose a Multipath TCP
session. The basic subflow manager is the full-mesh. As the name session. The basic subflow manager is the full-mesh. As the name
implies, it creates a full-mesh of subflows between the communicating implies, it creates a full-mesh of subflows between the communicating
hosts. hosts.
The most frequent use case for this subflow manager is a multihomed The most frequent use case for this subflow manager is a multihomed
skipping to change at page 17, line 38 skipping to change at page 17, line 37
Sub: fin-wait-2 | | Sub: fin-wait-2 | |
| | | |
| subflow-FIN | | subflow-FIN |
MPTCP: closed | <------------------------ | subflow-close() MPTCP: closed | <------------------------ | subflow-close()
Sub: time-wait | subflow-ACK | Sub: time-wait | subflow-ACK |
(step 3) | ------------------------> | MPTCP: time-wait (step 3) | ------------------------> | MPTCP: time-wait
| | Sub: closed | | Sub: closed
| | | |
Figure 5: Multipath TCP may not be able to avoid time-wait state on Figure 5: Multipath TCP may not be able to avoid time-wait state on
the subflow (indicated as "Sub the subflow (indicated as Sub in the drawing), even if enforced by
the application on the client-side.
Figure 5 shows a very particular issue within Multipath TCP. Many Figure 5 shows a very particular issue within Multipath TCP. Many
high-performance applications try to avoid Time-Wait state by high-performance applications try to avoid Time-Wait state by
deferring the closure of the connection until the peer has sent a deferring the closure of the connection until the peer has sent a
FIN. That way, the client on the left of Figure 5 does a passive FIN. That way, the client on the left of Figure 5 does a passive
closure of the connection, transitioning from Close-Wait to Last-ACK closure of the connection, transitioning from Close-Wait to Last-ACK
and finally freeing the resources after reception of the ACK of the and finally freeing the resources after reception of the ACK of the
FIN. An application running on top of a Multipath TCP enabled Linux FIN. An application running on top of a Multipath TCP enabled Linux
kernel might also use this approach. The difference here is that the kernel might also use this approach. The difference here is that the
close() of the connection (Step 1 in Figure 5) only triggers the close() of the connection (Step 1 in Figure 5) only triggers the
skipping to change at page 20, line 35 skipping to change at page 20, line 35
between the CDN provider and the network operators. A similar between the CDN provider and the network operators. A similar
problem occurs with regular TCP if the client caches DNS replies. problem occurs with regular TCP if the client caches DNS replies.
For example the client obtains a DNS answer over the cellular For example the client obtains a DNS answer over the cellular
interface and then stops this interface and starts to use its WiFi interface and then stops this interface and starts to use its WiFi
interface. If the client retrieves data from cdn1 over its WiFi interface. If the client retrieves data from cdn1 over its WiFi
interface, this may also violate the contract between the CDN and the interface, this may also violate the contract between the CDN and the
network operators. network operators.
A possible solution to prevent this problem would be to modify the A possible solution to prevent this problem would be to modify the
DNS resolution on the client. The client subnet EDNS extension DNS resolution on the client. The client subnet EDNS extension
defined in [I-D.ietf-dnsop-edns-client-subnet] could be used for this defined in [RFC7871] could be used for this purpose. When the client
purpose. When the client sends a DNS query from its WiFi interface, sends a DNS query from its WiFi interface, it should also send the
it should also send the client subnet corresponding to the cellular client subnet corresponding to the cellular interface in this
interface in this request. This would indicate to the resolver that request. This would indicate to the resolver that the answer should
the answer should be valid for both the WiFi and the cellular be valid for both the WiFi and the cellular interfaces (e.g., the
interfaces (e.g., the cdn3 server). cdn3 server).
3.10. Captive portals 3.10. Captive portals
Multipath TCP enables a host to use different interfaces to reach a Multipath TCP enables a host to use different interfaces to reach a
server. In theory, this should ensure connectivity when at least one server. In theory, this should ensure connectivity when at least one
of the interfaces is active. In practice however, there are some of the interfaces is active. In practice however, there are some
particular scenarios with captive portals that may cause operational particular scenarios with captive portals that may cause operational
problems. The reference environment is shown in Figure 7. problems. The reference environment is shown in Figure 7.
client ----- network1 client ----- network1
skipping to change at page 25, line 5 skipping to change at page 25, line 5
4. IANA Considerations 4. IANA Considerations
There are no IANA considerations in this informational document. There are no IANA considerations in this informational document.
5. Security Considerations 5. Security Considerations
The security considerations for Multipath TCP have already been The security considerations for Multipath TCP have already been
documented in [RFC6181], [RFC6182], [RFC6824] and [RFC7430]. documented in [RFC6181], [RFC6182], [RFC6824] and [RFC7430].
6. Conclusion 6. Acknowledgements
In this document, we have documented a few years of experience with
Multipath TCP. The different scientific publications that have been
summarised confirm that Multipath TCP works well in different use
cases in today's Internet. None of the cited publications has
identified major issues with Multipath TCP and its utilisation in the
current Internet. Some of these publications list directions for
future improvements that mainly affect the subflow managers and
packet schedulers. These heuristics affect the performance of
Multipath TCP, but not the protocol itself. It is likely that these
improvements will be discussed in future IETF documents.
Besides the published scientific literature, a number of companies
have deployed Multipath TCP at large. One of these deployments uses
Multipath TCP on the client and the server side, making it a true
end-to-end deployment. This deployment uses Multipath TCP to support
fast handover between cellular and WiFi networks. A wider deployment
of Multipath TCP on servers seems to be blocked by the necessity to
support Multipath TCP on load balancers. Given the influence that
middleboxes had on the design of Multipath TCP, it is interesting to
note that the other industrial deployments use Multipath TCP inside
middleboxes. These middelboxes use Multipath TCP to efficiently
combine several access links while still interacting with legacy TCP
servers.
7. Acknowledgements
This work was partially supported by the FP7-Trilogy2 project. We This work was partially supported by the FP7-Trilogy2 project. We
would like to thank all the implementers and users of the Multipath would like to thank all the implementers and users of the Multipath
TCP implementation in the Linux kernel. This document has benefited TCP implementation in the Linux kernel. This document has benefited
from the comments of John Ronan, Yoshifumi Nishida, Phil Eardley and from the comments of John Ronan, Yoshifumi Nishida, Phil Eardley,
Jaehyun Hwang. Jaehyun Hwang and Mirja Kuehlewind.
8. Informative References 7. Informative References
[Apple-MPTCP] [Apple-MPTCP]
Apple, Inc, ., "iOS - Multipath TCP Support in iOS 7", Apple, Inc, ., "iOS - Multipath TCP Support in iOS 7",
n.d., <https://support.apple.com/en-us/HT201373>. n.d., <https://support.apple.com/en-us/HT201373>.
[BALIA] Peng, Q., Walid, A., Hwang, J., and S. Low, "Multipath TCP
Analysis, Design, and Implementation", IEEE/ACM Trans. on
Networking, Vol. 24, No. 1 , 2016.
[BBF-WT348] [BBF-WT348]
Fabregas (Ed), G., "WT-348 - Hybrid Access for Broadband Fabregas (Ed), G., "WT-348 - Hybrid Access for Broadband
Networks", Broadband Forum, contribution bbf2014.1139.04 , Networks", Broadband Forum, contribution bbf2014.1139.04 ,
June 2015. June 2015.
[CACM14] Paasch, C. and O. Bonaventure, "Multipath TCP", [CACM14] Paasch, C. and O. Bonaventure, "Multipath TCP",
Communications of the ACM, 57(4):51-57 , April 2014, Communications of the ACM, 57(4):51-57 , April 2014,
<http://inl.info.ucl.ac.be/publications/multipath-tcp>. <http://inl.info.ucl.ac.be/publications/multipath-tcp>.
[COMCOM2016] [COMCOM2016]
skipping to change at page 28, line 28 skipping to change at page 27, line 33
[DetalMSS] [DetalMSS]
Detal, G., "Adaptive MSS value", Post on the mptcp-dev Detal, G., "Adaptive MSS value", Post on the mptcp-dev
mailing list , September 2014, <https:// mailing list , September 2014, <https://
listes-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2014-09/ listes-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2014-09/
msg00130.html>. msg00130.html>.
[FreeBSD-MPTCP] [FreeBSD-MPTCP]
Williams, N., "Multipath TCP For FreeBSD Kernel Patch Williams, N., "Multipath TCP For FreeBSD Kernel Patch
v0.5", n.d., <http://caia.swin.edu.au/urp/newtcp/mptcp>. v0.5", n.d., <http://caia.swin.edu.au/urp/newtcp/mptcp>.
[HAMPEL] Hampel, G., Rana, A., and T. Klein, "Seamless TCP mobility
using lightweight MPTCP proxy", Proceedings of the 11th
ACM international symposium on Mobility management and
wireless access (MobiWac '13). , 2013.
[HotMiddlebox13] [HotMiddlebox13]
Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O. Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O.
Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT
workshop HotMiddlebox , December 2013, <http:// workshop HotMiddlebox , December 2013, <http://
inl.info.ucl.ac.be/publications/ inl.info.ucl.ac.be/publications/
are-tcp-extensions-middlebox-proof>. are-tcp-extensions-middlebox-proof>.
[HotMiddlebox13b] [HotMiddlebox13b]
Detal, G., Paasch, C., and O. Bonaventure, "Multipath in Detal, G., Paasch, C., and O. Bonaventure, "Multipath in
the Middle(Box)", HotMiddlebox'13 , December 2013, <http:/ the Middle(Box)", HotMiddlebox'13 , December 2013, <http:/
skipping to change at page 29, line 5 skipping to change at page 28, line 13
multipath TCP", Proceedings of the 9th ACM SIGCOMM multipath TCP", Proceedings of the 9th ACM SIGCOMM
Workshop on Hot Topics in Networks (Hotnets-IX) , 2010, Workshop on Hot Topics in Networks (Hotnets-IX) , 2010,
<http://doi.acm.org/10.1145/1868447.1868457>. <http://doi.acm.org/10.1145/1868447.1868457>.
[I-D.boucadair-mptcp-max-subflow] [I-D.boucadair-mptcp-max-subflow]
Boucadair, M. and C. Jacquenet, "Negotiating the Maximum Boucadair, M. and C. Jacquenet, "Negotiating the Maximum
Number of Multipath TCP (MPTCP) Subflows", Number of Multipath TCP (MPTCP) Subflows",
draft-boucadair-mptcp-max-subflow-02 (work in progress), draft-boucadair-mptcp-max-subflow-02 (work in progress),
May 2016. May 2016.
[I-D.deng-mptcp-proxy]
Lingli, D., Liu, D., Sun, T., Boucadair, M., and G.
Cauchie, "Use-cases and Requirements for MPTCP Proxy in
ISP Networks", draft-deng-mptcp-proxy-01 (work in
progress), October 2014.
[I-D.eardley-mptcp-implementations-survey]
Eardley, P., "Survey of MPTCP Implementations",
draft-eardley-mptcp-implementations-survey-02 (work in
progress), July 2013.
[I-D.hampel-mptcp-proxies-anchors]
Hampel, G. and T. Klein, "MPTCP Proxies and Anchors",
draft-hampel-mptcp-proxies-anchors-00 (work in progress),
February 2012.
[I-D.ietf-dnsop-edns-client-subnet]
Contavalli, C., Gaast, W., tale, t., and W. Kumari,
"Client Subnet in DNS Queries",
draft-ietf-dnsop-edns-client-subnet-08 (work in progress),
April 2016.
[I-D.lhwxz-gre-notifications-hybrid-access] [I-D.lhwxz-gre-notifications-hybrid-access]
Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.
Zhang, "GRE Notifications for Hybrid Access", Zhang, "GRE Notifications for Hybrid Access",
draft-lhwxz-gre-notifications-hybrid-access-01 (work in draft-lhwxz-gre-notifications-hybrid-access-01 (work in
progress), January 2015. progress), January 2015.
[I-D.lhwxz-hybrid-access-network-architecture] [I-D.lhwxz-hybrid-access-network-architecture]
Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M. Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.
Zhang, "Hybrid Access Network Architecture", Zhang, "Hybrid Access Network Architecture",
draft-lhwxz-hybrid-access-network-architecture-02 (work in draft-lhwxz-hybrid-access-network-architecture-02 (work in
skipping to change at page 29, line 51 skipping to change at page 28, line 37
behind Layer-4 loadbalancers", behind Layer-4 loadbalancers",
draft-paasch-mptcp-loadbalancer-00 (work in progress), draft-paasch-mptcp-loadbalancer-00 (work in progress),
September 2015. September 2015.
[I-D.paasch-mptcp-syncookies] [I-D.paasch-mptcp-syncookies]
Paasch, C., Biswas, A., and D. Haas, "Making Multipath TCP Paasch, C., Biswas, A., and D. Haas, "Making Multipath TCP
robust for stateless webservers", robust for stateless webservers",
draft-paasch-mptcp-syncookies-02 (work in progress), draft-paasch-mptcp-syncookies-02 (work in progress),
October 2015. October 2015.
[I-D.walid-mptcp-congestion-control]
Walid, A., Peng, Q., Hwang, J., and S. Low, "Balanced
Linked Adaptation Congestion Control Algorithm for MPTCP",
draft-walid-mptcp-congestion-control-04 (work in
progress), January 2016.
[I-D.wei-mptcp-proxy-mechanism]
Wei, X., Xiong, C., and E. Ed, "MPTCP proxy mechanisms",
draft-wei-mptcp-proxy-mechanism-02 (work in progress),
June 2015.
[ICNP12] Cao, Y., Xu, M., and X. Fu, "Delay-based congestion [ICNP12] Cao, Y., Xu, M., and X. Fu, "Delay-based congestion
control for multipath TCP", 20th IEEE International control for multipath TCP", 20th IEEE International
Conference on Network Protocols (ICNP) , 2012. Conference on Network Protocols (ICNP) , 2012.
[IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., [IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,
Handley, M., and H. Tokuda, "Is it still possible to Handley, M., and H. Tokuda, "Is it still possible to
extend TCP?", Proceedings of the 2011 ACM SIGCOMM extend TCP?", Proceedings of the 2011 ACM SIGCOMM
conference on Internet measurement conference (IMC '11) , conference on Internet measurement conference (IMC '11) ,
2011, <http://doi.acm.org/10.1145/2068816.2068834>. 2011, <http://doi.acm.org/10.1145/2068816.2068834>.
skipping to change at page 33, line 5 skipping to change at page 31, line 31
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>. <http://www.rfc-editor.org/info/rfc6824>.
[RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
Raiciu, "Analysis of Residual Threats and Possible Fixes Raiciu, "Analysis of Residual Threats and Possible Fixes
for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/ for Multipath TCP (MPTCP)", RFC 7430, DOI 10.17487/
RFC7430, July 2015, RFC7430, July 2015,
<http://www.rfc-editor.org/info/rfc7430>. <http://www.rfc-editor.org/info/rfc7430>.
[RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W.
Kumari, "Client Subnet in DNS Queries", RFC 7871,
DOI 10.17487/RFC7871, May 2016,
<http://www.rfc-editor.org/info/rfc7871>.
[SIGCOMM11] [SIGCOMM11]
Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A., Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A.,
Wischik, D., and M. Handley, "Improving datacenter Wischik, D., and M. Handley, "Improving datacenter
performance and robustness with multipath TCP", performance and robustness with multipath TCP",
Proceedings of the ACM SIGCOMM 2011 conference , n.d., Proceedings of the ACM SIGCOMM 2011 conference , n.d.,
<http://doi.acm.org/10.1145/2018436.2018467>. <http://doi.acm.org/10.1145/2018436.2018467>.
[StrangeMbox] [StrangeMbox]
Bonaventure, O., "Multipath TCP through a strange Bonaventure, O., "Multipath TCP through a strange
middlebox", Blog post , January 2015, <http:// middlebox", Blog post , January 2015, <http://
skipping to change at page 35, line 5 skipping to change at page 34, line 5
Section 3.12 Section 3.12
* Restructured text and improved writing in some parts * Restructured text and improved writing in some parts
o version ietf-04 : April 2016, answer to last comments o version ietf-04 : April 2016, answer to last comments
* Updated text on measurements with smartphones * Updated text on measurements with smartphones
* Updated conclusion * Updated conclusion
o version ietf-06 : August 2016, answer to AD's review
* removed some expired drafts
* removed conclusion
Authors' Addresses Authors' Addresses
Olivier Bonaventure Olivier Bonaventure
UCLouvain UCLouvain
Email: Olivier.Bonaventure@uclouvain.be Email: Olivier.Bonaventure@uclouvain.be
Christoph Paasch Christoph Paasch
Apple, Inc. Apple, Inc.
 End of changes. 32 change blocks. 
144 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/