draft-ietf-mptcp-experience-00.txt   draft-ietf-mptcp-experience-01.txt 
MPTCP Working Group O. Bonaventure MPTCP Working Group O. Bonaventure
Internet-Draft C. Paasch Internet-Draft C. Paasch
Intended status: Informational G. Detal Intended status: Informational UCLouvain
Expires: March 20, 2015 UCLouvain Expires: September 9, 2015 G. Detal
September 16, 2014 UCLouvain and Tessares
March 08, 2015
Experience with Multipath TCP Experience with Multipath TCP
draft-ietf-mptcp-experience-00 draft-ietf-mptcp-experience-01
Abstract Abstract
This document discusses operational experiences of using Multipath This document discusses operational experiences of using Multipath
TCP in real world networks. It lists several prominent use cases for TCP in real world networks. It lists several prominent use cases for
which Multipath TCP has been considered and is being used. It also which Multipath TCP has been considered and is being used. It also
gives insight in some heuristics and decisions that have helped to gives insight in some heuristics and decisions that have helped to
realize these use cases. Further, it presents several open issues realize these use cases. Further, it presents several open issues
that are yet unclear on how they can be solved. that are yet unclear on how they can be solved.
skipping to change at page 1, line 36 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 March 20, 2015. This Internet-Draft will expire on September 9, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 24 skipping to change at page 2, line 25
5.1. Implemented subflow managers . . . . . . . . . . . . . . 9 5.1. Implemented subflow managers . . . . . . . . . . . . . . 9
5.2. Subflow destination port . . . . . . . . . . . . . . . . 11 5.2. Subflow destination port . . . . . . . . . . . . . . . . 11
5.3. Closing subflows . . . . . . . . . . . . . . . . . . . . 12 5.3. Closing subflows . . . . . . . . . . . . . . . . . . . . 12
6. Packet schedulers . . . . . . . . . . . . . . . . . . . . . . 13 6. Packet schedulers . . . . . . . . . . . . . . . . . . . . . . 13
7. Segment size selection . . . . . . . . . . . . . . . . . . . 14 7. Segment size selection . . . . . . . . . . . . . . . . . . . 14
8. Interactions with the Domain Name System . . . . . . . . . . 15 8. Interactions with the Domain Name System . . . . . . . . . . 15
9. Captive portals . . . . . . . . . . . . . . . . . . . . . . . 15 9. Captive portals . . . . . . . . . . . . . . . . . . . . . . . 15
10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . 16 13. Informative References . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Multipath TCP was standardized in [RFC6824] and four implementations Multipath TCP was standardized in [RFC6824] and four implementations
have been developed [I-D.eardley-mptcp-implementations-survey]. have been developed [I-D.eardley-mptcp-implementations-survey].
Since the publication of [RFC6824], some experience has been gathered Since the publication of [RFC6824], some experience has been gathered
by various network researchers and users about the issues that arise by various network researchers and users about the issues that arise
when Multipath TCP is used in the Internet. when Multipath TCP is used in the Internet.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
(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. tracebox
includes a scripting language that enables its user to specify includes a scripting language that enables its user to specify
precisely which packet is sent by the source. tracebox sends packets precisely which packet is sent by the source. tracebox sends packets
with an increasing TTL/HopLimit and compares the information returned with an increasing TTL/HopLimit and compares the information returned
in the ICMP messages with the packet that it sends. This enables in the ICMP messages with the packet that it sends. This enables
tracebox to detect any interference caused by middleboxes on a given tracebox to detect any interference caused by middleboxes on a given
path. tracebox works better when routers implement the ICMP extension path. tracebox works better when routers implement the ICMP extension
defined in [RFC1812]. defined in [RFC1812].
Users of the Multipath TCP implementation have reported some
experience with middlebox interference. The strangest scenario has
been a middlebox that accepts the Multipath TCP options in the SYN
segment but later replaces Multipath TCP options with a TCP EOL
option [StrangeMbox]. This causes Multipath TCP to perform a
fallback to regular TCP without any impact on the application.
3. Use cases 3. Use cases
Multipath TCP has been tested in several use cases. Several of the Multipath TCP has been tested in several use cases. Several of the
papers published in the scientific litterature have identified papers published in the scientific litterature have identified
possible improvements that are worth being discussed here. possible improvements that are worth being discussed here.
A first, although initially unexpected, documented use case for A first, although initially unexpected, documented use case for
Multipath TCP has been the datacenters [HotNets][SIGCOMM11]. Today's Multipath TCP has been the datacenters [HotNets][SIGCOMM11]. Today's
datacenters are designed to provide several paths between single- datacenters are designed to provide several paths between single-
homed servers. The multiplicity of these paths comes from the homed servers. The multiplicity of these paths comes from the
skipping to change at page 5, line 15 skipping to change at page 5, line 23
connection will follow the same path to prevent packet reordering. connection will follow the same path to prevent packet reordering.
The results presented in [HotNets] demonstrate by simulations that The results presented in [HotNets] demonstrate by simulations that
Multipath TCP can achieve a better utilization of the available Multipath TCP can achieve a better utilization of the available
network by using multiple subflows for each Multipath TCP session. network by using multiple subflows for each Multipath TCP session.
Although [RFC6182] assumes that at least one of the communicating Although [RFC6182] assumes that at least one of the communicating
hosts has several IP addresses, [HotNets] demonstrates that there are hosts has several IP addresses, [HotNets] demonstrates that there are
also benefits when both hosts are single-homed. This idea was also benefits when both hosts are single-homed. This idea was
pursued further in [SIGCOMM11] where the Multipath TCP implementation pursued further in [SIGCOMM11] where the Multipath TCP implementation
in the Linux kernel was modified to be able to use several subflows in the Linux kernel was modified to be able to use several subflows
from the same IP address. Measurements performed in a public from the same IP address. Measurements performed in a public
datacenter showed performance improvements with Multipath TCP. datacenter showed performance improvements with Multipath TCP
[SIGCOMM11].
Although ECMP is widely used inside datacenters, this is not the only Although ECMP is widely used inside datacenters, this is not the only
environment where there are different paths between a pair of hosts. environment where there are different paths between a pair of hosts.
ECMP and other load balancing techniques such as LAG are widely used ECMP and other load balancing techniques such as LAG are widely used
in today's network and having multiple paths between a pair of in today's network and having multiple paths between a pair of
single-homed hosts is becoming the norm instead of the exception. single-homed hosts is becoming the norm instead of the exception.
Although these multiple paths have often the same cost (from an IGP Although these multiple paths have often the same cost (from an IGP
metrics viewpoint), they do not necessarily have the same metrics viewpoint), they do not necessarily have the same
performance. For example, [IMC13c] reports the results of a long performance. For example, [IMC13c] reports the results of a long
measurement study showing that load balanced Internet paths between measurement study showing that load balanced Internet paths between
skipping to change at page 8, line 48 skipping to change at page 9, line 7
added. The second congestion control scheme is OLIA [CONEXT12]. added. The second congestion control scheme is OLIA [CONEXT12].
This congestion control scheme is also an adaptation of the NewReno This congestion control scheme is also an adaptation of the NewReno
single path congestion control scheme to support multiple paths. 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]. Measurement over a wide range of parameters scheme [CONEXT12]. Measurement 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]. As of this writing, it has not yet by using simulations in [ICNP12].
been evaluated by performing large measurement campaigns.
5. Subflow management 5. Subflow management
The multipath capability of Multipath TCP comes from the utilization The multipath capability of Multipath TCP comes from the utilization
of one subflow per path. The Multipath TCP architecture [RFC6182] of one subflow per path. The Multipath TCP architecture [RFC6182]
and the protocol specification [RFC6824] define the basic usage of and the protocol specification [RFC6824] define the basic usage of
the subflows and the protocol mechanisms that are required to create the subflows and the protocol mechanisms that are required to create
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
experiments with Multipath TCP have been performed in controlled experiments with Multipath TCP have been performed in controlled
skipping to change at page 16, line 39 skipping to change at page 16, line 41
users of the Multipath TCP implementation in the Linux kernel. users of the Multipath TCP implementation in the Linux kernel.
11. Acknowledgements 11. 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. TCP implementation in the Linux kernel.
12. Changelog 12. Changelog
o initial version : o initial version : September 16th, 2014 : Added section Section 7
that discusses some performance problems that appeared with the
Linux implementation when using subflows having different MSS
values
o update with a description of the middlebox that replaces an
unknown TCP option with EOL [StrangeMbox]
13. Informative References 13. Informative References
[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>.
[CONEXT12] [CONEXT12]
Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J. Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J.
Leboudec, "MPTCP is not pareto-optimal performance issues Leboudec, "MPTCP is not pareto-optimal performance issues
skipping to change at page 20, line 12 skipping to change at page 20, line 16
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013. Addresses", RFC 6824, January 2013.
[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]
Bonaventure, O., "Multipath TCP through a strange
middlebox", Blog post , January 2015,
<http://blog.multipath-tcp.org/blog/html/2015/01/30/
multipath_tcp_through_a_strange_middlebox.html>.
[TNC13] van der Pol, R., Bredel, M., and A. Barczyk, "Experiences [TNC13] van der Pol, R., Bredel, M., and A. Barczyk, "Experiences
with MPTCP in an intercontinental multipathed OpenFlow with MPTCP in an intercontinental multipathed OpenFlow
network", TNC2013 , 2013. network", TNC2013 , 2013.
[tracebox] [tracebox]
Detal, G., "tracebox", 2013, <http://www.tracebox.org>. Detal, G., "tracebox", 2013, <http://www.tracebox.org>.
Authors' Addresses Authors' Addresses
Olivier Bonaventure Olivier Bonaventure
UCLouvain UCLouvain
Email: Olivier.Bonaventure@uclouvain.be Email: Olivier.Bonaventure@uclouvain.be
Christoph Paasch Christoph Paasch
UCLouvain UCLouvain
Email: Christoph.Paasch@uclouvain.be Email: Christoph.Paasch@uclouvain.be
Gregory Detal Gregory Detal
UCLouvain UCLouvain and Tessares
Email: Gregory.Detal@uclouvain.be Email: Gregory.Detal@tessares.net
 End of changes. 12 change blocks. 
12 lines changed or deleted 32 lines changed or added

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