MULTIPATH TCP TEST-BED Based on IETF [1] working group MPTCP

04/20/23MPTCP TEST-BED

1

Members of group:

Pham Nguyễn Huy Phương

Nguyen Thi Mai Trang

Từ Minh Mẫn

Đặng Lê Nam

1. Introduction2. Background on MPTCP3. Performance tests4. Test scenarios & Results5. Issues6. Conclusions


2

The main purpose of this project is to test the new release of the MPTCP implementation in the Linux kernel and evaluate the performance of this new protocol. To achieve these goals, our work is: Using Iperf support for a client/server

application with Multipath TCP as transport protocol.

Measuring and analyzing the performance of Multipath TCP in comparison to single-path TCP.


3



4

MPTCP is an under standardization transport protocol which allows a TCP session to use simultaneously multiple available paths. The two key benefits of MPTCP are: To increase the resilience of the connectivity by

providing multiple paths. To increase the efficiency of the resource

usage. Example:


5

INTERNET

Host A Host B

A1

A2B2

B1

Improve Throughput: Multipath TCP must support the simultaneous use of multiple paths.

Improve Resilience: Multipath TCP must support the interchangeable use of multiple paths.


6

Application Compatibility: Follow the same service model as TCP: in-order,

reliable, and byte-oriented delivery. Network Compatibility:

Be compatible with the Internet, including being able to traverse middleboxes such as firewalls, NATs, etc.

Fall back to regular TCP if there is any incompatibility for the multipath transmission over a path.

Compatibility with other Network User: Not illegally harm users using single-path TCP at

shared bottlenecks.


7



8

Using MPTCP, we expect its throughput is improved significantly than when using TCP. Therefore, by using Wireshark, we will analyze the throughput of transmitting data with MPTCP.

When transmission error or packet loss occurs, MPTCP must be able to deal with it (retransmit on another path, etc.). Thus, analyzing the packet loss is also important.

We intend to have a test in which data is transmitted through Internet to observe the MPTCP ability to traverse middleboxes (NATs, Firewalls, etc.).

Some other test scenarios for more precise analysis: The simple cases in which machines connect to each

other directly (each with 2 Ethernet cards or 1 Ethernet card and 1 Wireless card).

Machines connect to each other through a LAN network.


9



10

Expected results: Double throughput in comparison to which of

regular single TCP case.


11

192.168.2.0

192.168.3.0

Server Client


12

MPTCP TCPTest No. 1st 2nd 3rd 1st 2nd 3rd Transmission size

~100 MBytes 1st subflow:

51.5 MBytes 2nd subflow:

48.7 MBytes

1st subflow: 50 MBytes

2nd subflow: 48.9 MBytes

1st subflow: 51.1 MBytes


Throughput 188.2 Mbps 186.2 Mbps 186.4 Mbps 98 Mbps 97.9 Mbps 97.9 Mbps 1st subflow:

96.8 Mbps 2nd subflow:

91.4 Mbps

1st subflow: 94.1 Mbps

2nd subflow: 92.1 Mbps



Transmission time

4.47 sec 4.45 sec 4.45 sec 8.65 sec 8.65 sec 8.65 sec

Total throughput is as doubled as which in single TCP case due to the fact two Ethernet links have the same delay and same length.

Throughput of each subflow is similar to which in single TCP case.


13

Throughput graph of 1st subflow (left) and 2nd subflow (right)


14

The average Cwnd in each subflow is much less than which in single TCP case.

The average RTT in each subflow is much less than which in single TCP case.

MPTCP TCPTest No. 1st 2nd 3rd 1st 2nd 3rd

Subflow No. 1st 2nd 1st 2nd 1st 2nd

Congestion window statistics

max owin (bytes)

81201 49001 109201 56001 117601 100801 372401 371001 364001

avg owin (bytes)

2126 2850 2213 2895 2144 2876 189027 194319 191051

initial window (bytes)

24 1400 24 1400 24 1400 2824 2824 2824

RTT statistics RTT samples 18266 16460 17680 16502 18119 16295 35238 34585 34955RTT min (ms) 0.0 0.0 0.0 0.0 0.0 0.0 0.1 0.2 0.2RTT max (ms) 0.1 15.3 0.1 0.3 0.5 17.6 31.0 31.0 31.0RTT avg (ms) 0.0 0.0 0.0 0.0 0.0 0.0 16.1 16.3 16.2duplicate acks 1 920 1 899 1 875 0 1 0triple dup acks

0 91 0 71 0 82 0 0 0


15

RTTs in case of MPTCP remain stable and are almost the same in each subflow.

RTT graph of 1st subflow (left) and 2nd subflow (right)

Expected results: Lower throughput than which of scenario 1

but still higher than which of single TCP case if delays of 2 links are not much different.


16

192.168.2.0

Server Client192.168.1.0

AP

192.168.1.0


17

MPTCP TCPTest No. 1st 2nd 3rd 4th 1st 2nd 3rd Transmission size

~100 MBytes 1st subflow:

90.76 MBytes 2nd subflow:

3.1 MBytes







Throughput 87.8 Mbps 99.77 Mbps 99.7 Mbps 100.06 Mbps 98 Mbps 97.9 Mbps 97.9 Mbps 1st subflow:

84.9 Mbps 2nd subflow:

2.9 Mbps







Transmission time

8.9 sec 8.4 sec 8.47 sec 8.4 sec 8.65 sec 8.65 sec 8.65 sec

Total throughput is similar to or little larger than which of single TCP case.

Throughput of 2nd subflow is much less than which of 1st subflow and which of single TCP case due to different delays between 2 subflows.


18


MPTCP TCPTest No. 1st 2nd 3rd 4th 1st 2nd 3rd

Subflow No. 1st 2nd 1st 2nd 1st 2nd 1st 2nd


max owin (bytes)

6252401

49001 224001 40601 184801 60201 200201 57401 372401 371001 364001

avg owin (bytes)

9142 20752 91894 16923 91961 20095 91863 23932 189027 194319 191051


2824 4200 2824 3992 24 4200 2824 3992 2824 2824 2824

RTT statistics

RTT samples 32028 1002 34218 1309 34362 1219 34067 1479 35238 34585 34955

RTT min (ms) 0.3 4.3 0.4 4.1 0.4 3.9 0.5 6.4 0.1 0.2 0.2

RTT max (ms) 39.0 197.7 17.7 139.9 46.9 118.6 44.8 136.0 31.0 31.0 31.0

RTT avg (ms) 0.6 51.3 7.8 34.3 7.8 42.6 7.8 45.2 16.1 16.3 16.2

duplicate acks 0 174 0 166 0 132 0 115 0 1 0

triple dup acks

0 12 0 13 0 10 0 7 0 0 0


19

The average Cwnd of 1st subflow is larger than which of 2nd subflow.

The average RTT of 1st subflow is less than which of 2nd subflow.


20

RTT of 1st subflow remains more stable and lower than which of 2nd subflow.


Expected results: Higher throughput than which of single TCP

case.


21

Switch

10.20.21.0

AP

Server Client

10.20.21.0


22

MPTCP TCPTest No. 1st 2nd 3rd 1st 2nd

Testing time 15h 15h 16h 16hTransmission size

~100 MBytes 1st subflow: 97.4

MBytes 2nd subflow: 2.8

MBytes





Throughput 83.9 Mbps 64.24 Mbps 90.47 Mbps 92.5 Mbps 93.2 Mbps 1st subflow: 81.6

Mbps 2nd subflow: 2.3

Mbps





Transmission time

10 sec 13.2 sec 9.18 sec 8.8 sec 8.74 sec

Total throughput of the best case is similar to which in single TCP case.

Throughput of 2nd subflow is almost not considerable in comparison to which of 1st subflow and which in single TCP case.


23



24

MPTCP Single TCPTest No. 1st 2nd 3rd 1st 2nd

Subflow No. 1st 2nd 1st 2nd 1st 2nd


max owin (bytes)

669201 29401 22401 89601 2036801 35001 7123201 22401

avg owin (bytes)

2112 3356 2097 4062 2135 2989 2210 2099


24 1400 24 1400 24 1192 24 24

RTT statistics RTT samples 34586 985 34477 1492 35193 940 33230 35833

RTT min (ms) 0 0 0 0 0 0 0 0

RTT max (ms) 40 39.7 39.6 16.7 0.7 39.6 6.6 6.1

RTT avg (ms) 0 0.3 0 0 0 0.1 0 0

duplicate acks 0 464 0 571 0 448 1 0

triple dup acks

0 5 0 3 0 2 0 0

Numbers of duplicate ACKs in 2nd subflows are large due to transmission delay or transmission loss through the LAN.

The average Cwnd in 2nd subflows are usually larger than which in 1st subflows and in single TCP case. The average RTT in all subflows are almost similar to which in single TCP case.


25

RTT of 1st subflow of MPTCP is more stable and lower than which in case of 2nd subflow of MPTCP.


Expected results: Throughput may be low due to different

delays between 2 links and high loss rate when transmitting through Internet.


26

INTERNET

192.168.1.0 192.168.2.0

Client

192.168.1.0 192.168.2.0

Server

LAN01 LAN02

Single TCP: Done with two LANs, each connects to the Internet. Configure NAT on each router in order to route the

transmitted data to the specified IP address on each LAN. It can work as well as we expected.

MPTCP: Similarly done with two LANs. In this case we tried with

two interfaces, Ethernet card and Wireless card. Data was transmitted over only one interface.

The problem may come from NAT functionality. At a time, NAT can be configured with only one IP address and only one port, while for MPTCP operation, more than one IP address and port is needed.


27



28

Unstability of MPTCP kernel in supporting wireless driver.

TCP Option inconsistency: Based on what we investigated, the used TCP option for

MPTCP transmission is not the same as the current specification of MPTCP.

This difference may come from the fact that the current MPTCP implementation is just the draft version and it may be modified later.


29



30

About MPTCP: MPTCP provides a solution to increase the throughput of data

transmission by making use of all available paths between hosts. MPTCP can be used transparently to the Application layer. MPTCP messages can be easily analyzed through TCP options. Currently MPTCP implementation is not complete; there are still

some inconsistencies between the draft specification and the current implementation.

About our achievements: Understand sufficiently about MPTCP architecture and be able to

apply its implementation to obtain expected results. Get experience of working in group, managing a whole project,

reporting and presenting. Need further investigation about MPTCP for deeper understanding

(coupled congestion control, etc.).


31

[1]: MPTCP specification of Internet Engineering Task Force: http://datatracker.ietf.org/wg/mptcp/

[2]: The IP Network Lab of the Department of Computing Science and Engineering: http://inl.info.ucl.ac.be/mptcp

[3]: Elearning Forum: http://www.5info.vn [4]: tcptrace tool and guideline to analyze TCP dump files :

http://tcptrace.org/ [5]: Transport Next Generation document:

http://tools.ietf.org/html/draft-iyengar-ford-tng-00 [6]: Architecture of MPTCP: http://tools.ietf.org/wg/mptcp/draft-ietf-

mptcp-architecture/ [7]: TCP Extensions for Multipath Operation with Multiple Addresses:

http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-multiaddressed/ [8]: Coupled Congestion Control for MPTCP:

http://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-congestion/


32

THANKS FOR YOUR ATTENTION!


33


34

?

MULTIPATH TCP TEST-BED Based on IETF [1] working group MPTCP

Documents

Transcript of MULTIPATH TCP TEST-BED Based on IETF [1] working group MPTCP