One document matched: draft-ietf-mptcp-experience-04.ps
%!PS-Adobe-3.0
%%BoundingBox: 24 24 571 818
%%Title: Enscript Output
%%For: Christoph Paasch
%%Creator: GNU Enscript 1.6.6
%%CreationDate: Mon Apr 4 11:04:46 2016
%%Orientation: Portrait
%%Pages: (atend)
%%DocumentMedia: A4 595 842 0 () ()
%%DocumentNeededResources: (atend)
%%EndComments
%%BeginProlog
%%BeginResource: procset Enscript-Prolog 1.6 6
%
% Procedures.
%
/_S { % save current state
/_s save def
} def
/_R { % restore from saved state
_s restore
} def
/S { % showpage protecting gstate
gsave
showpage
grestore
} bind def
/MF { % fontname newfontname -> - make a new encoded font
/newfontname exch def
/fontname exch def
/fontdict fontname findfont def
/newfont fontdict maxlength dict def
fontdict {
exch
dup /FID eq {
% skip FID pair
pop pop
} {
% copy to the new font dictionary
exch newfont 3 1 roll put
} ifelse
} forall
newfont /FontName newfontname put
% insert only valid encoding vectors
encoding_vector length 256 eq {
newfont /Encoding encoding_vector put
} if
newfontname newfont definefont pop
} def
/MF_PS { % fontname newfontname -> - make a new font preserving its enc
/newfontname exch def
/fontname exch def
/fontdict fontname findfont def
/newfont fontdict maxlength dict def
fontdict {
exch
dup /FID eq {
% skip FID pair
pop pop
} {
% copy to the new font dictionary
exch newfont 3 1 roll put
} ifelse
} forall
newfont /FontName newfontname put
newfontname newfont definefont pop
} def
/SF { % fontname width height -> - set a new font
/height exch def
/width exch def
findfont
[width 0 0 height 0 0] makefont setfont
} def
/SUF { % fontname width height -> - set a new user font
/height exch def
/width exch def
/F-gs-user-font MF
/F-gs-user-font width height SF
} def
/SUF_PS { % fontname width height -> - set a new user font preserving its enc
/height exch def
/width exch def
/F-gs-user-font MF_PS
/F-gs-user-font width height SF
} def
/M {moveto} bind def
/s {show} bind def
/Box { % x y w h -> - define box path
/d_h exch def /d_w exch def /d_y exch def /d_x exch def
d_x d_y moveto
d_w 0 rlineto
0 d_h rlineto
d_w neg 0 rlineto
closepath
} def
/bgs { % x y height blskip gray str -> - show string with bg color
/str exch def
/gray exch def
/blskip exch def
/height exch def
/y exch def
/x exch def
gsave
x y blskip sub str stringwidth pop height Box
gray setgray
fill
grestore
x y M str s
} def
/bgcs { % x y height blskip red green blue str -> - show string with bg color
/str exch def
/blue exch def
/green exch def
/red exch def
/blskip exch def
/height exch def
/y exch def
/x exch def
gsave
x y blskip sub str stringwidth pop height Box
red green blue setrgbcolor
fill
grestore
x y M str s
} def
% Highlight bars.
/highlight_bars { % nlines lineheight output_y_margin gray -> -
gsave
setgray
/ymarg exch def
/lineheight exch def
/nlines exch def
% This 2 is just a magic number to sync highlight lines to text.
0 d_header_y ymarg sub 2 sub translate
/cw d_output_w cols div def
/nrows d_output_h ymarg 2 mul sub lineheight div cvi def
% for each column
0 1 cols 1 sub {
cw mul /xp exch def
% for each rows
0 1 nrows 1 sub {
/rn exch def
rn lineheight mul neg /yp exch def
rn nlines idiv 2 mod 0 eq {
% Draw highlight bar. 4 is just a magic indentation.
xp 4 add yp cw 8 sub lineheight neg Box fill
} if
} for
} for
grestore
} def
% Line highlight bar.
/line_highlight { % x y width height gray -> -
gsave
/gray exch def
Box gray setgray fill
grestore
} def
% Column separator lines.
/column_lines {
gsave
.1 setlinewidth
0 d_footer_h translate
/cw d_output_w cols div def
1 1 cols 1 sub {
cw mul 0 moveto
0 d_output_h rlineto stroke
} for
grestore
} def
% Column borders.
/column_borders {
gsave
.1 setlinewidth
0 d_footer_h moveto
0 d_output_h rlineto
d_output_w 0 rlineto
0 d_output_h neg rlineto
closepath stroke
grestore
} def
% Do the actual underlay drawing
/draw_underlay {
ul_style 0 eq {
ul_str true charpath stroke
} {
ul_str show
} ifelse
} def
% Underlay
/underlay { % - -> -
gsave
0 d_page_h translate
d_page_h neg d_page_w atan rotate
ul_gray setgray
ul_font setfont
/dw d_page_h dup mul d_page_w dup mul add sqrt def
ul_str stringwidth pop dw exch sub 2 div ul_h_ptsize -2 div moveto
draw_underlay
grestore
} def
/user_underlay { % - -> -
gsave
ul_x ul_y translate
ul_angle rotate
ul_gray setgray
ul_font setfont
0 0 ul_h_ptsize 2 div sub moveto
draw_underlay
grestore
} def
% Page prefeed
/page_prefeed { % bool -> -
statusdict /prefeed known {
statusdict exch /prefeed exch put
} {
pop
} ifelse
} def
% Wrapped line markers
/wrapped_line_mark { % x y charwith charheight type -> -
/type exch def
/h exch def
/w exch def
/y exch def
/x exch def
type 2 eq {
% Black boxes (like TeX does)
gsave
0 setlinewidth
x w 4 div add y M
0 h rlineto w 2 div 0 rlineto 0 h neg rlineto
closepath fill
grestore
} {
type 3 eq {
% Small arrows
gsave
.2 setlinewidth
x w 2 div add y h 2 div add M
w 4 div 0 rlineto
x w 4 div add y lineto stroke
x w 4 div add w 8 div add y h 4 div add M
x w 4 div add y lineto
w 4 div h 8 div rlineto stroke
grestore
} {
% do nothing
} ifelse
} ifelse
} def
% EPSF import.
/BeginEPSF {
/b4_Inc_state save def % Save state for cleanup
/dict_count countdictstack def % Count objects on dict stack
/op_count count 1 sub def % Count objects on operand stack
userdict begin
/showpage { } def
0 setgray 0 setlinecap
1 setlinewidth 0 setlinejoin
10 setmiterlimit [ ] 0 setdash newpath
/languagelevel where {
pop languagelevel
1 ne {
false setstrokeadjust false setoverprint
} if
} if
} bind def
/EndEPSF {
count op_count sub { pos } repeat % Clean up stacks
countdictstack dict_count sub { end } repeat
b4_Inc_state restore
} bind def
% Check PostScript language level.
/languagelevel where {
pop /gs_languagelevel languagelevel def
} {
/gs_languagelevel 1 def
} ifelse
%%EndResource
%%BeginResource: procset Enscript-Encoding-88591 1.6 6
/encoding_vector [
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/space /exclam /quotedbl /numbersign
/dollar /percent /ampersand /quoteright
/parenleft /parenright /asterisk /plus
/comma /hyphen /period /slash
/zero /one /two /three
/four /five /six /seven
/eight /nine /colon /semicolon
/less /equal /greater /question
/at /A /B /C
/D /E /F /G
/H /I /J /K
/L /M /N /O
/P /Q /R /S
/T /U /V /W
/X /Y /Z /bracketleft
/backslash /bracketright /asciicircum /underscore
/quoteleft /a /b /c
/d /e /f /g
/h /i /j /k
/l /m /n /o
/p /q /r /s
/t /u /v /w
/x /y /z /braceleft
/bar /braceright /tilde /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/.notdef /.notdef /.notdef /.notdef
/space /exclamdown /cent /sterling
/currency /yen /brokenbar /section
/dieresis /copyright /ordfeminine /guillemotleft
/logicalnot /hyphen /registered /macron
/degree /plusminus /twosuperior /threesuperior
/acute /mu /paragraph /bullet
/cedilla /onesuperior /ordmasculine /guillemotright
/onequarter /onehalf /threequarters /questiondown
/Agrave /Aacute /Acircumflex /Atilde
/Adieresis /Aring /AE /Ccedilla
/Egrave /Eacute /Ecircumflex /Edieresis
/Igrave /Iacute /Icircumflex /Idieresis
/Eth /Ntilde /Ograve /Oacute
/Ocircumflex /Otilde /Odieresis /multiply
/Oslash /Ugrave /Uacute /Ucircumflex
/Udieresis /Yacute /Thorn /germandbls
/agrave /aacute /acircumflex /atilde
/adieresis /aring /ae /ccedilla
/egrave /eacute /ecircumflex /edieresis
/igrave /iacute /icircumflex /idieresis
/eth /ntilde /ograve /oacute
/ocircumflex /otilde /odieresis /divide
/oslash /ugrave /uacute /ucircumflex
/udieresis /yacute /thorn /ydieresis
] def
%%EndResource
%%EndProlog
%%BeginSetup
%%IncludeResource: font Courier-Bold
%%IncludeResource: font Courier
/HFpt_w 10 def
/HFpt_h 10 def
/Courier-Bold /HF-gs-font MF
/HF /HF-gs-font findfont [HFpt_w 0 0 HFpt_h 0 0] makefont def
/Courier /F-gs-font MF
/F-gs-font 10 10 SF
/#copies 1 def
% Pagedevice definitions:
gs_languagelevel 1 gt {
<<
/PageSize [595 842]
>> setpagedevice
} if
/d_page_w 547 def
/d_page_h 794 def
/d_header_x 0 def
/d_header_y 794 def
/d_header_w 547 def
/d_header_h 0 def
/d_footer_x 0 def
/d_footer_y 0 def
/d_footer_w 547 def
/d_footer_h 0 def
/d_output_w 547 def
/d_output_h 794 def
/cols 1 def
%%EndSetup
%%Page: (1) 1
%%BeginPageSetup
_S
24 24 translate
/pagenum 1 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 737 M
(MPTCP Working Group O. Bonaventure) s
5 726 M
(Internet-Draft UCLouvain) s
5 715 M
(Intended status: Informational C. Paasch) s
5 704 M
(Expires: October 3, 2016 Apple, Inc.) s
5 693 M
( G. Detal) s
5 682 M
( Tessares) s
5 671 M
( April 01, 2016) s
5 638 M
( Use Cases and Operational Experience with Multipath TCP) s
5 627 M
( draft-ietf-mptcp-experience-04) s
5 605 M
(Abstract) s
5 583 M
( This document discusses both use cases and operational experience) s
5 572 M
( with Multipath TCP in real world networks. It lists several) s
5 561 M
( prominent use cases for which Multipath TCP has been considered and) s
5 550 M
( is being used. It also gives insight to some heuristics and) s
5 539 M
( decisions that have helped to realize these use cases.) s
5 517 M
(Status of This Memo) s
5 495 M
( This Internet-Draft is submitted in full conformance with the) s
5 484 M
( provisions of BCP 78 and BCP 79.) s
5 462 M
( Internet-Drafts are working documents of the Internet Engineering) s
5 451 M
( Task Force \(IETF\). Note that other groups may also distribute) s
5 440 M
( working documents as Internet-Drafts. The list of current Internet-) s
5 429 M
( Drafts is at http://datatracker.ietf.org/drafts/current/.) s
5 407 M
( Internet-Drafts are draft documents valid for a maximum of six months) s
5 396 M
( and may be updated, replaced, or obsoleted by other documents at any) s
5 385 M
( time. It is inappropriate to use Internet-Drafts as reference) s
5 374 M
( material or to cite them other than as "work in progress.") s
5 352 M
( This Internet-Draft will expire on October 3, 2016.) s
5 330 M
(Copyright Notice) s
5 308 M
( Copyright \(c\) 2016 IETF Trust and the persons identified as the) s
5 297 M
( document authors. All rights reserved.) s
5 275 M
( This document is subject to BCP 78 and the IETF Trust's Legal) s
5 264 M
( Provisions Relating to IETF Documents) s
5 253 M
( \(http://trustee.ietf.org/license-info\) in effect on the date of) s
5 242 M
( publication of this document. Please review these documents) s
5 231 M
( carefully, as they describe your rights and restrictions with respect) s
5 220 M
( to this document. Code Components extracted from this document must) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 1]) s
_R
S
%%Page: (2) 2
%%BeginPageSetup
_S
24 24 translate
/pagenum 2 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( include Simplified BSD License text as described in Section 4.e of) s
5 726 M
( the Trust Legal Provisions and are provided without warranty as) s
5 715 M
( described in the Simplified BSD License.) s
5 693 M
(Table of Contents) s
5 671 M
( 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2) s
5 660 M
( 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4) s
5 649 M
( 2.1. Datacenters . . . . . . . . . . . . . . . . . . . . . . . 4) s
5 638 M
( 2.2. Cellular/WiFi Offload . . . . . . . . . . . . . . . . . . 5) s
5 627 M
( 2.3. Multipath TCP proxies . . . . . . . . . . . . . . . . . . 8) s
5 616 M
( 3. Operational Experience . . . . . . . . . . . . . . . . . . . 9) s
5 605 M
( 3.1. Middlebox interference . . . . . . . . . . . . . . . . . 9) s
5 594 M
( 3.2. Congestion control . . . . . . . . . . . . . . . . . . . 11) s
5 583 M
( 3.3. Subflow management . . . . . . . . . . . . . . . . . . . 12) s
5 572 M
( 3.4. Implemented subflow managers . . . . . . . . . . . . . . 12) s
5 561 M
( 3.5. Subflow destination port . . . . . . . . . . . . . . . . 14) s
5 550 M
( 3.6. Closing subflows . . . . . . . . . . . . . . . . . . . . 15) s
5 539 M
( 3.7. Packet schedulers . . . . . . . . . . . . . . . . . . . . 17) s
5 528 M
( 3.8. Segment size selection . . . . . . . . . . . . . . . . . 17) s
5 517 M
( 3.9. Interactions with the Domain Name System . . . . . . . . 18) s
5 506 M
( 3.10. Captive portals . . . . . . . . . . . . . . . . . . . . . 19) s
5 495 M
( 3.11. Stateless webservers . . . . . . . . . . . . . . . . . . 20) s
5 484 M
( 3.12. Loadbalanced serverfarms . . . . . . . . . . . . . . . . 20) s
5 473 M
( 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 21) s
5 462 M
( 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21) s
5 451 M
( 6. Informative References . . . . . . . . . . . . . . . . . . . 22) s
5 440 M
( Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 28) s
5 429 M
( Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29) s
5 407 M
(1. Introduction) s
5 385 M
( Multipath TCP was standardized in [RFC6824] and five independant) s
5 374 M
( implementations have been developed) s
5 363 M
( [I-D.eardley-mptcp-implementations-survey]. As of September 2015,) s
5 352 M
( Multipath TCP has been or is being implemented on the following) s
5 341 M
( platforms :) s
5 319 M
( o Linux kernel [MultipathTCP-Linux]) s
5 297 M
( o Apple iOS and MacOS [Apple-MPTCP]) s
5 275 M
( o Citrix load balancers) s
5 253 M
( o FreeBSD [FreeBSD-MPTCP]) s
5 231 M
( o Oracle) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 2]) s
_R
S
%%Page: (3) 3
%%BeginPageSetup
_S
24 24 translate
/pagenum 3 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( The first three implementations) s
5 726 M
( [I-D.eardley-mptcp-implementations-survey] are known to interoperate.) s
5 715 M
( The last two are currently being tested and improved against the) s
5 704 M
( Linux implementation. Three of these implementations are open-) s
5 693 M
( source. Apple's implementation is widely deployed.) s
5 671 M
( Since the publication of [RFC6824], experience has been gathered by) s
5 660 M
( various network researchers and users about the operational issues) s
5 649 M
( that arise when Multipath TCP is used in today's Internet.) s
5 627 M
( When the MPTCP working group was created, several use cases for) s
5 616 M
( Multipath TCP were identified [RFC6182]. Since then, other use cases) s
5 605 M
( have been proposed and some have been tested and even deployed. We) s
5 594 M
( describe these use cases in Section 2.) s
5 572 M
( Section 3 focuses on the operational experience with Multipath TCP.) s
5 561 M
( Most of this experience comes from the utilisation of the Multipath) s
5 550 M
( TCP implementation in the Linux kernel [MultipathTCP-Linux]. This) s
5 539 M
( open-source implementation has been downloaded and is used by) s
5 528 M
( thousands of users all over the world. Many of these users have) s
5 517 M
( provided direct or indirect feedback by writing documents \(scientific) s
5 506 M
( articles or blog messages\) or posting to the mptcp-dev mailing list) s
5 495 M
( \(see https://listes-2.sipr.ucl.ac.be/sympa/arc/mptcp-dev \). This) s
5 484 M
( Multipath TCP implementation is actively maintained and continuously) s
5 473 M
( improved. It is used on various types of hosts, ranging from) s
5 462 M
( smartphones or embedded routers to high-end servers.) s
5 440 M
( The Multipath TCP implementation in the Linux kernel is not, by far,) s
5 429 M
( the most widespread deployment of Multipath TCP. Since September) s
5 418 M
( 2013, Multipath TCP is also supported on smartphones and tablets) s
5 407 M
( running iOS7 [IOS7]. There are likely hundreds of millions of) s
5 396 M
( Multipath TCP enabled devices. However, this particular Multipath) s
5 385 M
( TCP implementation is currently only used to support a single) s
5 374 M
( application. Unfortunately, there is no public information about the) s
5 363 M
( lessons learned from this large scale deployment.) s
5 341 M
( Section 3 is organized as follows. Supporting the middleboxes was) s
5 330 M
( one of the difficult issues in designing the Multipath TCP protocol.) s
5 319 M
( We explain in Section 3.1 which types of middleboxes the Linux Kernel) s
5 308 M
( implementation of Multipath TCP supports and how it reacts upon) s
5 297 M
( encountering these. Section 3.2 summarises the MPTCP specific) s
5 286 M
( congestion controls that have been implemented. Section 3.3 and) s
5 275 M
( Section 3.7 discuss heuristics and issues with respect to subflow) s
5 264 M
( management as well as the scheduling across the subflows.) s
5 253 M
( Section 3.8 explains some problems that occurred with subflows having) s
5 242 M
( different Maximum Segment Size \(MSS\) values. Section 3.9 presents) s
5 231 M
( issues with respect to content delivery networks and suggests a) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 3]) s
_R
S
%%Page: (4) 4
%%BeginPageSetup
_S
24 24 translate
/pagenum 4 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( solution to this issue. Finally, Section 3.10 documents an issue) s
5 726 M
( with captive portals where MPTCP will behave suboptimally.) s
5 704 M
(2. Use cases) s
5 682 M
( Multipath TCP has been tested in several use cases. There is already) s
5 671 M
( an abundant scientific literature on Multipath TCP [MPTCPBIB].) s
5 660 M
( Several of the papers published in the scientific literature have) s
5 649 M
( identified possible improvements that are worth being discussed here.) s
5 627 M
(2.1. Datacenters) s
5 605 M
( A first, although initially unexpected, documented use case for) s
5 594 M
( Multipath TCP has been in datacenters [HotNets][SIGCOMM11]. Today's) s
5 583 M
( datacenters are designed to provide several paths between single-) s
5 572 M
( homed servers. The multiplicity of these paths comes from the) s
5 561 M
( utilization of Equal Cost Multipath \(ECMP\) and other load balancing) s
5 550 M
( techniques inside the datacenter. Most of the deployed load) s
5 539 M
( balancing techniques in datacenters rely on hashes computed over the) s
5 528 M
( five tuple. Thus all packets from the same TCP connection follow the) s
5 517 M
( same path and so are not reordered. The results in [HotNets]) s
5 506 M
( demonstrate by simulations that Multipath TCP can achieve a better) s
5 495 M
( utilization of the available network by using multiple subflows for) s
5 484 M
( each Multipath TCP session. Although [RFC6182] assumes that at least) s
5 473 M
( one of the communicating hosts has several IP addresses, [HotNets]) s
5 462 M
( demonstrates that Multipath TCP is beneficial when both hosts are) s
5 451 M
( single-homed. This idea is analysed in more details in [SIGCOMM11]) s
5 440 M
( where the Multipath TCP implementation in the Linux kernel is) s
5 429 M
( modified to be able to use several subflows from the same IP address.) s
5 418 M
( Measurements in a public datacenter show the quantitative benefits of) s
5 407 M
( Multipath TCP [SIGCOMM11] in this environment.) s
5 385 M
( Although ECMP is widely used inside datacenters, this is not the only) s
5 374 M
( environment where there are different paths between a pair of hosts.) s
5 363 M
( ECMP and other load balancing techniques such as Link Aggregation) s
5 352 M
( Groups \(LAG\) are widely used in today's networks and having multiple) s
5 341 M
( paths between a pair of single-homed hosts is becoming the norm) s
5 330 M
( instead of the exception. Although these multiple paths have often) s
5 319 M
( the same cost \(from an IGP metrics viewpoint\), they do not) s
5 308 M
( necessarily have the same performance. For example, [IMC13c] reports) s
5 297 M
( the results of a long measurement study showing that load balanced) s
5 286 M
( Internet paths between that same pair of hosts can have huge delay) s
5 275 M
( differences.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 4]) s
_R
S
%%Page: (5) 5
%%BeginPageSetup
_S
24 24 translate
/pagenum 5 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
(2.2. Cellular/WiFi Offload) s
5 715 M
( A second use case that has been explored by several network) s
5 704 M
( researchers is the cellular/WiFi offload use case. Smartphones or) s
5 693 M
( other mobile devices equipped with two wireless interfaces are a very) s
5 682 M
( common use case for Multipath TCP. In September 2015, this is also) s
5 671 M
( the largest deployment of Multipath-TCP enabled devices [IOS7]. It) s
5 660 M
( has been briefly discussed during IETF88 [ietf88], but there is no) s
5 649 M
( published paper or report that analyses this deployment. For this) s
5 638 M
( reason, we only discuss published papers that have mainly used the) s
5 627 M
( Multipath TCP implementation in the Linux kernel for their) s
5 616 M
( experiments.) s
5 594 M
( The performance of Multipath TCP in wireless networks was briefly) s
5 583 M
( evaluated in [NSDI12]. One experiment analyzes the performance of) s
5 572 M
( Multipath TCP on a client with two wireless interfaces. This) s
5 561 M
( evaluation shows that when the receive window is large, Multipath TCP) s
5 550 M
( can efficiently use the two available links. However, if the window) s
5 539 M
( becomes smaller, then packets sent on a slow path can block the) s
5 528 M
( transmission of packets on a faster path. In some cases, the) s
5 517 M
( performance of Multipath TCP over two paths can become lower than the) s
5 506 M
( performance of regular TCP over the best performing path. Two) s
5 495 M
( heuristics, reinjection and penalization, are proposed in [NSDI12] to) s
5 484 M
( solve this identified performance problem. These two heuristics have) s
5 473 M
( since been used in the Multipath TCP implementation in the Linux) s
5 462 M
( kernel. [CONEXT13] explored the problem in more detail and revealed) s
5 451 M
( some other scenarios where Multipath TCP can have difficulties in) s
5 440 M
( efficiently pooling the available paths. Improvements to the) s
5 429 M
( Multipath TCP implementation in the Linux kernel are proposed in) s
5 418 M
( [CONEXT13] to cope with some of these problems.) s
5 396 M
( The first experimental analysis of Multipath TCP in a public wireless) s
5 385 M
( environment was presented in [Cellnet12]. These measurements explore) s
5 374 M
( the ability of Multipath TCP to use two wireless networks \(real WiFi) s
5 363 M
( and 3G networks\). Three modes of operation are compared. The first) s
5 352 M
( mode of operation is the simultaneous use of the two wireless) s
5 341 M
( networks. In this mode, Multipath TCP pools the available resources) s
5 330 M
( and uses both wireless interfaces. This mode provides fast handover) s
5 319 M
( from WiFi to cellular or the opposite when the user moves.) s
5 308 M
( Measurements presented in [CACM14] show that the handover from one) s
5 297 M
( wireless network to another is not an abrupt process. When a host) s
5 286 M
( moves, there are regions where the quality of one of the wireless) s
5 275 M
( networks is weaker than the other, but the host considers this) s
5 264 M
( wireless network to still be up. When a mobile host enters such) s
5 253 M
( regions, its ability to send packets over another wireless network is) s
5 242 M
( important to ensure a smooth handover. This is clearly illustrated) s
5 231 M
( from the packet trace discussed in [CACM14].) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 5]) s
_R
S
%%Page: (6) 6
%%BeginPageSetup
_S
24 24 translate
/pagenum 6 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( Many cellular networks use volume-based pricing and users often) s
5 726 M
( prefer to use unmetered WiFi networks when available instead of) s
5 715 M
( metered cellular networks. [Cellnet12] implements support for the) s
5 704 M
( MP_PRIO option to explore two other modes of operation.) s
5 682 M
( In the backup mode, Multipath TCP opens a TCP subflow over each) s
5 671 M
( interface, but the cellular interface is configured in backup mode.) s
5 660 M
( This implies that data only flows over only the WiFi interface when) s
5 649 M
( both interfaces are considered to be active. If the WiFi interface) s
5 638 M
( fails, then the traffic switches quickly to the cellular interface,) s
5 627 M
( ensuring a smooth handover from the user's viewpoint [Cellnet12].) s
5 616 M
( The cost of this approach is that the WiFi and cellular interfaces) s
5 605 M
( are likely to remain active all the time since all subflows are) s
5 594 M
( established over the two interfaces.) s
5 572 M
( The single-path mode is slightly different. This mode benefits from) s
5 561 M
( the break-before-make capability of Multipath TCP. When an MPTCP) s
5 550 M
( session is established, a subflow is created over the WiFi interface.) s
5 539 M
( No packet is sent over the cellular interface as long as the WiFi) s
5 528 M
( interface remains up [Cellnet12]. This implies that the cellular) s
5 517 M
( interface can remain idle and battery capacity is preserved. When) s
5 506 M
( the WiFi interface fails, a new subflow is established over the) s
5 495 M
( cellular interface in order to preserve the established Multipath TCP) s
5 484 M
( sessions. Compared to the backup mode described earlier,) s
5 473 M
( measurements reported in [Cellnet12] indicate that this mode of) s
5 462 M
( operation is characterised by a throughput drop while the cellular) s
5 451 M
( interface is brought up and the subflows are reestablished.) s
5 429 M
( From a protocol viewpoint, [Cellnet12] discusses the problem posed by) s
5 418 M
( the unreliability of the ADD_ADDR option and proposes a small) s
5 407 M
( protocol extension to allow hosts to reliably exchange this option.) s
5 396 M
( It would be useful to analyze packet traces to understand whether the) s
5 385 M
( unreliability of the REMOVE_ADDR option poses an operational problem) s
5 374 M
( in real deployments.) s
5 352 M
( Another study of the performance of Multipath TCP in wireless) s
5 341 M
( networks was reported in [IMC13b]. This study uses laptops connected) s
5 330 M
( to various cellular ISPs and WiFi hotspots. It compares various file) s
5 319 M
( transfer scenarios. [IMC13b] observes that 4-path MPTCP outperforms) s
5 308 M
( 2-path MPTCP, especially for larger files. The comparison between) s
5 297 M
( LIA, OLIA and Reno does not reveal a significant performance) s
5 286 M
( difference for file sizes smaller than 4MB.) s
5 264 M
( A different study of the performance of Multipath TCP with two) s
5 253 M
( wireless networks is presented in [INFOCOM14]. In this study the two) s
5 242 M
( networks had different qualities : a good network and a lossy) s
5 231 M
( network. When using two paths with different packet loss ratios, the) s
5 220 M
( Multipath TCP congestion control scheme moves traffic away from the) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 6]) s
_R
S
%%Page: (7) 7
%%BeginPageSetup
_S
24 24 translate
/pagenum 7 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( lossy link that is considered to be congested. However, [INFOCOM14]) s
5 726 M
( documents an interesting scenario that is summarised in Figure 1.) s
5 704 M
( client ----------- path1 -------- server) s
5 693 M
( | |) s
5 682 M
( +--------------- path2 ------------+) s
5 649 M
( Figure 1: Simple network topology) s
5 627 M
( Initially, the two paths have the same quality and Multipath TCP) s
5 616 M
( distributes the load over both of them. During the transfer, the) s
5 605 M
( second path becomes lossy, e.g. because the client moves. Multipath) s
5 594 M
( TCP detects the packet losses and they are retransmitted over the) s
5 583 M
( first path. This enables the data transfer to continue over the) s
5 572 M
( first path. However, the subflow over the second path is still up) s
5 561 M
( and transmits one packet from time to time. Although the N packets) s
5 550 M
( have been acknowledged over the first subflow \(at the MPTCP level\),) s
5 539 M
( they have not been acknowledged at the TCP level over the second) s
5 528 M
( subflow. To preserve the continuity of the sequence numbers over the) s
5 517 M
( second subflow, TCP will continue to retransmit these segments until) s
5 506 M
( either they are acknowledged or the maximum number of retransmissions) s
5 495 M
( is reached. This behavior is clearly inefficient and may lead to) s
5 484 M
( blocking since the second subflow will consume window space to be) s
5 473 M
( able to retransmit these packets. [INFOCOM14] proposes a new) s
5 462 M
( Multipath TCP option to solve this problem. In practice, a new TCP) s
5 451 M
( option is probably not required. When the client detects that the) s
5 440 M
( data transmitted over the second subflow has been acknowledged over) s
5 429 M
( the first subflow, it could decide to terminate the second subflow by) s
5 418 M
( sending a RST segment. If the interface associated to this subflow) s
5 407 M
( is still up, a new subflow could be immediately reestablished. It) s
5 396 M
( would then be immediately usable to send new data and would not be) s
5 385 M
( forced to first retransmit the previously transmitted data. As of) s
5 374 M
( this writing, this dynamic management of the subflows is not yet) s
5 363 M
( implemented in the Multipath TCP implementation in the Linux kernel.) s
5 341 M
( Some studies have started to analyse the performance of Multipath TCP) s
5 330 M
( on smartphones with real applications. In contrast with the bulk) s
5 319 M
( transfers that are used by many publications, real applications do) s
5 308 M
( not exchange huge amounts of data and establish a large number of) s
5 297 M
( small connections. [COMMAG2016] proposes a software testing) s
5 286 M
( framework that allows to automate Android applications to study their) s
5 275 M
( interactions with Multipath TCP. [PAM2016] analyses a one-month) s
5 264 M
( packet trace of all the packets exchanged by a dozen of smartphones) s
5 253 M
( used by regular users. This analysis reveals that short connections) s
5 242 M
( are important on smartphones and that the main benefit of using) s
5 231 M
( Multipath TCP on smartphones is the ability to perform seamless) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 7]) s
_R
S
%%Page: (8) 8
%%BeginPageSetup
_S
24 24 translate
/pagenum 8 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( handovers between different wireless networks. Long connections) s
5 726 M
( benefit from these handovers.) s
5 704 M
(2.3. Multipath TCP proxies) s
5 682 M
( As Multipath TCP is not yet widely deployed on both clients and) s
5 671 M
( servers, several deployments have used various forms of proxies. Two) s
5 660 M
( families of solutions are currently being used or tested) s
5 649 M
( [I-D.deng-mptcp-proxy].) s
5 627 M
( A first use case is when a Multipath TCP enabled client wants to use) s
5 616 M
( several interfaces to reach a regular TCP server. A typical use case) s
5 605 M
( is a smartphone that needs to use both its WiFi and its cellular) s
5 594 M
( interface to transfer data. Several types of proxies are possible) s
5 583 M
( for this use case. An HTTP proxy deployed on a Multipath TCP capable) s
5 572 M
( server would enable the smartphone to use Multipath TCP to access) s
5 561 M
( regular web servers. Obviously, this solution only works for) s
5 550 M
( applications that rely on HTTP. Another possibility is to use a) s
5 539 M
( proxy that can convert any Multipath TCP connection into a regular) s
5 528 M
( TCP connection. Multipath TCP-specific proxies have been proposed) s
5 517 M
( [I-D.wei-mptcp-proxy-mechanism] [HotMiddlebox13b]) s
5 506 M
( [I-D.hampel-mptcp-proxies-anchors].) s
5 484 M
( Another possibility leverages the SOCKS protocol [RFC1928]. SOCKS is) s
5 473 M
( often used in enterprise networks to allow clients to reach external) s
5 462 M
( servers. For this, the client opens a TCP connection to the SOCKS) s
5 451 M
( server that relays it to the final destination. If both the client) s
5 440 M
( and the SOCKS server use Multipath TCP, but not the final) s
5 429 M
( destination, then Multipath TCP can still be used on the path between) s
5 418 M
( the client and the SOCKS server. At IETF'93, Korea Telecom announced) s
5 407 M
( that they have deployed in June 2015 a commercial service that uses) s
5 396 M
( Multipath TCP on smartphones. These smartphones access regular TCP) s
5 385 M
( servers through a SOCKS proxy. This enables them to achieve) s
5 374 M
( throughputs of up to 850 Mbps [KT].) s
5 352 M
( Measurements performed with Android smartphones [Mobicom15] show that) s
5 341 M
( popular applications work correctly through a SOCKS proxy and) s
5 330 M
( Multipath TCP enabled smartphones. Thanks to Multipath TCP, long-) s
5 319 M
( lived connections can be spread over the two available interfaces.) s
5 308 M
( However, for short-lived connections, most of the data is sent over) s
5 297 M
( the initial subflow that is created over the interface corresponding) s
5 286 M
( to the default route and the second subflow is almost not used) s
5 275 M
( [PAM2016].) s
5 253 M
( A second use case is when Multipath TCP is used by middleboxes,) s
5 242 M
( typically inside access networks. Various network operators are) s
5 231 M
( discussing and evaluating solutions for hybrid access networks) s
5 220 M
( [BBF-WT348]. Such networks arise when a network operator controls) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 8]) s
_R
S
%%Page: (9) 9
%%BeginPageSetup
_S
24 24 translate
/pagenum 9 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( two different access network technologies, e.g. wired and cellular,) s
5 726 M
( and wants to combine them to improve the bandwidth offered to the) s
5 715 M
( endusers [I-D.lhwxz-hybrid-access-network-architecture]. Several) s
5 704 M
( solutions are currently investigated for such networks [BBF-WT348].) s
5 693 M
( Figure 2 shows the organisation of such a network. When a client) s
5 682 M
( creates a normal TCP connection, it is intercepted by the Hybrid CPE) s
5 671 M
( \(HPCE\) that converts it in a Multipath TCP connection so that it can) s
5 660 M
( use the available access networks \(DSL and LTE in the example\). The) s
5 649 M
( Hybrid Access Gateway \(HAG\) does the opposite to ensure that the) s
5 638 M
( regular server sees a normal TCP connection. Some of the solutions) s
5 627 M
( that are currently discussed for hybrid networks use Multipath TCP on) s
5 616 M
( the HCPE and the HAG. Other solutions rely on tunnels between the) s
5 605 M
( HCPE and the HAG [I-D.lhwxz-gre-notifications-hybrid-access].) s
5 583 M
( client --- HCPE ------ DSL ------- HAG --- internet --- server) s
5 572 M
( | |) s
5 561 M
( +------- LTE -----------+) s
5 528 M
( Figure 2: Hybrid Access Network) s
5 506 M
(3. Operational Experience) s
5 484 M
(3.1. Middlebox interference) s
5 462 M
( The interference caused by various types of middleboxes has been an) s
5 451 M
( important concern during the design of the Multipath TCP protocol.) s
5 440 M
( Three studies on the interactions between Multipath TCP and) s
5 429 M
( middleboxes are worth discussing.) s
5 407 M
( The first analysis appears in [IMC11]. This paper was the main) s
5 396 M
( motivation for Multipath TCP incorporating various techniques to cope) s
5 385 M
( with middlebox interference. More specifically, Multipath TCP has) s
5 374 M
( been designed to cope with middleboxes that :) s
5 352 M
( o change source or destination addresses) s
5 330 M
( o change source or destination port numbers) s
5 308 M
( o change TCP sequence numbers) s
5 286 M
( o split or coalesce segments) s
5 264 M
( o remove TCP options) s
5 242 M
( o modify the payload of TCP segments) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 9]) s
_R
S
%%Page: (10) 10
%%BeginPageSetup
_S
24 24 translate
/pagenum 10 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( These middlebox interferences have all been included in the MBtest) s
5 726 M
( suite [MBTest]. This test suite is used in [HotMiddlebox13] to) s
5 715 M
( verify the reaction of the Multipath TCP implementation in the Linux) s
5 704 M
( kernel when faced with middlebox interference. The test environment) s
5 693 M
( used for this evaluation is a dual-homed client connected to a) s
5 682 M
( single-homed server. The middlebox behavior can be activated on any) s
5 671 M
( of the paths. The main results of this analysis are :) s
5 649 M
( o the Multipath TCP implementation in the Linux kernel is not) s
5 638 M
( affected by a middlebox that performs NAT or modifies TCP sequence) s
5 627 M
( numbers) s
5 605 M
( o when a middlebox removes the MP_CAPABLE option from the initial) s
5 594 M
( SYN segment, the Multipath TCP implementation in the Linux kernel) s
5 583 M
( falls back correctly to regular TCP) s
5 561 M
( o when a middlebox removes the DSS option from all data segments,) s
5 550 M
( the Multipath TCP implementation in the Linux kernel falls back) s
5 539 M
( correctly to regular TCP) s
5 517 M
( o when a middlebox performs segment coalescing, the Multipath TCP) s
5 506 M
( implementation in the Linux kernel is still able to accurately) s
5 495 M
( extract the data corresponding to the indicated mapping) s
5 473 M
( o when a middlebox performs segment splitting, the Multipath TCP) s
5 462 M
( implementation in the Linux kernel correctly reassembles the data) s
5 451 M
( corresponding to the indicated mapping. [HotMiddlebox13] shows on) s
5 440 M
( figure 4 in section 3.3 a corner case with segment splitting that) s
5 429 M
( may lead to a desynchronisation between the two hosts.) s
5 407 M
( The interactions between Multipath TCP and real deployed middleboxes) s
5 396 M
( is also analyzed in [HotMiddlebox13] and a particular scenario with) s
5 385 M
( the FTP application level gateway running on a NAT is described.) s
5 363 M
( Middlebox interference can also be detected by analysing packet) s
5 352 M
( traces on Multipath TCP enabled servers. A closer look at the) s
5 341 M
( packets received on the multipath-tcp.org server [TMA2015] shows that) s
5 330 M
( among the 184,000 Multipath TCP connections, only 125 of them were) s
5 319 M
( falling back to regular TCP. These connections originated from 28) s
5 308 M
( different client IP addresses. These include 91 HTTP connections and) s
5 297 M
( 34 FTP connections. The FTP interference is expected and due to) s
5 286 M
( Application Level Gateways running home routers. The HTTP) s
5 275 M
( interference appeared only on the direction from server to client and) s
5 264 M
( could have been caused by transparent proxies deployed in cellular or) s
5 253 M
( enterprise networks. A longer trace is discussed in [COMCOM2016] and) s
5 242 M
( similar conclusions about the middlebox interference are provided.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 10]) s
_R
S
%%Page: (11) 11
%%BeginPageSetup
_S
24 24 translate
/pagenum 11 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( From an operational viewpoint, knowing that Multipath TCP can cope) s
5 726 M
( with various types of middlebox interference is important. However,) s
5 715 M
( there are situations where the network operators need to gather) s
5 704 M
( information about where a particular middlebox interference occurs.) s
5 693 M
( The tracebox software [tracebox] described in [IMC13a] is an) s
5 682 M
( extension of the popular traceroute software that enables network) s
5 671 M
( operators to check at which hop a particular field of the TCP header) s
5 660 M
( \(including options\) is modified. It has been used by several network) s
5 649 M
( operators to debug various middlebox interference problems. tracebox) s
5 638 M
( includes a scripting language that enables its user to specify) s
5 627 M
( precisely which packet \(including IP and TCP options\) is sent by the) s
5 616 M
( source. tracebox sends packets with an increasing TTL/HopLimit and) s
5 605 M
( compares the information returned in the ICMP messages with the) s
5 594 M
( packet that it sent. This enables tracebox to detect any) s
5 583 M
( interference caused by middleboxes on a given path. tracebox works) s
5 572 M
( better when routers implement the ICMP extension defined in) s
5 561 M
( [RFC1812].) s
5 539 M
( Users of the Multipath TCP implementation have reported some) s
5 528 M
( experience with middlebox interference. The strangest scenario has) s
5 517 M
( been a middlebox that accepts the Multipath TCP options in the SYN) s
5 506 M
( segment but later replaces Multipath TCP options with a TCP EOL) s
5 495 M
( option [StrangeMbox]. This causes Multipath TCP to perform a) s
5 484 M
( fallback to regular TCP without any impact on the application.) s
5 462 M
(3.2. Congestion control) s
5 440 M
( Congestion control has been an important problem for Multipath TCP.) s
5 429 M
( The standardised congestion control scheme for Multipath TCP is) s
5 418 M
( defined in [RFC6356] and [NSDI11]. This congestion control scheme) s
5 407 M
( has been implemented in the Linux implementation of Multipath TCP.) s
5 396 M
( Linux uses a modular architecture to support various congestion) s
5 385 M
( control schemes. This architecture is applicable for both regular) s
5 374 M
( TCP and Multipath TCP. While the coupled congestion control scheme) s
5 363 M
( defined in [RFC6356] is the default congestion control scheme in the) s
5 352 M
( Linux implementation, other congestion control schemes have been) s
5 341 M
( added. The second congestion control scheme is OLIA [CONEXT12].) s
5 330 M
( This congestion control scheme is also an adaptation of the NewReno) s
5 319 M
( single path congestion control scheme to support multiple paths.) s
5 308 M
( Simulations and measurements have shown that it provides some) s
5 297 M
( performance benefits compared to the the default congestion control) s
5 286 M
( scheme [CONEXT12]. Measurements over a wide range of parameters) s
5 275 M
( reported in [CONEXT13] also indicate some benefits with the OLIA) s
5 264 M
( congestion control scheme. Recently, a delay-based congestion) s
5 253 M
( control scheme has been ported to the Multipath TCP implementation in) s
5 242 M
( the Linux kernel. This congestion control scheme has been evaluated) s
5 231 M
( by using simulations in [ICNP12]. The fourth congestion control) s
5 220 M
( scheme that has been included in the Linux implementation of) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 11]) s
_R
S
%%Page: (12) 12
%%BeginPageSetup
_S
24 24 translate
/pagenum 12 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( Multipath TCP is the BALIA scheme) s
5 726 M
( [I-D.walid-mptcp-congestion-control].) s
5 704 M
( These different congestion control schemes have been compared in) s
5 693 M
( several articles. [CONEXT13] and [PaaschPhD] compare these) s
5 682 M
( algorithms in an emulated environment. The evaluation showed that) s
5 671 M
( the delay-based congestion control scheme is less able to efficiently) s
5 660 M
( use the available links than the three other schemes. Reports from) s
5 649 M
( some users indicate that they seem to favor OLIA.) s
5 627 M
(3.3. Subflow management) s
5 605 M
( The multipath capability of Multipath TCP comes from the utilisation) s
5 594 M
( of one subflow per path. The Multipath TCP architecture [RFC6182]) s
5 583 M
( and the protocol specification [RFC6824] define the basic usage of) s
5 572 M
( the subflows and the protocol mechanisms that are required to create) s
5 561 M
( and terminate them. However, there are no guidelines on how subflows) s
5 550 M
( are used during the lifetime of a Multipath TCP session. Most of the) s
5 539 M
( published experiments with Multipath TCP have been performed in) s
5 528 M
( controlled environments. Still, based on the experience running them) s
5 517 M
( and discussions on the mptcp-dev mailing list, interesting lessons) s
5 506 M
( have been learned about the management of these subflows.) s
5 484 M
( From a subflow viewpoint, the Multipath TCP protocol is completely) s
5 473 M
( symmetrical. Both the clients and the server have the capability to) s
5 462 M
( create subflows. However in practice the existing Multipath TCP) s
5 451 M
( implementations [I-D.eardley-mptcp-implementations-survey] have opted) s
5 440 M
( for a strategy where only the client creates new subflows. The main) s
5 429 M
( motivation for this strategy is that often the client resides behind) s
5 418 M
( a NAT or a firewall, preventing passive subflow openings on the) s
5 407 M
( client. Although there are environments such as datacenters where) s
5 396 M
( this problem does not occur, as of this writing, no precise) s
5 385 M
( requirement has emerged for allowing the server to create new) s
5 374 M
( subflows.) s
5 352 M
(3.4. Implemented subflow managers) s
5 330 M
( The Multipath TCP implementation in the Linux kernel includes several) s
5 319 M
( strategies to manage the subflows that compose a Multipath TCP) s
5 308 M
( session. The basic subflow manager is the full-mesh. As the name) s
5 297 M
( implies, it creates a full-mesh of subflows between the communicating) s
5 286 M
( hosts.) s
5 264 M
( The most frequent use case for this subflow manager is a multihomed) s
5 253 M
( client connected to a single-homed server. In this case, one subflow) s
5 242 M
( is created for each interface on the client. The current) s
5 231 M
( implementation of the full-mesh subflow manager is static. The) s
5 220 M
( subflows are created immediately after the creation of the initial) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 12]) s
_R
S
%%Page: (13) 13
%%BeginPageSetup
_S
24 24 translate
/pagenum 13 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( subflow. If one subflow fails during the lifetime of the Multipath) s
5 726 M
( TCP session \(e.g. due to excessive retransmissions, or the loss of) s
5 715 M
( the corresponding interface\), it is not always reestablished. There) s
5 704 M
( is ongoing work to enhance the full-mesh path manager to deal with) s
5 693 M
( such events.) s
5 671 M
( When the server is multihomed, using the full-mesh subflow manager) s
5 660 M
( may lead to a large number of subflows being established. For) s
5 649 M
( example, consider a dual-homed client connected to a server with) s
5 638 M
( three interfaces. In this case, even if the subflows are only) s
5 627 M
( created by the client, 6 subflows will be established. This may be) s
5 616 M
( excessive in some environments, in particular when the client and/or) s
5 605 M
( the server have a large number of interfaces. A recent draft has) s
5 594 M
( proposed a Multipath TCP option to negotiate the maximum number of) s
5 583 M
( subflows. However, it should be noted that there have been reports) s
5 572 M
( on the mptcp-dev mailing indicating that users rely on Multipath TCP) s
5 561 M
( to aggregate more than four different interfaces. Thus, there is a) s
5 550 M
( need for supporting many interfaces efficiently.) s
5 528 M
( Creating subflows between multihomed clients and servers may) s
5 517 M
( sometimes lead to operational issues as observed by discussions on) s
5 506 M
( the mptcp-dev mailing list. In some cases the network operators) s
5 495 M
( would like to have a better control on how the subflows are created) s
5 484 M
( by Multipath TCP [I-D.boucadair-mptcp-max-subflow]. This might) s
5 473 M
( require the definition of policy rules to control the operation of) s
5 462 M
( the subflow manager. The two scenarios below illustrate some of) s
5 451 M
( these requirements.) s
5 429 M
( host1 ---------- switch1 ----- host2) s
5 418 M
( | | |) s
5 407 M
( +-------------- switch2 --------+) s
5 374 M
( Figure 3: Simple switched network topology) s
5 352 M
( Consider the simple network topology shown in Figure 3. From an) s
5 341 M
( operational viewpoint, a network operator could want to create two) s
5 330 M
( subflows between the communicating hosts. From a bandwidth) s
5 319 M
( utilization viewpoint, the most natural paths are host1-switch1-host2) s
5 308 M
( and host1-switch2-host2. However, a Multipath TCP implementation) s
5 297 M
( running on these two hosts may sometimes have difficulties to obtain) s
5 286 M
( this result.) s
5 264 M
( To understand the difficulty, let us consider different allocation) s
5 253 M
( strategies for the IP addresses. A first strategy is to assign two) s
5 242 M
( subnets : subnetA \(resp. subnetB\) contains the IP addresses of) s
5 231 M
( host1's interface to switch1 \(resp. switch2\) and host2's interface to) s
5 220 M
( switch1 \(resp. switch2\). In this case, a Multipath TCP subflow) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 13]) s
_R
S
%%Page: (14) 14
%%BeginPageSetup
_S
24 24 translate
/pagenum 14 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( manager should only create one subflow per subnet. To enforce the) s
5 726 M
( utilization of these paths, the network operator would have to) s
5 715 M
( specify a policy that prefers the subflows in the same subnet over) s
5 704 M
( subflows between addresses in different subnets. It should be noted) s
5 693 M
( that the policy should probably also specify how the subflow manager) s
5 682 M
( should react when an interface or subflow fails.) s
5 660 M
( A second strategy is to use a single subnet for all IP addresses. In) s
5 649 M
( this case, it becomes more difficult to specify a policy that) s
5 638 M
( indicates which subflows should be established.) s
5 616 M
( The second subflow manager that is currently supported by the) s
5 605 M
( Multipath TCP implementation in the Linux kernel is the ndiffport) s
5 594 M
( subflow manager. This manager was initially created to exploit the) s
5 583 M
( path diversity that exists between single-homed hosts due to the) s
5 572 M
( utilization of flow-based load balancing techniques [SIGCOMM11].) s
5 561 M
( This subflow manager creates N subflows between the same pair of IP) s
5 550 M
( addresses. The N subflows are created by the client and differ only) s
5 539 M
( in the source port selected by the client. It was not designed to be) s
5 528 M
( used on multihomed hosts.) s
5 506 M
( A more flexible subflow manager has been proposed, implemented and) s
5 495 M
( evaluated in [CONEXT15]. This subflow manager exposes various kernel) s
5 484 M
( events to a user space daemon that decides when subflows need to be) s
5 473 M
( created and terminated based on various policies.) s
5 451 M
(3.5. Subflow destination port) s
5 429 M
( The Multipath TCP protocol relies on the token contained in the) s
5 418 M
( MP_JOIN option to associate a subflow to an existing Multipath TCP) s
5 407 M
( session. This implies that there is no restriction on the source) s
5 396 M
( address, destination address and source or destination ports used for) s
5 385 M
( the new subflow. The ability to use different source and destination) s
5 374 M
( addresses is key to support multihomed servers and clients. The) s
5 363 M
( ability to use different destination port numbers is worth discussing) s
5 352 M
( because it has operational implications.) s
5 330 M
( For illustration, consider a dual-homed client that creates a second) s
5 319 M
( subflow to reach a single-homed server as illustrated in Figure 4.) s
5 297 M
( client ------- r1 --- internet --- server) s
5 286 M
( | |) s
5 275 M
( +----------r2-------+) s
5 242 M
( Figure 4: Multihomed-client connected to single-homed server) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 14]) s
_R
S
%%Page: (15) 15
%%BeginPageSetup
_S
24 24 translate
/pagenum 15 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( When the Multipath TCP implementation in the Linux kernel creates the) s
5 726 M
( second subflow it uses the same destination port as the initial) s
5 715 M
( subflow. This choice is motivated by the fact that the server might) s
5 704 M
( be protected by a firewall and only accept TCP connections \(including) s
5 693 M
( subflows\) on the official port number. Using the same destination) s
5 682 M
( port for all subflows is also useful for operators that rely on the) s
5 671 M
( port numbers to track application usage in their network.) s
5 649 M
( There have been suggestions from Multipath TCP users to modify the) s
5 638 M
( implementation to allow the client to use different destination ports) s
5 627 M
( to reach the server. This suggestion seems mainly motivated by) s
5 616 M
( traffic shaping middleboxes that are used in some wireless networks.) s
5 605 M
( In networks where different shaping rates are associated to different) s
5 594 M
( destination port numbers, this could allow Multipath TCP to reach a) s
5 583 M
( higher performance. As of this writing, we are not aware of any) s
5 572 M
( implementation of this kind of tweaking.) s
5 550 M
( However, from an implementation point-of-view supporting different) s
5 539 M
( destination ports for the same Multipath TCP connection can cause) s
5 528 M
( some issues. A legacy implementation of a TCP stack creates a) s
5 517 M
( listening socket to react upon incoming SYN segments. The listening) s
5 506 M
( socket is handling the SYN segments that are sent on a specific port) s
5 495 M
( number. Demultiplexing incoming segments can thus be done solely by) s
5 484 M
( looking at the IP addresses and the port numbers. With Multipath TCP) s
5 473 M
( however, incoming SYN segments may have an MP_JOIN option with a) s
5 462 M
( different destination port. This means, that all incoming segments) s
5 451 M
( that did not match on an existing listening-socket or an already) s
5 440 M
( established socket must be parsed for an eventual MP_JOIN option.) s
5 429 M
( This imposes an additional cost on servers, previously not existent) s
5 418 M
( on legacy TCP implementations.) s
5 396 M
(3.6. Closing subflows) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 15]) s
_R
S
%%Page: (16) 16
%%BeginPageSetup
_S
24 24 translate
/pagenum 16 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( client server) s
5 726 M
( | |) s
5 715 M
( MPTCP: established | | MPTCP: established) s
5 704 M
( Sub: established | | Sub: established) s
5 693 M
( | |) s
5 682 M
( | DATA_FIN |) s
5 671 M
( MPTCP: close-wait | <------------------------ | close\(\) \(step 1\)) s
5 660 M
( Sub: established | DATA_ACK |) s
5 649 M
( | ------------------------> | MPTCP: fin-wait-2) s
5 638 M
( | | Sub: established) s
5 627 M
( | |) s
5 616 M
( | DATA_FIN + subflow-FIN |) s
5 605 M
( close\(\)/shutdown\(\) | ------------------------> | MPTCP: time-wait) s
5 594 M
( \(step 2\) | DATA_ACK | Sub: close-wait) s
5 583 M
( MPTCP: closed | <------------------------ |) s
5 572 M
( Sub: fin-wait-2 | |) s
5 561 M
( | |) s
5 550 M
( | subflow-FIN |) s
5 539 M
( MPTCP: closed | <------------------------ | subflow-close\(\)) s
5 528 M
( Sub: time-wait | subflow-ACK |) s
5 517 M
( \(step 3\) | ------------------------> | MPTCP: time-wait) s
5 506 M
( | | Sub: closed) s
5 495 M
( | |) s
5 462 M
( Figure 5: Multipath TCP may not be able to avoid time-wait state) s
5 451 M
( \(even if enforced by the application\).) s
5 429 M
( Figure 5 shows a very particular issue within Multipath TCP. Many) s
5 418 M
( high-performance applications try to avoid Time-Wait state by) s
5 407 M
( deferring the closure of the connection until the peer has sent a) s
5 396 M
( FIN. That way, the client on the left of Figure 5 does a passive) s
5 385 M
( closure of the connection, transitioning from Close-Wait to Last-ACK) s
5 374 M
( and finally freeing the resources after reception of the ACK of the) s
5 363 M
( FIN. An application running on top of a Multipath TCP enabled Linux) s
5 352 M
( kernel might also use this approach. The difference here is that the) s
5 341 M
( close\(\) of the connection \(Step 1 in Figure 5\) only triggers the) s
5 330 M
( sending of a DATA_FIN. Nothing guarantees that the kernel is ready) s
5 319 M
( to combine the DATA_FIN with a subflow-FIN. The reception of the) s
5 308 M
( DATA_FIN will make the application trigger the closure of the) s
5 297 M
( connection \(step 2\), trying to avoid Time-Wait state with this late) s
5 286 M
( closure. This time, the kernel might decide to combine the DATA_FIN) s
5 275 M
( with a subflow-FIN. This decision will be fatal, as the subflow's) s
5 264 M
( state machine will not transition from Close-Wait to Last-Ack, but) s
5 253 M
( rather go through Fin-Wait-2 into Time-Wait state. The Time-Wait) s
5 242 M
( state will consume resources on the host for at least 2 MSL \(Maximum) s
5 231 M
( Segment Lifetime\). Thus, a smart application that tries to avoid) s
5 220 M
( Time-Wait state by doing late closure of the connection actually ends) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 16]) s
_R
S
%%Page: (17) 17
%%BeginPageSetup
_S
24 24 translate
/pagenum 17 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( up with one of its subflows in Time-Wait state. A high-performance) s
5 726 M
( Multipath TCP kernel implementation should honor the desire of the) s
5 715 M
( application to do passive closure of the connection and successfully) s
5 704 M
( avoid Time-Wait state - even on the subflows.) s
5 682 M
( The solution to this problem lies in an optimistic assumption that a) s
5 671 M
( host doing active-closure of a Multipath TCP connection by sending a) s
5 660 M
( DATA_FIN will soon also send a FIN on all its subflows. Thus, the) s
5 649 M
( passive closer of the connection can simply wait for the peer to send) s
5 638 M
( exactly this FIN - enforcing passive closure even on the subflows.) s
5 627 M
( Of course, to avoid consuming resources indefinitely, a timer must) s
5 616 M
( limit the time our implementation waits for the FIN.) s
5 594 M
(3.7. Packet schedulers) s
5 572 M
( In a Multipath TCP implementation, the packet scheduler is the) s
5 561 M
( algorithm that is executed when transmitting each packet to decide on) s
5 550 M
( which subflow it needs to be transmitted. The packet scheduler) s
5 539 M
( itself does not have any impact on the interoperability of Multipath) s
5 528 M
( TCP implementations. However, it may clearly impact the performance) s
5 517 M
( of Multipath TCP sessions. The Multipath TCP implementation in the) s
5 506 M
( Linux kernel supports a pluggable architecture for the packet) s
5 495 M
( scheduler [PaaschPhD]. As of this writing, two schedulers have been) s
5 484 M
( implemented: round-robin and lowest-rtt-first. The second scheduler) s
5 473 M
( relies on the round-trip-time \(rtt\) measured on each TCP subflow and) s
5 462 M
( sends first segments over the subflow having the lowest round-trip-) s
5 451 M
( time. They are compared in [CSWS14]. The experiments and) s
5 440 M
( measurements described in [CSWS14] show that the lowest-rtt-first) s
5 429 M
( scheduler appears to be the best compromise from a performance) s
5 418 M
( viewpoint. Another study of the packet schedulers is presented in) s
5 407 M
( [PAMS2014]. This study relies on simulations with the Multipath TCP) s
5 396 M
( implementation in the Linux kernel. They compare the lowest-rtt-) s
5 385 M
( first with the round-robin and a random scheduler. They show some) s
5 374 M
( situations where the lowest-rtt-first scheduler does not perform as) s
5 363 M
( well as the other schedulers, but there are many scenarios where the) s
5 352 M
( opposite is true. [PAMS2014] notes that "it is highly likely that) s
5 341 M
( the optimal scheduling strategy depends on the characteristics of the) s
5 330 M
( paths being used.") s
5 308 M
(3.8. Segment size selection) s
5 286 M
( When an application performs a write/send system call, the kernel) s
5 275 M
( allocates a packet buffer \(sk_buff in Linux\) to store the data the) s
5 264 M
( application wants to send. The kernel will store at most one MSS) s
5 253 M
( \(Maximum Segment Size\) of data per buffer. As the MSS can differ) s
5 242 M
( amongst subflows, an MPTCP implementation must select carefully the) s
5 231 M
( MSS used to generate application data. The Linux kernel) s
5 220 M
( implementation had various ways of selecting the MSS: minimum or) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 17]) s
_R
S
%%Page: (18) 18
%%BeginPageSetup
_S
24 24 translate
/pagenum 18 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( maximum amongst the different subflows. However, these heuristics of) s
5 726 M
( MSS selection can cause significant performance issues in some) s
5 715 M
( environment. Consider the following example. An MPTCP connection) s
5 704 M
( has two established subflows that respectively use a MSS of 1420 and) s
5 693 M
( 1428 bytes. If MPTCP selects the maximum, then the application will) s
5 682 M
( generate segments of 1428 bytes of data. An MPTCP implementation) s
5 671 M
( will have to split the segment in two \(a 1420-byte and 8-byte) s
5 660 M
( segments\) when pushing on the subflow with the smallest MSS. The) s
5 649 M
( latter segment will introduce a large overhead as for a single data) s
5 638 M
( segment 2 slots will be used in the congestion window \(in packets\)) s
5 627 M
( therefore reducing by roughly twice the potential throughput \(in) s
5 616 M
( bytes/s\) of this subflow. Taking the smallest MSS does not solve the) s
5 605 M
( issue as there might be a case where the subflow with the smallest) s
5 594 M
( MSS only sends a few packets therefore reducing the potential) s
5 583 M
( throughput of the other subflows.) s
5 561 M
( The Linux implementation recently took another approach [DetalMSS].) s
5 550 M
( Instead of selecting the minimum and maximum values, it now) s
5 539 M
( dynamically adapts the MSS based on the contribution of all the) s
5 528 M
( subflows to the connection's throughput. For this it computes, for) s
5 517 M
( each subflow, the potential throughput achieved by selecting each MSS) s
5 506 M
( value and by taking into account the lost space in the cwnd. It then) s
5 495 M
( selects the MSS that allows to achieve the highest potential) s
5 484 M
( throughput.) s
5 462 M
(3.9. Interactions with the Domain Name System) s
5 440 M
( Multihomed clients such as smartphones can send DNS queries over any) s
5 429 M
( of their interfaces. When a single-homed client performs a DNS) s
5 418 M
( query, it receives from its local resolver the best answer for its) s
5 407 M
( request. If the client is multihomed, the answer returned to the DNS) s
5 396 M
( query may vary with the interface over which it has been sent.) s
5 374 M
( cdn1) s
5 363 M
( |) s
5 352 M
( client -- cellular -- internet -- cdn3) s
5 341 M
( | |) s
5 330 M
( +----- wifi --------+) s
5 319 M
( |) s
5 308 M
( cdn2) s
5 275 M
( Figure 6: Simple network topology) s
5 253 M
( If the client sends a DNS query over the WiFi interface, the answer) s
5 242 M
( will point to the cdn2 server while the same request sent over the) s
5 231 M
( cellular interface will point to the cdn1 server. This might cause) s
5 220 M
( problems for CDN providers that locate their servers inside ISP) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 18]) s
_R
S
%%Page: (19) 19
%%BeginPageSetup
_S
24 24 translate
/pagenum 19 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( networks and have contracts that specify that the CDN server will) s
5 726 M
( only be accessed from within this particular ISP. Assume now that) s
5 715 M
( both the client and the CDN servers support Multipath TCP. In this) s
5 704 M
( case, a Multipath TCP session from cdn1 or cdn2 would potentially use) s
5 693 M
( both the cellular network and the WiFi network. Serving the client) s
5 682 M
( from cdn2 over the cellular interface could violate the contract) s
5 671 M
( between the CDN provider and the network operators. A similar) s
5 660 M
( problem occurs with regular TCP if the client caches DNS replies.) s
5 649 M
( For example the client obtains a DNS answer over the cellular) s
5 638 M
( interface and then stops this interface and starts to use its WiFi) s
5 627 M
( interface. If the client retrieves data from cdn1 over its WiFi) s
5 616 M
( interface, this may also violate the contract between the CDN and the) s
5 605 M
( network operators.) s
5 583 M
( A possible solution to prevent this problem would be to modify the) s
5 572 M
( DNS resolution on the client. The client subnet EDNS extension) s
5 561 M
( defined in [I-D.ietf-dnsop-edns-client-subnet] could be used for this) s
5 550 M
( purpose. When the client sends a DNS query from its WiFi interface,) s
5 539 M
( it should also send the client subnet corresponding to the cellular) s
5 528 M
( interface in this request. This would indicate to the resolver that) s
5 517 M
( the answer should be valid for both the WiFi and the cellular) s
5 506 M
( interfaces \(e.g., the cdn3 server\).) s
5 484 M
(3.10. Captive portals) s
5 462 M
( Multipath TCP enables a host to use different interfaces to reach a) s
5 451 M
( server. In theory, this should ensure connectivity when at least one) s
5 440 M
( of the interfaces is active. In practice however, there are some) s
5 429 M
( particular scenarios with captive portals that may cause operational) s
5 418 M
( problems. The reference environment is shown in Figure 7.) s
5 396 M
( client ----- network1) s
5 385 M
( |) s
5 374 M
( +------- internet ------------- server) s
5 341 M
( Figure 7: Issue with captive portal) s
5 319 M
( The client is attached to two networks : network1 that provides) s
5 308 M
( limited connectivity and the entire Internet through the second) s
5 297 M
( network interface. In practice, this scenario corresponds to an open) s
5 286 M
( WiFi network with a captive portal for network1 and a cellular) s
5 275 M
( service for the second interface. On many smartphones, the WiFi) s
5 264 M
( interface is preferred over the cellular interface. If the) s
5 253 M
( smartphone learns a default route via both interfaces, it will) s
5 242 M
( typically prefer to use the WiFi interface to send its DNS request) s
5 231 M
( and create the first subflow. This is not optimal with Multipath) s
5 220 M
( TCP. A better approach would probably be to try a few attempts on) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 19]) s
_R
S
%%Page: (20) 20
%%BeginPageSetup
_S
24 24 translate
/pagenum 20 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( the WiFi interface and then try to use the second interface for the) s
5 726 M
( initial subflow as well.) s
5 704 M
(3.11. Stateless webservers) s
5 682 M
( MPTCP has been designed to interoperate with webservers that benefit) s
5 671 M
( from SYN-cookies to protect against SYN-flooding attacks [RFC4987].) s
5 660 M
( MPTCP achieves this by echoing the keys negotiated during the) s
5 649 M
( MP_CAPABLE handshake in the third ACK of the 3-way handshake.) s
5 638 M
( Reception of this third ACK then allows the server to reconstruct the) s
5 627 M
( state specific to MPTCP.) s
5 605 M
( However, one caveat to this mechanism is the non-reliable nature of) s
5 594 M
( the third ACK. Indeed, when the third ACK gets lost, the server will) s
5 583 M
( not be able to reconstruct the MPTCP-state. MPTCP will fallback to) s
5 572 M
( regular TCP in this case. This is in contrast to regular TCP. When) s
5 561 M
( the client starts sending data, the first data segment also includes) s
5 550 M
( the SYN-cookie, which allows the server to reconstruct the TCP-state.) s
5 539 M
( Further, this data segment will be retransmitted by the client in) s
5 528 M
( case it gets lost and thus is resilient against loss. MPTCP does not) s
5 517 M
( include the keys in this data segment and thus the server cannot) s
5 506 M
( reconstruct the MPTCP state.) s
5 484 M
( This issue might be considered as a minor one for MPTCP. Losing the) s
5 473 M
( third ACK should only happen when packet loss is high. However, when) s
5 462 M
( packet-loss is high MPTCP provides a lot of benefits as it can move) s
5 451 M
( traffic away from the lossy link. It is undesirable that MPTCP has a) s
5 440 M
( higher chance to fall back to regular TCP in those lossy) s
5 429 M
( environments.) s
5 407 M
( [I-D.paasch-mptcp-syncookies] discusses this issue and suggests a) s
5 396 M
( modified handshake mechanism that ensures reliable delivery of the) s
5 385 M
( MP_CAPABLE, following the 3-way handshake. This modification will) s
5 374 M
( make MPTCP reliable, even in lossy environments when servers need to) s
5 363 M
( use SYN-cookies to protect against SYN-flooding attacks.) s
5 341 M
(3.12. Loadbalanced serverfarms) s
5 319 M
( Large-scale serverfarms typically deploy thousands of servers behind) s
5 308 M
( a single virtual IP \(VIP\). Steering traffic to these servers is done) s
5 297 M
( through layer-4 loadbalancers that ensure that a TCP-flow will always) s
5 286 M
( be routed to the same server [Presto08].) s
5 264 M
( As Multipath TCP uses multiple different TCP subflows to steer the) s
5 253 M
( traffic across the different paths, loadbalancers need to ensure that) s
5 242 M
( all these subflows are routed to the same server. This implies that) s
5 231 M
( the loadbalancers need to track the MPTCP-related state, allowing) s
5 220 M
( them to parse the token in the MP_JOIN and assign those subflows to) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 20]) s
_R
S
%%Page: (21) 21
%%BeginPageSetup
_S
24 24 translate
/pagenum 21 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( the appropriate server. However, serverfarms typically deploy) s
5 726 M
( multiple of these loadbalancers for reliability and capacity reasons.) s
5 715 M
( As a TCP subflow might get routed to any of these loadbalancers, they) s
5 704 M
( would need to synchronize the MPTCP-related state - a solution that) s
5 693 M
( is not feasible at large scale.) s
5 671 M
( The token \(carried in the MP_JOIN\) contains the information) s
5 660 M
( indicating which MPTCP-session the subflow belongs to. As the token) s
5 649 M
( is a hash of the key, servers are not able to generate the token in) s
5 638 M
( such a way that the token can provide the necessary information to) s
5 627 M
( the loadbalancers which would allow them to route TCP subflows to the) s
5 616 M
( appropriate server. [I-D.paasch-mptcp-loadbalancer] discusses this) s
5 605 M
( issue in detail and suggests two alternative MP_CAPABLE handshakes to) s
5 594 M
( overcome these. As of September 2015, it is not yet clear how MPTCP) s
5 583 M
( might accomodate such use-case to enable its deployment within) s
5 572 M
( loadbalanced serverfarms.) s
5 550 M
(4. Conclusion) s
5 528 M
( In this document, we have documented a few years of experience with) s
5 517 M
( Multipath TCP. The different scientific publications that have been) s
5 506 M
( summarised confirm that Multipath TCP works well in different use) s
5 495 M
( cases in today's Internet. None of the cited publications has) s
5 484 M
( identified major issues with Multipath TCP and its utilisation in the) s
5 473 M
( current Internet. Some of these publications list directions for) s
5 462 M
( future improvements that mainly affect the subflow managers and) s
5 451 M
( packet schedulers. These heuristics affect the performance of) s
5 440 M
( Multipath TCP, but not the protocol itself. It is likely that these) s
5 429 M
( improvements will be discussed in future IETF documents.) s
5 407 M
( Besides the published scientific literature, a number of companies) s
5 396 M
( have deployed Multipath TCP at large. One of these deployments uses) s
5 385 M
( Multipath TCP on the client and the server side, making it a true) s
5 374 M
( end-to-end deployment. This deployment uses Multipath TCP to support) s
5 363 M
( fast handover between cellular and WiFi networks. A wider deployment) s
5 352 M
( of Multipath TCP on servers seems to be blocked by the necessity to) s
5 341 M
( support Multipath TCP on load balancers. Given the influence that) s
5 330 M
( middleboxes had on the design of Multipath TCP, it is interesting to) s
5 319 M
( note that the other industrial deployments use Multipath TCP inside) s
5 308 M
( middleboxes. These middelboxes use Multipath TCP to efficiently) s
5 297 M
( combine several access links while still interacting with legacy TCP) s
5 286 M
( servers.) s
5 264 M
(5. Acknowledgements) s
5 242 M
( This work was partially supported by the FP7-Trilogy2 project. We) s
5 231 M
( would like to thank all the implementers and users of the Multipath) s
5 220 M
( TCP implementation in the Linux kernel. This document has benefited) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 21]) s
_R
S
%%Page: (22) 22
%%BeginPageSetup
_S
24 24 translate
/pagenum 22 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( from the comments of John Ronan, Yoshifumi Nishida, Phil Eardley and) s
5 726 M
( Jaehyun Hwang.) s
5 704 M
(6. Informative References) s
5 682 M
( [Apple-MPTCP]) s
5 671 M
( Apple, Inc, ., "iOS - Multipath TCP Support in iOS 7",) s
5 660 M
( n.d., <https://support.apple.com/en-us/HT201373>.) s
5 638 M
( [BBF-WT348]) s
5 627 M
( Fabregas \(Ed\), G., "WT-348 - Hybrid Access for Broadband) s
5 616 M
( Networks", Broadband Forum, contribution bbf2014.1139.04 ,) s
5 605 M
( June 2015.) s
5 583 M
( [CACM14] Paasch, C. and O. Bonaventure, "Multipath TCP",) s
5 572 M
( Communications of the ACM, 57\(4\):51-57 , April 2014,) s
5 561 M
( <http://inl.info.ucl.ac.be/publications/multipath-tcp>.) s
5 539 M
( [COMCOM2016]) s
5 528 M
( "Observing real Multipath TCP traffic", Computer) s
5 517 M
( Communications , April 2016,) s
5 506 M
( <http://inl.info.ucl.ac.be/publications/) s
5 495 M
( observing-real-multipath-tcp-traffic>.) s
5 473 M
( [COMMAG2016]) s
5 462 M
( De Coninck, Q., Baerts, M., Hesmans, B., and O.) s
5 451 M
( Bonaventure, "Observing Real Smartphone Applications over) s
5 440 M
( Multipath TCP", IEEE Communications Magazine , March 2016,) s
5 429 M
( <http://inl.info.ucl.ac.be/publications/observing-real-) s
5 418 M
( smartphone-applications-over-multipath-tcp>.) s
5 396 M
( [CONEXT12]) s
5 385 M
( Khalili, R., Gast, N., Popovic, M., Upadhyay, U., and J.) s
5 374 M
( Leboudec, "MPTCP is not pareto-optimal performance issues) s
5 363 M
( and a possible solution", Proceedings of the 8th) s
5 352 M
( international conference on Emerging networking) s
5 341 M
( experiments and technologies \(CoNEXT12\) , 2012.) s
5 319 M
( [CONEXT13]) s
5 308 M
( Paasch, C., Khalili, R., and O. Bonaventure, "On the) s
5 297 M
( Benefits of Applying Experimental Design to Improve) s
5 286 M
( Multipath TCP", Conference on emerging Networking) s
5 275 M
( EXperiments and Technologies \(CoNEXT\) , December 2013,) s
5 264 M
( <http://inl.info.ucl.ac.be/publications/benefits-applying-) s
5 253 M
( experimental-design-improve-multipath-tcp>.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 22]) s
_R
S
%%Page: (23) 23
%%BeginPageSetup
_S
24 24 translate
/pagenum 23 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( [CONEXT15]) s
5 726 M
( Hesmans, B., Detal, G., Barre, S., Bauduin, R., and O.) s
5 715 M
( Bonaventure, "SMAPP - Towards Smart Multipath TCP-enabled) s
5 704 M
( APPlications", Proc. Conext 2015, Heidelberg, Germany ,) s
5 693 M
( December 2015, <http://inl.info.ucl.ac.be/publications/) s
5 682 M
( smapp-towards-smart-multipath-tcp-enabled-applications>.) s
5 660 M
( [CSWS14] Paasch, C., Ferlin, S., Alay, O., and O. Bonaventure,) s
5 649 M
( "Experimental Evaluation of Multipath TCP Schedulers",) s
5 638 M
( SIGCOMM CSWS2014 workshop , August 2014.) s
5 616 M
( [Cellnet12]) s
5 605 M
( Paasch, C., Detal, G., Duchene, F., Raiciu, C., and O.) s
5 594 M
( Bonaventure, "Exploring Mobile/WiFi Handover with) s
5 583 M
( Multipath TCP", ACM SIGCOMM workshop on Cellular Networks) s
5 572 M
( \(Cellnet12\) , 2012,) s
5 561 M
( <http://inl.info.ucl.ac.be/publications/) s
5 550 M
( exploring-mobilewifi-handover-multipath-tcp>.) s
5 528 M
( [DetalMSS]) s
5 517 M
( Detal, G., "Adaptive MSS value", Post on the mptcp-dev) s
5 506 M
( mailing list , September 2014, <https://listes-) s
5 495 M
( 2.sipr.ucl.ac.be/sympa/arc/mptcp-dev/2014-09/) s
5 484 M
( msg00130.html>.) s
5 462 M
( [FreeBSD-MPTCP]) s
5 451 M
( Williams, N., "Multipath TCP For FreeBSD Kernel Patch) s
5 440 M
( v0.5", n.d., <http://caia.swin.edu.au/urp/newtcp/mptcp>.) s
5 418 M
( [HotMiddlebox13]) s
5 407 M
( Hesmans, B., Duchene, F., Paasch, C., Detal, G., and O.) s
5 396 M
( Bonaventure, "Are TCP Extensions Middlebox-proof?", CoNEXT) s
5 385 M
( workshop HotMiddlebox , December 2013,) s
5 374 M
( <http://inl.info.ucl.ac.be/publications/) s
5 363 M
( are-tcp-extensions-middlebox-proof>.) s
5 341 M
( [HotMiddlebox13b]) s
5 330 M
( Detal, G., Paasch, C., and O. Bonaventure, "Multipath in) s
5 319 M
( the Middle\(Box\)", HotMiddlebox'13 , December 2013,) s
5 308 M
( <http://inl.info.ucl.ac.be/publications/) s
5 297 M
( multipath-middlebox>.) s
5 275 M
( [HotNets] Raiciu, C., Pluntke, C., Barre, S., Greenhalgh, A.,) s
5 264 M
( Wischik, D., and M. Handley, "Data center networking with) s
5 253 M
( multipath TCP", Proceedings of the 9th ACM SIGCOMM) s
5 242 M
( Workshop on Hot Topics in Networks \(Hotnets-IX\) , 2010,) s
5 231 M
( <http://doi.acm.org/10.1145/1868447.1868457>.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 23]) s
_R
S
%%Page: (24) 24
%%BeginPageSetup
_S
24 24 translate
/pagenum 24 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( [I-D.boucadair-mptcp-max-subflow]) s
5 726 M
( Boucadair, M. and C. Jacquenet, "Negotiating the Maximum) s
5 715 M
( Number of Multipath TCP \(MPTCP\) Subflows", draft-) s
5 704 M
( boucadair-mptcp-max-subflow-01 \(work in progress\),) s
5 693 M
( December 2015.) s
5 671 M
( [I-D.deng-mptcp-proxy]) s
5 660 M
( Lingli, D., Liu, D., Sun, T., Boucadair, M., and G.) s
5 649 M
( Cauchie, "Use-cases and Requirements for MPTCP Proxy in) s
5 638 M
( ISP Networks", draft-deng-mptcp-proxy-01 \(work in) s
5 627 M
( progress\), October 2014.) s
5 605 M
( [I-D.eardley-mptcp-implementations-survey]) s
5 594 M
( Eardley, P., "Survey of MPTCP Implementations", draft-) s
5 583 M
( eardley-mptcp-implementations-survey-02 \(work in) s
5 572 M
( progress\), July 2013.) s
5 550 M
( [I-D.hampel-mptcp-proxies-anchors]) s
5 539 M
( Hampel, G. and T. Klein, "MPTCP Proxies and Anchors",) s
5 528 M
( draft-hampel-mptcp-proxies-anchors-00 \(work in progress\),) s
5 517 M
( February 2012.) s
5 495 M
( [I-D.ietf-dnsop-edns-client-subnet]) s
5 484 M
( Contavalli, C., Gaast, W., tale, t., and W. Kumari,) s
5 473 M
( "Client Subnet in DNS Queries", draft-ietf-dnsop-edns-) s
5 462 M
( client-subnet-07 \(work in progress\), March 2016.) s
5 440 M
( [I-D.lhwxz-gre-notifications-hybrid-access]) s
5 429 M
( Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.) s
5 418 M
( Zhang, "GRE Notifications for Hybrid Access", draft-lhwxz-) s
5 407 M
( gre-notifications-hybrid-access-01 \(work in progress\),) s
5 396 M
( January 2015.) s
5 374 M
( [I-D.lhwxz-hybrid-access-network-architecture]) s
5 363 M
( Leymann, N., Heidemann, C., Wasserman, M., Xue, L., and M.) s
5 352 M
( Zhang, "Hybrid Access Network Architecture", draft-lhwxz-) s
5 341 M
( hybrid-access-network-architecture-02 \(work in progress\),) s
5 330 M
( January 2015.) s
5 308 M
( [I-D.paasch-mptcp-loadbalancer]) s
5 297 M
( Paasch, C., Greenway, G., and A. Ford, "Multipath TCP) s
5 286 M
( behind Layer-4 loadbalancers", draft-paasch-mptcp-) s
5 275 M
( loadbalancer-00 \(work in progress\), September 2015.) s
5 253 M
( [I-D.paasch-mptcp-syncookies]) s
5 242 M
( Paasch, C., Biswas, A., and D. Haas, "Making Multipath TCP) s
5 231 M
( robust for stateless webservers", draft-paasch-mptcp-) s
5 220 M
( syncookies-02 \(work in progress\), October 2015.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 24]) s
_R
S
%%Page: (25) 25
%%BeginPageSetup
_S
24 24 translate
/pagenum 25 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( [I-D.walid-mptcp-congestion-control]) s
5 726 M
( Walid, A., Peng, Q., Hwang, J., and S. Low, "Balanced) s
5 715 M
( Linked Adaptation Congestion Control Algorithm for MPTCP",) s
5 704 M
( draft-walid-mptcp-congestion-control-04 \(work in) s
5 693 M
( progress\), January 2016.) s
5 671 M
( [I-D.wei-mptcp-proxy-mechanism]) s
5 660 M
( Wei, X., Xiong, C., and E. Ed, "MPTCP proxy mechanisms",) s
5 649 M
( draft-wei-mptcp-proxy-mechanism-02 \(work in progress\),) s
5 638 M
( June 2015.) s
5 616 M
( [ICNP12] Cao, Y., Xu, M., and X. Fu, "Delay-based congestion) s
5 605 M
( control for multipath TCP", 20th IEEE International) s
5 594 M
( Conference on Network Protocols \(ICNP\) , 2012.) s
5 572 M
( [IMC11] Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A.,) s
5 561 M
( Handley, M., and H. Tokuda, "Is it still possible to) s
5 550 M
( extend TCP?", Proceedings of the 2011 ACM SIGCOMM) s
5 539 M
( conference on Internet measurement conference \(IMC '11\) ,) s
5 528 M
( 2011, <http://doi.acm.org/10.1145/2068816.2068834>.) s
5 506 M
( [IMC13a] Detal, G., Hesmans, B., Bonaventure, O., Vanaubel, Y., and) s
5 495 M
( B. Donnet, "Revealing Middlebox Interference with) s
5 484 M
( Tracebox", Proceedings of the 2013 ACM SIGCOMM conference) s
5 473 M
( on Internet measurement conference , 2013,) s
5 462 M
( <http://inl.info.ucl.ac.be/publications/) s
5 451 M
( revealing-middlebox-interference-tracebox>.) s
5 429 M
( [IMC13b] Chen, Y., Lim, Y., Gibbens, R., Nahum, E., Khalili, R.,) s
5 418 M
( and D. Towsley, "A measurement-based study of MultiPath) s
5 407 M
( TCP performance over wireless network", Proceedings of the) s
5 396 M
( 2013 conference on Internet measurement conference \(IMC) s
5 385 M
( '13\) , n.d., <http://doi.acm.org/10.1145/2504730.2504751>.) s
5 363 M
( [IMC13c] Pelsser, C., Cittadini, L., Vissicchio, S., and R. Bush,) s
5 352 M
( "From Paris to Tokyo on the suitability of ping to measure) s
5 341 M
( latency", Proceedings of the 2013 conference on Internet) s
5 330 M
( measurement conference \(IMC '13\) , 2013,) s
5 319 M
( <http://doi.acm.org/10.1145/2504730.2504765>.) s
5 297 M
( [INFOCOM14]) s
5 286 M
( Lim, Y., Chen, Y., Nahum, E., Towsley, D., and K. Lee,) s
5 275 M
( "Cross-Layer Path Management in Multi-path Transport) s
5 264 M
( Protocol for Mobile Devices", IEEE INFOCOM'14 , 2014.) s
5 242 M
( [IOS7] "Multipath TCP Support in iOS 7", January 2014,) s
5 231 M
( <http://support.apple.com/kb/HT5977>.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 25]) s
_R
S
%%Page: (26) 26
%%BeginPageSetup
_S
24 24 translate
/pagenum 26 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( [KT] Seo, S., "KT's GiGA LTE", July 2015,) s
5 726 M
( <https://www.ietf.org/proceedings/93/slides/slides-93-) s
5 715 M
( mptcp-3.pdf>.) s
5 693 M
( [MBTest] Hesmans, B., "MBTest", 2013,) s
5 682 M
( <https://bitbucket.org/bhesmans/mbtest>.) s
5 660 M
( [MPTCPBIB]) s
5 649 M
( Bonaventure, O., "Multipath TCP - An annotated) s
5 638 M
( bibliography", Technical report , April 2015,) s
5 627 M
( <https://github.com/obonaventure/mptcp-bib>.) s
5 605 M
( [Mobicom15]) s
5 594 M
( De Coninck, Q., Baerts, M., Hesmans, B., and O.) s
5 583 M
( Bonaventure, "Poster - Evaluating Android Applications) s
5 572 M
( with Multipath TCP", Mobicom 2015 \(Poster\) , September) s
5 561 M
( 2015.) s
5 539 M
( [MultipathTCP-Linux]) s
5 528 M
( Paasch, C., Barre, S., and . et al, "Multipath TCP) s
5 517 M
( implementation in the Linux kernel", n.d.,) s
5 506 M
( <http://www.multipath-tcp.org>.) s
5 484 M
( [NSDI11] Wischik, D., Raiciu, C., Greenhalgh, A., and M. Handley,) s
5 473 M
( "Design, implementation and evaluation of congestion) s
5 462 M
( control for Multipath TCP", In Proceedings of the 8th) s
5 451 M
( USENIX conference on Networked systems design and) s
5 440 M
( implementation \(NSDI11\) , 2011.) s
5 418 M
( [NSDI12] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M.,) s
5 407 M
( Duchene, F., Bonaventure, O., and M. Handley, "How Hard) s
5 396 M
( Can It Be? Designing and Implementing a Deployable) s
5 385 M
( Multipath TCP", USENIX Symposium of Networked Systems) s
5 374 M
( Design and Implementation \(NSDI12\) , April 2012,) s
5 363 M
( <http://inl.info.ucl.ac.be/publications/how-hard-can-it-) s
5 352 M
( be-designing-and-implementing-deployable-multipath-tcp>.) s
5 330 M
( [PAM2016] De Coninck, Q., Baerts, M., Hesmans, B., and O.) s
5 319 M
( Bonaventure, "A First Analysis of Multipath TCP on) s
5 308 M
( Smartphones", 17th International Passive and Active) s
5 297 M
( Measurements Conference \(PAM2016\) , March 2016,) s
5 286 M
( <http://inl.info.ucl.ac.be/publications/) s
5 275 M
( first-analysis-multipath-tcp-smartphones>.) s
5 253 M
( [PAMS2014]) s
5 242 M
( Arzani, B., Gurney, A., Cheng, S., Guerin, R., and B. Loo,) s
5 231 M
( "Impact of Path Selection and Scheduling Policies on MPTCP) s
5 220 M
( Performance", PAMS2014 , 2014.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 26]) s
_R
S
%%Page: (27) 27
%%BeginPageSetup
_S
24 24 translate
/pagenum 27 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( [PaaschPhD]) s
5 726 M
( Paasch, C., "Improving Multipath TCP", Ph.D. Thesis ,) s
5 715 M
( November 2014, <http://inl.info.ucl.ac.be/publications/) s
5 704 M
( improving-multipath-tcp>.) s
5 682 M
( [Presto08]) s
5 671 M
( Greenberg, A., Lahiri, P., Maltz, D., Parveen, P., and S.) s
5 660 M
( Sengupta, "Towards a Next Generation Data Center) s
5 649 M
( Architecture - Scalability and Commoditization", ACM) s
5 638 M
( PRESTO 2008 , August 2008,) s
5 627 M
( <http://dl.acm.org/citation.cfm?id=1397732>.) s
5 605 M
( [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",) s
5 594 M
( RFC 1812, DOI 10.17487/RFC1812, June 1995,) s
5 583 M
( <http://www.rfc-editor.org/info/rfc1812>.) s
5 561 M
( [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and) s
5 550 M
( L. Jones, "SOCKS Protocol Version 5", RFC 1928, DOI) s
5 539 M
( 10.17487/RFC1928, March 1996,) s
5 528 M
( <http://www.rfc-editor.org/info/rfc1928>.) s
5 506 M
( [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common) s
5 495 M
( Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,) s
5 484 M
( <http://www.rfc-editor.org/info/rfc4987>.) s
5 462 M
( [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.) s
5 451 M
( Iyengar, "Architectural Guidelines for Multipath TCP) s
5 440 M
( Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,) s
5 429 M
( <http://www.rfc-editor.org/info/rfc6182>.) s
5 407 M
( [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled) s
5 396 M
( Congestion Control for Multipath Transport Protocols", RFC) s
5 385 M
( 6356, DOI 10.17487/RFC6356, October 2011,) s
5 374 M
( <http://www.rfc-editor.org/info/rfc6356>.) s
5 352 M
( [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,) s
5 341 M
( "TCP Extensions for Multipath Operation with Multiple) s
5 330 M
( Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,) s
5 319 M
( <http://www.rfc-editor.org/info/rfc6824>.) s
5 297 M
( [SIGCOMM11]) s
5 286 M
( Raiciu, C., Barre, S., Pluntke, C., Greenhalgh, A.,) s
5 275 M
( Wischik, D., and M. Handley, "Improving datacenter) s
5 264 M
( performance and robustness with multipath TCP",) s
5 253 M
( Proceedings of the ACM SIGCOMM 2011 conference , n.d.,) s
5 242 M
( <http://doi.acm.org/10.1145/2018436.2018467>.) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 27]) s
_R
S
%%Page: (28) 28
%%BeginPageSetup
_S
24 24 translate
/pagenum 28 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( [StrangeMbox]) s
5 726 M
( Bonaventure, O., "Multipath TCP through a strange) s
5 715 M
( middlebox", Blog post , January 2015,) s
5 704 M
( <http://blog.multipath-tcp.org/blog/html/2015/01/30/) s
5 693 M
( multipath_tcp_through_a_strange_middlebox.html>.) s
5 671 M
( [TMA2015] Hesmans, B., Tran Viet, H., Sadre, R., and O. Bonaventure,) s
5 660 M
( "A First Look at Real Multipath TCP Traffic", Traffic) s
5 649 M
( Monitoring and Analysis , 2015,) s
5 638 M
( <http://inl.info.ucl.ac.be/publications/) s
5 627 M
( first-look-real-multipath-tcp-traffic>.) s
5 605 M
( [ietf88] Stewart, L., "IETF'88 Meeting minutes of the MPTCP working) s
5 594 M
( group", n.d., <http://tools.ietf.org/wg/mptcp/) s
5 583 M
( minutes?item=minutes-88-mptcp.html>.) s
5 561 M
( [tracebox]) s
5 550 M
( Detal, G. and O. Tilmans, "tracebox", 2013,) s
5 539 M
( <http://www.tracebox.org>.) s
5 517 M
(Appendix A. Changelog) s
5 495 M
( This section should be removed before final publication) s
5 473 M
( o initial version : September 16th, 2014 : Added section Section 3.8) s
5 462 M
( that discusses some performance problems that appeared with the) s
5 451 M
( Linux implementation when using subflows having different MSS) s
5 440 M
( values) s
5 418 M
( o update with a description of the middlebox that replaces an) s
5 407 M
( unknown TCP option with EOL [StrangeMbox]) s
5 385 M
( o version ietf-02 : July 2015, answer to last call comments) s
5 363 M
( * Reorganised text to better separate use cases and operational) s
5 352 M
( experience) s
5 330 M
( * New use case on Multipath TCP proxies in Section 2.3) s
5 308 M
( * Added some text on middleboxes in Section 3.1) s
5 286 M
( * Removed the discussion on SDN) s
5 264 M
( * Restructured text and improved writing in some parts) s
5 242 M
( o version ietf-03 : September 2015, answer to comments from Phil) s
5 231 M
( Eardley) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 28]) s
_R
S
%%Page: (29) 29
%%BeginPageSetup
_S
24 24 translate
/pagenum 29 def
/fname (draft-bonaventure-mptcp-experience.txt) def
/fdir (.) def
/ftail (draft-bonaventure-mptcp-experience.txt) def
/user_header_p false def
/user_footer_p false def
%%EndPageSetup
5 770 M
(Internet-Draft MPTCP Experience April 2016) s
5 737 M
( * Improved introduction) s
5 715 M
( * Added details about using SOCKS and Korea Telecom's use-case in) s
5 704 M
( Section 2.3.) s
5 682 M
( * Added issue around clients caching DNS-results in Section 3.9) s
5 660 M
( * Explained issue of MPTCP with stateless webservers Section 3.11) s
5 638 M
( * Added description of MPTCP's use behind layer-4 loadbalancers) s
5 627 M
( Section 3.12) s
5 605 M
( * Restructured text and improved writing in some parts) s
5 583 M
( o version ietf-04 : April 2016, answer to last comments) s
5 561 M
( * Updated text on measurements with smartphones) s
5 539 M
( * Updated conclusion) s
5 517 M
(Authors' Addresses) s
5 495 M
( Olivier Bonaventure) s
5 484 M
( UCLouvain) s
5 462 M
( Email: Olivier.Bonaventure@uclouvain.be) s
5 429 M
( Christoph Paasch) s
5 418 M
( Apple, Inc.) s
5 396 M
( Email: cpaasch@apple.com) s
5 363 M
( Gregory Detal) s
5 352 M
( Tessares) s
5 330 M
( Email: Gregory.Detal@tessares.net) s
5 176 M
(Bonaventure, et al. Expires October 3, 2016 [Page 29]) s
_R
S
%%Trailer
%%Pages: 29
%%DocumentNeededResources: font Courier-Bold Courier
%%EOF
| PAFTECH AB 2003-2026 | 2026-04-24 02:57:22 |