MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of...

38
MultiPath TCP: Hands-On Gerrie Veerman - UvA Supervisor: Ronald van der Pol - SARA 05-07-2012 1

Transcript of MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of...

Page 1: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

MultiPath TCP: Hands-On

Gerrie Veerman - UvA Supervisor: Ronald van der Pol - SARA 05-07-2012

1

Page 2: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

What is MultiPath TCP?

• The ability to use multiple paths with the same connection.

2

Page 3: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Making use of Multi-homing

• One could make use of multiple interfaces simultaneously and roam between 3G and WiFi instantly.

3

Page 4: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

The Project

Research Question:

Is the current MPTCP implementation a useful technology for e-science data transfers in the GLIF environment?

Why are we doing this?

• Demand for bandwidth keeps increasing

• MPTCP is still relatively new

• Can MPTCP really make efficient use of multiple paths

• How stable is the current implementation

• First hands-on experience for SARA

4

Page 5: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

History and Present

History:

• Christian Huitema suggested the idea in 1995

• The idea turned into MPTCP around 2006

Present:

• In 2011 the first RFCs appeared

• 1e implementation in the 2.6 Linux kernel in 2011 (higher versions should support it, we used 3.2)

• Currently three RFCs written and four still in draft

• MPTCP is still being developed, discussed and extensively tested

5

Page 6: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

How does MPTCP work?

6

Page 7: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Properties of MPTCP

• MPTCP is actually implemented in TCP option fields

• For middle-boxes MPTCP looks like regular TCP packets

• Applications can use MPTCP as in a regular TCP socket API

• End-hosts need multiple routing tables, one for each path (default gateways)

• One needs higher buffers than with TCP

7

Page 8: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Path Management

• Routes and paths are created by the network not the MPTCP protocol

• After a handshake the first initial subflow is created

• MPTCP shares all available IP addresses with each other and tries to create a full-mesh out of them

• The connections which do not work get dropped

• MPTCP has the ability to add and remove subflows

• Every subflow has its unique subflow ID and keys (SHA-1 is used). 8

Page 9: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

The Goals of MPTCP

1. Improve throughput: Perform at least as well as a single path flow would on the best of the paths available to it.

2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths

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.

9

Page 10: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Congestion

• With TCP:

• With MPTCP:

10

Page 11: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Congestion Algorithm

Should make sure the most efficient paths are taken and meet the design goals of MPTCP

11

Page 12: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Questions we had?

• How is everything configured/addressed/routed?

• How well does the current implementation work?

• Can it handle a LAN and WAN environment?

• How robust is the protocol?

• Can it handle differences in bandwidth?

• How well does MPTCP handle congestion?

12

Page 13: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Created Topology

13

Page 14: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Experiments Experiment Topics:

• Improved throughput

• Robustness

• Congestion and Fairness

• LAN vs WAN environment

What we used:

• Small and large packets (MSS)

• For all our tests we used iperf

• Different sizes for socket buffers

• Increased the maximum buffer size for the kernel (rmem_max, wmem_max, tcp_rmem and tcp_wmem).

14

Page 15: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Throughput

15

LAN LAN

Speed 1Gb/s 1Gb/s

RTT 5ms 5ms

Buffer 6MB 6MB

Min-Buf 2.5MB 2.5MB

MSS 1400 1400

Page 16: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Robustness • Interfaces go UP and DOWN

16

LAN LAN

Speed 1Gb/s 1Gb/s

RTT 5ms 5ms

Buffer 6MB 6MB

Min-Buf 2.5MB 2.5MB

MSS 1400 1400

Page 17: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Balancing

17

• We got both graphs with the exact same experiment LAN LAN LAN

Speed 1Gb/s 1Gb/s 10Gb/s

RTT 5ms 5ms 5ms

Buffer 16MB 16MB 16MB

Min-Buf 15MB 15MB 15MB

MSS 1400 1400 1400

Page 18: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Balancing

18

• MSS and buffers increased LAN LAN LAN

Speed 1Gb/s 1Gb/s 10Gb/s

RTT 5ms 5ms 5ms

Buffer 26MB 26MB 26MB

Min-Buf 15MB 15MB 15MB

MSS 8900 8900 8900

Page 19: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

WAN: Throughput • Increased round trip times

19 0

100

200

300

400

500

600

700

800

900

1000

6 8 10 12 14 16

Ban

dw

idh

t M

b/s

Buffers in MB

300Mb/s Geneve

1Gb/s Geneve

Total

WAN WAN

Speed 300Mb/s 1Gb/s

RTT 35ms 35ms

Buffer Different Different

Min-Buf 10.8MB 10.8MB

MSS 1400 1400

Page 20: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

WAN: Advanced Throughput • Using only the two Geneve links is more optimal

• Big RTT difference +/-170ms

20

0

200

400

600

800

1000

1200

1400

1600

1800

6 12 18 24 30 36 42 48 56 64 72

Ban

dw

idth

Mb

/s

Buffers in MB

300Mb/s Geneve

1Gb/s Geneve

10Gb/s Chicago

Total

WAN WAN WAN

Speed 300Mb/s 1Gb/s 10Gb/s

RTT 35ms 35ms 202ms

Buffer Different Different Different

Min-Buf 570MB 570MB 570MB

MSS 1400 1400 1400

Page 21: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN + WAN: Throughput

• Small difference in RTT +/- 30ms

21

WAN LAN

Speed 1Gb/s 1Gb/s

RTT 35ms 5ms

Buffer 10MB 10MB

Min-Buf 17.5MB 17.5MB

MSS 1400 1400

Page 22: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Fairness

22

• One can see that the bandwidth TCP gets is far below what it ‘should’ get in theory

LAN

Speed 1Gb/s

RTT 5ms

Buffer 6MB

Min-Buf 2.5MB

MSS 1400

Page 23: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Analysis

• Behavior of the different parameters

• Performance dips in graphs

• Window size decreases (packets are dropped)

• Slow server?

• Overflowing buffers?

• Interfaces going UP and DOWN

• MPTCP debug option

• Subflow count stays 1 while it should be 2, no clue why this happens

• Tcpdump/Wireshark

• No clear explanation yet. (indication its due to the socket buffer in combination with the window size)

23

Page 24: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Achievements Experience:

• Kernel froze sometimes, especially when interfaces went up and down

• Can work with both IPv4 and IPv6 simultaneously

• MPTCP seems quite stable overall

Research

• MPTCP meets its goals: improve throughput and balance congestion

• The goal: do no harm is not met perfectly. In our experiments MPTCP is a bit unfair to TCP

• The behavior of MPTCP in different environments with different parameters

24

Page 25: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Conclusion Research Question:

Is the current MPTCP implementation a useful technology for e-science data transfers in the GLIF environment?

• When the e-science environment is stable, uses the same link speeds, has high enough buffers and same RTTs

• MPTCP seems to behave well and gets maximum throughput

• However, when you have a lot of differences in link speeds, buffer sizes and RTTs

• MPTCP may behave less optimal and becomes as good as TCP would get. One should consider if using MPTCP gives any real benefit. However, when robustness is a key factor you can of course make use of MPTCP

• With higher speeds, one would need fast servers and one should put a lot of attention in tweaking all parameters

25

Page 26: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Future work

• More advanced analyzing and testing of the protocol

• Testing against other projects like GridFTP

• The GLIF test-bed topology within SARA

• Run experiments again to verify our results

• Investigate the tuning further

• Try it yourself

26

Page 27: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

27

Page 28: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Backup Slides

28

Page 29: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Congestion Algorithm • Should make sure the most efficient paths are taken and meet

the design goals of MPTCP

8Mb/s

8Mb/s

8Mb/s

Flow 1:1

10Mb/s

10Mb/s

10Mb/s

Flow 4:1

29

Page 30: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

MPTCP Handshake

30

Page 31: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

Buffer calculation

• TCP:

• MPTCP:

• Example: RTT=36ms, 2x 1Gb/s

31

Page 32: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

MPTCP Algorithm

• Window size increase rule is only changed

32

Page 33: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

MPTCP Handover

33

Page 34: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: 2x 10Gb/s Link

34

• One MPTCP

session

• Two MPTCP

sessions

LAN LAN

Speed 10Gb/s 10Gb/s

RTT 5ms 5ms

Buffer 20MB 20MB

Min-Buf 25MB 25MB

MSS 8900 8900

Page 35: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Advanced changes

35 0

1000

2000

3000

4000

5000

6000

7000

8000

9000

10000

11000

12000

1 61 121 181 241 301 361 421 481 541 601 661 721 781 841 901

Ban

dw

idth

Mb

/s

Seconds

10Gb/s LAN

1Gb/s LAN

1Gb/s LAN

In Theory

LAN LAN LAN

Speed 1Gb/s 1Gb/s 10Gb/s

RTT 5ms 5ms 5ms

Buffer 16MB 16MB 16MB

Min-Buf 15MB 15MB 15MB

MSS 1400 1400 1400

Page 36: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Fairness with a TCP session

36

1x 1Gb/s 2x 1Gb/s LAN LAN

Speed 1Gb/s 1Gb/s

RTT 5ms 5ms

Buffer 6MB 6MB

Min-Buf 2.5MB 2.5MB

MSS 1400 1400

Page 37: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Fairness on 2x 1Gb/s links

37 0

200

400

600

800

1000

1200

1400

1600

1800

2000

1 61 121 181 241 301 361 421 481 541

Ban

dw

idth

Mb

/s

Seconds

MPTCP Session

TCP Session

In Theory TCP

LAN LAN

Speed 1Gb/s 1Gb/s

RTT 5ms 5ms

Buffer 6MB 6MB

Min-Buf 2.5MB 2.5MB

MSS 1400 1400

Page 38: MultiPath TCP: Hands-On2. Do no harm: multipath flow should not take up more capacity from any of the resources shared by its different paths 3. Balance congestion: A multipath flow

LAN: Fairness on 2x 1Gb/s links

38 0

200

400

600

800

1000

1200

1400

1600

1800

2000

1 61 121 181 241 301 361 421 481 541 601

Ban

dw

idth

Mb

/s

Seconds

MPTCP Session

TCP 2 Sessions

TCP in Theory

LAN LAN

Speed 1Gb/s 1Gb/s

RTT 5ms 5ms

Buffer 6MB 6MB

Min-Buf 2.5MB 2.5MB

MSS 1400 1400