CRAWDAD uclouvain/mptcp_smartphone

Multipath TCP is a recent TCP extension that enables multihomed hosts like smartphones to send and receive data over multiple interfaces. Despite the growing interest in this new TCP extension, little is known about its behavior with real applications in wireless networks. Our paper "A First Analysis of Multipath TCP on Smartphones" analyzes a trace from a SOCKS proxy serving smartphones using Multipath TCP. This first detailed study of real Multipath TCP smartphone traffic reveals several interesting points about its behavior in the wild. It confirms the heterogeneity of wireless and cellular networks which influences the scheduling of Multipath TCP. The analysis shows that most of the additional subflows are never used to send data. The amount of reinjections is also quantified and shows that they are not a major issue for the deployment of Multipath TCP. With our methodology to detect handovers, around a quarter of the connections using several subflows experience data handovers.

last modified : 2016-03-04

nickname : mptcp_smartphone

institution : Université catholique de Louvain

release date : 2016-03-04

date/time of measurement start : 2015-03-08

date/time of measurement end : 2015-04-28

collection environment : The dataset covers the traffic produced by a dozen of users using Nexus 5 smartphones running Android~4.4 with a modified Linux kernel that includes Multipath TCP v0.89.5. These users were either professors, PhD or Master students at Université catholique de Louvain-la-Neuve. While some of them used their device to go only on the Internet, others are still using them as their main phone.

network configuration : All the TCP traffic is relayed to a Multipath TCP capable SOCKS proxy. This allows smartphones to use Multipath TCP.

data collection methodology : Tcpdump with a filter containing only TCP packets. Note that the trace contains both proxy sides, i.e. smartphone side and real server one.

sanitization : We first remove all packets that are not from/to smartphone side. In other words, we removed all packets where the real remote server was involved. To do this, we check the SYN and SYN/ACK of connections to label them as interesting or not. Note that in this process, packets without SYN or SYN/ACK in the same file were removed. The following modifications were then applied on the filtered traces to anonymize them: * MAC addresses: set to 00:00:00:00:00:00 * IP addresses: bytewise hasing with HMAC-SHA1 (prefix-preserving) * IP Type of Service: set to 0 * IP options: removed * TCP MPTCP ADD_ADDRESS option: set private IP to 0.0.0.0 (or ::0 if advertising IPv6 address); if not private, bytewise hashing with same HMAC-SHA1 than IP addresses. * TCP payload: removed * Checksums are recomputed on anonymized packets and bad original checksums are left bad in anonymized packets. You can find our anonymization software (PktAnon with some adaptation to keep it MPTCP aware) here: https://bitbucket.org/qdeconinck/packet-anonymizer

limitation : If packets of a connection are spread on two files, say f1 and f2, if the SYN and SYN/ACK are contained in f1, all remaining packets in f2 are removed (due to sanitization).

Traceset

uclouvain/mptcp_smartphone/mptcp_smartphone

Multipath TCP traces from real smartphone users

• files: mptcp-dump_20150408_14121311.pcap.gz, mptcp-dump_20150408_14121315.pcap.gz, mptcp-dump_20150408_14121306.pcap.gz, mptcp-dump_20150408_14121312.pcap.gz, mptcp-dump_20150308_21403709.pcap.gz, mptcp-dump_20150308_21403705.pcap.gz, mptcp-dump_20150408_14121300.pcap.gz, mptcp-dump_20150408_14121307.pcap.gz, mptcp-dump_20150408_14121303.pcap.gz, mptcp-dump_20150308_21403713.pcap.gz, mptcp-dump_20150308_21403712.pcap.gz, mptcp-dump_20150408_14121314.pcap.gz, mptcp-dump_20150405_003247.pcap.gz, mptcp-dump_20150408_14121304.pcap.gz, mptcp-dump_20150408_14121301.pcap.gz, mptcp-dump_20150308_21403702.pcap.gz, mptcp-dump_20150405_002006.pcap.gz, mptcp-dump_20150308_21403710.pcap.gz, mptcp-dump_20150408_14121305.pcap.gz, mptcp-dump_20150308_21403706.pcap.gz, mptcp-dump_20150308_21403707.pcap.gz, mptcp-dump_20150408_14121313.pcap.gz, mptcp-dump_20150408_14121310.pcap.gz, mptcp-dump_20150308_21403700.pcap.gz, mptcp-dump_20150408_14121302.pcap.gz, mptcp-dump_20150308_21403704.pcap.gz, mptcp-dump_20150408_14121308.pcap.gz, mptcp-dump_20150308_21403701.pcap.gz, mptcp-dump_20150408_14121309.pcap.gz, mptcp-dump_20150308_21403708.pcap.gz, mptcp-dump_20150308_21403703.pcap.gz, mptcp-dump_20150308_21403711.pcap.gz
• measurement purpose: Network Performance Analysis, Usage Characterization

uclouvain/mptcp_smartphone/mptcp_smartphone Traces

• mptcp_smartphone:
• format:

  PCAP