MPTCP as seen by IETF - overview Miroslav Popovic March 17, 2011 - - PowerPoint PPT Presentation

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges

MPTCP as seen by IETF - overview

Miroslav Popovic March 17, 2011

Miroslav Popovic MPTCP as seen by IETF - overview 1/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges

Table of contents

1 Introduction and motivation

Introduction Motivation

2 MPTCP

MPTCP basics MPTCP operation

3 Middleboxes 4 Coupled congestion control

Motivation Road to solution

5 Benefits and new challenges

Miroslav Popovic MPTCP as seen by IETF - overview 2/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Introduction Motivation

Introduction

The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. The primary output of the group will be the protocol extensions needed to deploy MPTCP, and adaptations to congestion control to safely support multipath resource sharing. Initially the WG will only produce documents that are experimental or informational. (From the MPTCP workgroup web page)

Miroslav Popovic MPTCP as seen by IETF - overview 3/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Introduction Motivation

Resource pooling principle

Resource pooling <=> making a collection of resources behave like a single pooled resource. Goal is to increase the robustness in case of failures or congestions, better handling of bursts of traffic, better utilization of resources. Some examples: statistical multiplexing through packet switching, dynamic alternative routing, multihoming, load balancing... Problems with scalabilty, speed of responsivness, lack of global picture...

Miroslav Popovic MPTCP as seen by IETF - overview 4/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges MPTCP basics MPTCP operation

What is MPTCP?

MPTCP is a set of extensions to regular TCP to allow a transport connection to operate across multiple paths simultaneously. Protocol changes are needed for signalling and setting up multiple subflows, their management, reassembly of data and session termination. Design assumptions Backwards compatible to increase the chances of deployment (middleboxes, existing applications, fall-back to regular TCP). At least one endpoint is multihomed and multiaddressed (there is no necessity for entirely disjoint paths).

Miroslav Popovic MPTCP as seen by IETF - overview 5/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges MPTCP basics MPTCP operation

Regular TCP vs MPTCP - Networking Stack

MPTCP operates at the transport layer and should be transparent to higher and lower layers.

Miroslav Popovic MPTCP as seen by IETF - overview 6/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges MPTCP basics MPTCP operation

How does it work?

MPTCP operations are signalled using optional TCP header fields. Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a single path as regular TCP. MPTCP connection is identified by the first subflow even if that path becomes unavailable later. Multiple addresses => multiple paths (they do not have to be entirely disjoint). Path management for discovery end subflow setup; initiation and adress signalling. Additional subsockets are not visible by application layer.

Miroslav Popovic MPTCP as seen by IETF - overview 7/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges MPTCP basics MPTCP operation

Specific features of MPTCP

Possibility to mark some subflows as a backup (hot standby). Status of a particular link can be changed during the

• peration.

This option appeared in the latest version of the draft (not implemented yet). Data Sequence Mapping option defines the mapping from the data sequence number to the subflow sequence number. This option specifies a full mapping from data sequence number to subflow sequence number, informing the receiver that there is a one-to-one correspondence between the two sequence spaces for the specified length.

Miroslav Popovic MPTCP as seen by IETF - overview 8/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges

What if intermediate devices behave different from what we expect?

NATs, firewalls, proxies... Possible problems are: stripping unknown options, dropping packets with unknown options, manipulation with options during segmentation and reassembling... MPTCP design takes into account ”reasonable” existing middlebox behaviour. MPTCP is able to handle these scenarios (sometimes by falling back to regular TCP behaviour).

Miroslav Popovic MPTCP as seen by IETF - overview 9/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Design goals for the MPTCP congestion control algorithm

Goal 1 (Improve Throughput) A multipath flow should perform at least as well as a single path flow would on the best of the paths available to it. Goal 2 (Do no harm) A multipath flow should not take up more capacity on any one of its paths than if it was a single path flow using only that route. This guarantees it will not unduly harm

• ther flows.

Goal 3 (Balance congestion) A multipath flow should move as much traffic as possible off its most congested paths, subject to meeting the first two goals.

Miroslav Popovic MPTCP as seen by IETF - overview 10/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Theoretical analysis of coordinated congestion controler

Multi-path congestion control algorithm is proposed in [Kelly and Voice, 2005] (simple increase/decrease rules). Stability analysis under the assumption that fluid models are an appropriate description of the system establishes stability condition. Every subflow has its own congestion window but the congestion control parameters are linked in order to achieve resource pooling.

Miroslav Popovic MPTCP as seen by IETF - overview 11/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

”Fully linked” MPTCP algorithm

This algorithm for coordinated congestion controler is in the spirit

• f the findings mentioned on previous slide.

Regular TCP In case of positive ACK: CWND ← CWND + 1 In case of loss: CWND ← CWND/2 ”Fully linked” MPTCP algorithm In case of positive ACK: CWNDi ← CWNDi + CWNDi/CWNDTOT

• i

CWNDi CWNDTOT = 1 => same as regular TCP

In case of loss: CWNDi ← CWNDi − CWNDTOT/2 same as regular TCP

Miroslav Popovic MPTCP as seen by IETF - overview 12/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Example 1: ”Fully linked” algorithm is unstable?

Scenario: Two MPTCP flows sharing the same link, there is a loss whenever w1 + w2 = 100, increases as before, decreases for 1/4 of the total congestion window. Starting at w1 = w2 = 1, increases until w1 = w2 = 50 when loss

• ccurs on path 1. The result is w1 = 25, w2 = 50. 2nd observed

loss will occur for w1 = 33, w2 = 67. If it is on path 1 the result is w1 = 33 − 100/4 = 8, w2 = 67 It takes 5 consecutive drops on path 2 for windows to equalize. Even if the 2nd observed loss was on path 2 the result would be 33 = w1 < w2 = 66 − 25 = 41.

Miroslav Popovic MPTCP as seen by IETF - overview 13/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Example 1: Two consecutive drops on path 1

Miroslav Popovic MPTCP as seen by IETF - overview 14/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

”Fully linked” MPTCP achieves resource pooling (left figure) but is unstable (right figure - flappiness)

Single connection with two paths. Packets are dropped randomly according to an inhomogeneous Poisson process.

Miroslav Popovic MPTCP as seen by IETF - overview 15/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

MPTCP ”uncoupled” algorithm

The case of uncoordinated congestion controler where every subflow behaves as regular TCP no matter what is the situation on

• ther subflows.

Regular TCP In case of positive ACK: CWND ← CWND + 1 In case of loss: CWND ← CWND/2 MPTCP ”uncoupled” algorithm In case of positive ACK: CWNDi ← CWNDi + 1 In case of loss: CWNDi ← CWNDi/2

Miroslav Popovic MPTCP as seen by IETF - overview 16/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

MPTCP ”uncoupled” => stable but no resource pooling

Worse path unaware there exists better path where we might move the traffic.

Miroslav Popovic MPTCP as seen by IETF - overview 17/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

”Linked increases” MPTCP algorithm

Compromise between ”Fully linked” and ”uncoupled” MPTCP algorithm. Regular TCP In case of positive ACK: CWND ← CWND + 1 In case of loss: CWND ← CWND/2 ”Linked increases” MPTCP algorithm In case of positive ACK: CWNDi ← CWNDi + CWNDi/CWNDTOT

• i

CWNDi CWNDTOT = 1 same as regular TCP

In case of loss: CWNDi ← CWNDi/2

Miroslav Popovic MPTCP as seen by IETF - overview 18/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

”Linked increases” is a reasonable compromise between flappiness and load shifting

Miroslav Popovic MPTCP as seen by IETF - overview 19/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Example 2: ”Linked increases” needs some more tuning (1)

In equilibrium, the increases and decreases should balance out. Regular TCP:

1 wTCP = p wTCP 2

⇒ wTCP =

• 2

p

”Linked Increases”:

1 w = pi wi 2 ⇒ wi = 2 wpi

In case we have 2 paths with p1 = p2 = p: w1 =

2 wp1 , w2 = 2 wp2 ,

w = w1 + w2 ⇒ w1 = w2 =

1 √p

Multipath flows aggregate bandwidth should be the same bandwidth as a regular TCP flow would get on the best path available to the multipath flow.

Miroslav Popovic MPTCP as seen by IETF - overview 20/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Example 2: ”Linked increases” needs some more tuning (2)

Scenario 1: RTT1 = RTT2 = RTT Regular TCP on a better path: θTCP = wTCP

RTT = √ 2 √pRTT

MPTCP: θ =

w1 RTT + w2 RTT = 1 √pRTT + 1 √pRTT = 2 √pRTT = θTCP

Scenario 2: RTT1 = RTT, RTT2 = 10RTT Regular TCP on a better path: θTCP = wTCP

RTT = √ 2 √pRTT

MPTCP: θ =

w1 RTT + w2 10RTT = 1 √pRTT + 1 10√pRTT = 11 10√pRTT = θTCP

The solution is to scale the increase function.

Miroslav Popovic MPTCP as seen by IETF - overview 21/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Scaled ”Linked increases” MPTCP algorithm [Raiciu 2010]

Regular TCP In case of positive ACK: CWND ← CWND + 1 In case of loss: CWND ← CWND/2 Scaled ”Linked increases” MPTCP algorithm In case of positive ACK: CWNDi ← CWNDi + a · CWNDi/CWNDTOT In case of loss: CWNDi ← CWNDi/2

Miroslav Popovic MPTCP as seen by IETF - overview 22/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Calculating scaling factor a

Fixed point equation a CWNDTOT = pi CWNDi 2 ⇒ pi = 2a CWNDi · CWNDTOT MPTCP equal as best possible regular TCP

• i

CWNDi RTTi = max

i

wTCP

i

RTTi , wTCP

i

≈

• 2/pi

The result a = CWNDTOT   max

i

√CWNDi/RTTi

• r CWNDi/RTTi

 

2

Miroslav Popovic MPTCP as seen by IETF - overview 23/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Example 2: ”Linked increases” needs some more tuning (3)

In equilibrium, the increases and decreases should balance out. Regular TCP:

1 wTCP = p wTCP 2

⇒ wTCP =

• 2

p

”Linked Increases”:

a w = pi wi 2 ⇒ wi = 2a wpi

In case we have 2 paths with p1 = p2 = p: w1 =

2a wp1 , w2 = 2a wp2 ,

w = w1 + w2 ⇒ w1 = w2 =

√a √p

Multipath flows aggregate bandwidth should be the same bandwidth as a regular TCP flow would get on the best path available to the multipath flow.

Miroslav Popovic MPTCP as seen by IETF - overview 24/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Example 2: ”Linked increases” needs some more tuning (4)

Scenario 1: RTT1 = RTT2 = RTT Regular TCP on a better path: θTCP = wTCP

RTT = √ 2 √pRTT

MPTCP: θ = θ1 + θ2 =

w1 RTT + w2 RTT = √a √pRTT + √a √pRTT = 2√a √pRTT

θ = θTCP ⇒ a = 0.5 Scenario 2: RTT1 = RTT, RTT2 = 10RTT Regular TCP on a better path: θTCP = wTCP

RTT = √ 2 √pRTT

MPTCP: θ = θ1 + θ2 =

w1 RTT + w2 10RTT = √a √pRTT + √a 10√pRTT = 11√a 10√pRTT

θ = θTCP ⇒ a = 1.65

Miroslav Popovic MPTCP as seen by IETF - overview 25/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Example 3: Dropping probability is changed

Scenario 1: RTT1 = RTT2 = RTT, p1 = p2 = p Regular TCP on a better path: θTCP = wTCP

RTT = √ 2 √pRTT

MPTCP: θ = θ1 + θ2 =

w1 RTT + w2 RTT = √a √pRTT + √a √pRTT = 2√a √pRTT

θ = θTCP ⇒ a = 0.5 Scenario 2: RTT1 = RTT2 = RTT, p1 = p, p2 = 10p Regular TCP on a better path: θTCP = wTCP

RTT = √ 2 √pRTT

MPTCP: θ =

w1 RTT + w2 10RTT = 10 11

• 22

10 √a √pRTT + 1 11

• 22

10 √a 10√pRTT =

• 22

10 √a √pRTT , θ = θTCP ⇒ a = 0.91

Miroslav Popovic MPTCP as seen by IETF - overview 26/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

MPTCP in practice - the increase formula from IETF draft

Only the increase phase of the congestion avoidance is affected. For each ack received on subflow i, increase cwndi by CWNDi = CWNDi+min

• α · bytes acked · MSSi

TOTCWND , bytes acked · MSSi CWNDi

• α can be arbitrarily large. Minimum between the computed

increase for the multipath subflow, and the increase regular TCP would get is taken. Hence, any multipath subflow cannot be more aggressive than a regular TCP flow in the same circumstances (goal 2 - do no harm).

Miroslav Popovic MPTCP as seen by IETF - overview 27/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

Tuning the agressiveness as in IETF draft

α is a parameter of the algorithm that describes the aggresiveness

• f the multipath flow.

α = TOTCWND · max

i CWNDi RTT 2

i

• i

CWNDi RTTi

2 α is chosen such that the aggregate throughput of the multipath flow is equal to the rate a TCP flow would get if it ran on the best path (goal 1 - improve throughput).

Miroslav Popovic MPTCP as seen by IETF - overview 28/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges Motivation Road to solution

It works!

MPTCP patch for Linux implemented by groups from Universit´ e catholique de Louvain and University College London. Authors claim that ”Linked Increases” gets throughput within +/ − 10% of best regular TCP (based on extensive experiments). We have working demo.

Miroslav Popovic MPTCP as seen by IETF - overview 29/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges

MPTCP benefits and ideas for future work

Solves the problem of handovers. Different traffic engineering possibilities (throughput maximization, load balancing, cost minimization...). Multipath-aware retransmission mechanisms on subflow level might improve the performance. Selection of paths to be used by MPTCP. Using all available subflows might be suboptimal. Evaluation of MPTCP performance in reality and interactions with middleboxes. ...

Miroslav Popovic MPTCP as seen by IETF - overview 30/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges

References I

Wischik, Damon and Handley, Mark and Braun, Marcelo Bagnulo The resource pooling principle SIGCOMM Comput. Commun. Rev., 2008.

• A. Ford, C. Raiciu, M. Handley

TCP Extensions for Multipath Operation with Multiple Addresses IETF Internet draft, 2011. Damon Wischik, Mark Handley and Costin Raiciu Control of multipath TCP and optimization of multipath routing in the Internet

• Proc. NetCOOP, 2009.

Miroslav Popovic MPTCP as seen by IETF - overview 31/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges

References II

• C. Raiciu, M. Handley, D. Wischik

Coupled Congestion Control for Multipath Transport Protocols IETF Internet draft, 2011. Jean-Yves Le Boudec Rate adaptation, Congestion Control and Fairness: A Tutorial EPFL lecture notes, 2010.

• C. Raiciu, M. Handley, D. Wischik

Practical Congestion Control for Multipath Transport Protocols UCL Technical Report , 2010.

Miroslav Popovic MPTCP as seen by IETF - overview 32/ 33

Introduction and motivation MPTCP Middleboxes Coupled congestion control Benefits and new challenges

References III

Frank Kelly and Thomas Voice Stability of end-to-end algorithms for joint routing and rate control Computer Communication Review 35:2 (2005) 5-12. , 2005.

Miroslav Popovic MPTCP as seen by IETF - overview 33/ 33