Performance Evaluation of Multipath Performance Evaluation of - - PDF document

Performance Evaluation of Multipath Performance Evaluation of Multipath TCP Linux Implementations

Euroview 2011 Euroview 2011

Amanpreet Singh

• C. Görg, A. Timm-Giel, M. Scharf, T.-R. Banniza

2nd August 2011 Outline

Motivation TCP-based Multipath Protocol Implementations

• MPTCP
• MCTCP

Experimental Setup Experimental Setup

• G-Lab Experimental Facitility - TOMATO

P f E l ti Performance Evaluation Conclusion & Outlook

2 Euroview 2011

2

Motivation

End-hosts are often equipped with multiple interfaces

• allows for deploying multipath transport to increase throughput, improve

resilience and balance congestion in the network [RFC 6182] resilience and balance congestion in the network [RFC 6182]

Internet Internet Access Network ce ce d De Device vice End De End Devi vi Access Netw Access Networ

• rk

k En End nd De d Device vice Access Network En

This has led to the design and development of Multipath TCP solutions

• a set of extensions for TCP that allows spreading of a single TCP flow across

multiple subflows

3 Euroview 2011

3

Multipath TCP Variants

Different solutions were published in the Multipath TCP working group in IETF Different solutions were published in the Multipath TCP working group in IETF as drafts MultiPath TCP (MPTCP) MultiPath TCP (MPTCP) [draft-ietf-mptcp-multiaddressed-03]

• MPTCP’s Linux kernel implementation is open source

[https://scm info ucl ac be/trac/mptcp/downloads]

IP IP MPTCP application

socket API kernel space user space TCP TCP

[https://scm.info.ucl.ac.be/trac/mptcp/downloads]

• each multipath TCP subflow looks to the network as a normal TCP flow
• TCP option field is used for signalling information exchange

IP IP

PayLoad Multi-connection Transport (PLMT) [draft-singh-mptcp-plmt-00]

• user space solution avoids TCP stack modification

TCP

socket API

TCP PLMT application

socket API kernel user space control

TCP

• user space solution, avoids TCP stack modification
• encodes signalling information in the payload

Multiple Connection TCP (MCTCP)

TCP IP TCP IP

kernel space

TCP IP

p ( ) [draft-scharf-mptcp-mctcp-01]

• A hybrid variant transparent in the single-path case
• TCP option field is used only for connection setup

TCP IP

socket API (extended)

TCP IP MCTCP application

socket API kernel space user or kernel space user space

4 Euroview 2011

4

• TCP option field is used only for connection setup

IP IP

Performance Evaluation Setup

Use Topology Management Tool (ToMaTo) - a virtual networking testbed to design and use virtual networking topologies (consisting of devices and connectors) connectors)

• End-hosts (KVM Devices) - KVM virtualization technology with hardware emulated

by qemu

• Network connectivity is through Tinc VPN - Configurable link delay and bandwidth

y g g y

Linux Vanilla Kernel 2.6.32 patched with MCTCP and 2.6.35 patched with MPTCP are used to boot KVM devices MPTCP are used to boot KVM devices Test Strategy

• Client and Server programs in C are used to shape application traffic (10Mbps,

20Mbps or higher)

• Socket buffer size is set to 262,144B to avoid TCP flow control

Li k b d idth i t t 10Mb d d l i i d b t 1 t 100

• Link bandwidth is set to 10Mbps and delay is varied between 1ms to 100ms
• Numerical results are averaged over 5 runs

5 Euroview 2011

5

G-Lab Experimental Facility

http://toma http://tomato german erman-la lab de http://toma http://tomato.ge german-la lab.de de Directly Connected Scenario – Path per subflow

6 Euroview 2011

6

Path per Subflow – Load Distribution

Server Rate 10Mbps Link delay 10ms Cubic Congestion Control

• ss -0%

Server Rate 10Mbps, Link delay 10ms, Cubic Congestion Control

MCTCP MPTCP

Event 3 (EV3): 50-60s Hi h d l f 100

EV3

Event Lo %

Higher delay of 100ms

• n one (red) link

EV2

Event Loss -2%

Event 2 (EV2): 30-40s Packet loss only on one (black) links

vent Loss -5%

Event 1 (EV1): 10-20s Packet loss on both links

EV1

• ss -10%

Ev Event L

7 Euroview 2011

7

MCTCP is robust to link dynamics (packet loss/e2e Delay) and performs fair scheduling over its subflows

Path per Subflow - Background Traffic - 2Mbps

% vent Loss -0%

Client Server MCTCP Traffic

stion Control E

Client Server

Cubic Conges t Loss -10%

MCTCP + UDP Traffic

k Delay 10ms, Even Link

MCTCP can adapt to asymmetric path quality of its subflows and can aggregate the available bandwidth

8 Euroview 2011

8

Path per Subflow – Packet Loss on both Links

MCTCP may use coupled*# congestion control optionally

* draft-ietf-mptcp-congestion-03

9 Euroview 2011

9

draft ietf mptcp congestion 03

# see also MCTCP: A Multipath Transport Shim Layer

Conclusion

Multipath TCP solutions adhere to the requirement goals of the multipath TCP architecture

• increase throughput, more resilient

g p

• ffer reliable, in-order transport being transparent to applications

MCTCP

• is optimized for bulk data transfer (multipath operation is initiated after a short

delay – can introduce overhead)

• is robust to dynamic changes in the network such as variations in the packet

loss rate, end-to-end delay and available bandwidth

• more MCTCP performance results and implementation details are published in

“MCTCP: A Multipath Transport Shim Layer,” M. Scharf and T.-R. Banniza, Gl b 2011 Globecom 2011

MPTCP

• is a kernel-based solution that uses TCP options field for signalling
• is a kernel-based solution that uses TCP options field for signalling
• the current scheduling strategy doesn't seem to work well in all cases
• more elaborate results are presented in „ MultiPath TCP: From Theory to

Practice,“ S. Barre´, C. Paasch, and O. Bonaventure, IFIP Networking, 2011

10 Euroview 2011

10

Practice, S. Barre , C. Paasch, and O. Bonaventure, IFIP Networking, 2011

Outlook

Multipath TCP tests

• with larger network topologies
• in heterogeneous environment
• for different application types

Design Issues

• How many MxTCP subflows?

Criteria to close an nderperforming s bflo

• Criteria to close an underperforming subflow
• Scheduler to minimize reordering between subflows and resulting jitter

Implementation Issues Implementation Issues

• APIs for multipath-aware applications

Both MPTCP and MCTCP implementation work is in progress and hence evolving to provide a better solution for Future Internet demands

11 Euroview 2011

11