Introduction

Overview

The Internet is the global system of interconnected computer networks that uses the Internet protocol suite to communicate between networks and devices. It is a network of networks that consists of private, public, academic, business, and government networks of local to global scope, linked by a broad array of electronic, wireless, and optical networking technologies, It is mostly backed by udp/tcp. The Transmission Control Protocol (TCP) is used by the vast majority of applictions to transport their data reliably across the Internet. These applications are and not limited to, http, ftp, scp,sftp. TCP was designed in the 1970s, along with an entire stack of itself called as TCP/Stack and neither mobile devices nor computers with many network interfaces were an immediate design priority.

On the other hand, the TCP designers knew that network links could fail, and they chose to decouple the network-layer protocols (Internet Protocol) from those of the transport layer (TCP) so that the network could reroute packets around failures without affecting TCP connections. Later on a further more advanced layer was designed, which seggregated the complexity a lot more well. This ability to reroute packets is largely due to the use of dynamic routing protocols, and their job is made much easier because they don’t need to know anything about transportlayer connections. The entire layer works by abstraction and functioning well, meaning a layer is only concerned with what it is supposed to do, and need not bother about how the layer above handle the data.

As noted above, the primary purpose of the TCP is to provide reliable, securable logical circuit or connection service between pairs of processes.

To provide this service on top of a less reliable internet communication system requires facilities in the following areas: Basic Data Transfer Reliability Flow Control Multiplexing Connections Precedence and Security The basic operation of the TCP in each of these areas is described in the following paragraphs.

Basic Data Transfer: The TCP is able to transfer a continuous stream of octets in each direction between its users by packaging some number of octets into segments for transmission through the internet system. In general, the TCPs decide when to block and forward data at their own convenience. Sometimes users need to be sure that all the data they have submitted to the TCP has been transmitted. For this purpose a push function is defined. To assure that data submitted to a TCP is actually transmitted the sending user indicates that it should be pushed through to the receiving user. A push causes the TCPs to promptly forward and deliver data up to that point to the receiver. The exact push point might not be visible to the receiving user and the push function does not supply a record boundary marker.

Reliability: The TCP must recover from data that is damaged, lost, duplicated, or delivered out of order by the internet communication system. This is achieved by assigning a sequence number to each octet transmitted, and requiring a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within a timeout interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that may be received out of order and to eliminate duplicates. Damage is handled by adding a checksum to each segment transmitted, checking it at the receiver, and discarding damaged segments. As long as the TCPs continue to function properly and the internet system does not become completely partitioned, no transmission errors will affect the correct delivery of data. TCP recovers from internet communication system errors.

Flow Control: TCP provides a means for the receiver to govern the amount of data sent by the sender. This is achieved by returning a “window” with every ACK indicating a range of acceptable sequence numbers beyond the last segment successfully received. The window indicates an allowed number of octets that the sender may transmit before receiving further permission.

Multiplexing: To allow for many processes within a single Host to use TCP communication facilities simultaneously, the TCP provides a set of addresses or ports within each host. Concatenated with the network and host addresses from the internet communication layer, this forms a socket. A pair of sockets uniquely identifies each connection. That is, a socket may be simultaneously used in multiple connections. The binding of ports to processes is handled independently by each Host. However, it proves useful to attach frequently used processes (e.g., a “logger” or timesharing service) to fixed sockets which are made known to the public. These services can then be accessed through the known addresses. Establishing and learning the port addresses of other processes may involve more dynamic mechanisms.

Connections: The reliability and flow control mechanisms described above require that TCPs initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is uniquely specified by a pair of sockets identifying its two sides. When two processes wish to communicate, their TCP’s must first establish a connection (initialize the status information on each side). When their communication is complete, the connection is terminated or closed to free the resources for other uses. Since connections must be established between unreliable hosts and over the unreliable internet communication system, a handshake mechanism with clock-based sequence numbers is used to avoid erroneous initialization of connections. Precedence and Security: The users of TCP may indicate the security and precedence of their communication. Provision is made for default values to be used when these features are not needed.

   +------+ +-----+ +-----+       +-----+                    
   |Telnet| | FTP | |Voice|  ...  |     |  Application Level 
   +------+ +-----+ +-----+       +-----+                    
         |   |         |             |                       
        +-----+     +-----+       +-----+                    
        | TCP |     | RTP |  ...  |     |  Host Level        
        +-----+     +-----+       +-----+                    
 |           |             |                       
        +-------------------------------+                    
        |    Internet Protocol & ICMP   |  Gateway Level     
        +-------------------------------+                    
             |                                     
+---------------------------+                      
|   Local Network Protocol  |    Network Level     
+---------------------------+                      

           [Figure 1: Protocol Relationships]

Background

Today’s networks are multipath: mobile devices have multiple wireless interfaces, datacenters have many redundant paths between servers, and multihoming has become the norm for big server farms. Meanwhile, TCP is essentially a single-path protocol: when a TCP connection is established, the connection is bound to the IP addresses of the two communicating hosts. If one of these addresses changes, for whatever reason, the connection will fail. In fact, a TCP connection cannot even be load balanced across more than one path within the network, because this results in packet reordering, and TCP misinterprets this reordering as congestion and slows down.

When the Transmission Control Protocol (TCP) was first designed in 1974 as a part of the Internet Protocol Suite, the idea revolved around a single device with a single network connection. Since then the times have changed to supply different demands. In 2014 64% of the American adult population owned a smartphone. A smartphone typically supports both a 2G/3G/4G connection as well as a Wi- Fi connection. Even though smartphones have been around for a series of years, there is a very limited usage of a protocol that utilizes the multiple connections, available on the smartphone, to either aggregate bandwidth or as a reliability tool.

A typically smartphone works by using either the 2G/3G/4G connection or the Wi- Fi connection and then it uses different techniques for the handover or handoff part. None of the most used smartphone operating systems uses multiple connections simultaneously even though the technology already exists. Seen from the users point of view, it might be beneficial sometimes to use all of the available connections, e.g. when downloading a large file, to decrease the download time.

Not only cellphones, even embedded devices such as raspberry pi and laptops (yes laptops make atleast 40% of electronic equipments), these devices are very well equipped with ethernet adapters and wifi adapters. Not only that these devices are well equipped with properly functioning drivers (broadcom on raspberry pi 3b+, rtl8723* series for Hp laptop/netbooks). Not utilising them well is sheer wastage of resources and lack of utilisation.

Multipath TCP (MPTCP) is a major modification to TCP that allows multiple paths to be used simultaneously by a single transport connection. Multipath TCP circumvents the issues mentioned above and several others that affect TCP. Changing TCP to use multiple paths is not a new idea; it was originally proposed more than 15 years ago by Christian Huitema in the Internet Engineering Task Force (IETF), and there have been a half-dozen more proposals since then to similar effect. Multipath TCP draws on the experience gathered in previous work, and goes further to solve issues of fairness when competing with regular TCP and deployment issues as a result of middleboxes in today’s Internet. The Multipath TCP protocol has recently been standardized by the IETF, and an implementation in the Linux kernel is available today.

Overview of MPTCP Operation

The design of Multipath TCP has been influenced by many requirements, but there are two that stand out the most: first is application compatibility and second one is network compatibility. Compatibility of Application basically implies that applications that today run over TCP should work without any change over Multipath TCP, this is to ensure two major functionalities:

Next, Multipath TCP must operate over any Internet path where TCP operates, this means that there is no need to modify the existing infrastructure for switching to MPTCP. Many paths on today’s Internet include middleboxes, such as Network Address Translators, firewalls, and various kinds of transparent proxies. Unlike IP routers, all these devices do know about the TCP connections they forward and affect them in special ways. Designing TCP extensions that can safely traverse all these middleboxes has proven to be challenging. Before diving into the details of Multipath TCP, as we now that the basic operation of normal TCP.

A connection can be divided into three phases:

       +-------------------------------+
       |           Application         |
       +-------------------------------+
    ^                  |
    ~~~~~~~~~~|~Sockets Interface|~~~~~~~~~
    |                  v
       +-------------------------------+
       |             MPTCP             |
       + - - - - - - - + - - - - - - - +
       | Subflow (TCP) | Subflow (TCP) |
       +-------------------------------+
       |       IP      |      IP       |
       +-------------------------------+

        [Figure 2: MPTCP Protocol Stack]

Multipath TCP in the Networking Stack

MPTCP operates at the transport layer and aims to be transparent to both higher and lower layers. It is a set of additional features on top of standard TCP; Figure 3 illustrates this layering. MPTCP is designed to be usable by legacy applications with no changes;

             +-------------------------------+
             |           Application         |
  +---------------+    +-------------------------------+
  |  Application  |    |             MPTCP             |
  +---------------+    + - - - - - - - + - - - - - - - +
  |      TCP      |    | Subflow (TCP) | Subflow (TCP) |
  +---------------+    +-------------------------------+
  |      IP       |    |       IP      |      IP       |
  +---------------+    +-------------------------------+

  [Figure 3: Comparison of Standard TCP and MPTCP Protocol Stacks]

Terminologies

MPTCP Concepts and Working

This section provides a high-level summary of normal operation of MPTCP, and is illustrated by the scenario shown in Figure 4.

     Host A                      Host B
 ------------------------    ------------------------
 Address A1    Address A2    Address B1    Address B2
 ----------    ----------    ----------    ----------
     |            |              |             |
     |  (initial connection)     |             |
     |-------------------------->|             |
     |<--------------------------|             |
     |    |                      |             |
     |   (additional subflow setup)            |
     |    |--------------------->|             |
     |    |<---------------------|             |
     |    |                      |             |
     |    |                      |             |

      [Figure 4: Example MPTCP Usage Scenario]

Problem Statement

As we have seen that MPTCP is a very capable protocol as it enables us usage of multiple interfaces allowing us to effectively utilise the bandwidth and various other features. My problem statement is whether the MPTCP can be brought into the real world effectively and explore the challenges (and overcome them if possible) that might come into the way.

One of the major problems that researchers face upon trying to work on MPTCP is the setting up of a decent environment. No doubt that there are enough resources on the internet which can help one out in setting up of an environment, but they all lack one thing, that is the error resolving techniques. Some of the posts are not even up-to-date to the latest details and updates. The purpose of this research project is simply to set up a basic environment for testing and experimenting with MPTCP. It can also be used by novice users to use MPTCP in their day to day life(as illustrated by title), though it is not recommended. It must be noted that MPTCP is still in its early experimental phase. Fortunately the people are already working on it and making it better.

Also, we will see how to set up the simulation environment of mptcp in Ubuntu machines, along with various other machines as well. The choice of Ubuntu machine is mostly because of its easier usage and easier setup. For other types of available machines, the process almost remains the same (if  its available in the software repository, or else one will have to compile from the source).

Objective and Purpose

Objectively, We want to find and conduct experiments on all possible devices with support for MPTCP, we shall also look into various scheduling algorithms so as to find out the one which is more suited for which sort of purposes.

Along with it, we shall try to see if there is a platform that is not supported and experiment upon supporting it. We shall also look into acquiring details and methodologies to make sure how to obtain them so that the further researchers need not waste time in exploring various scenarios and things unnecessarily.

After setting up the MPTCP environment we shall be working on Multiple algorithms so as to find out the optimal algorithm for multiple scenario.

This certainly involves working with multiple simulators and objects. We are also working on  implementing our own algorithm for scheduling.

We are going to see the installation of MPTCP on every possible machine, then we shall explore the tools, security mechanisms, simulation strategies and various Research tools.This shall save time for the future generation and allow them to focus on creating then experimenting.

Period of Project

The time period of the entire research is one and a half years, and still ongoing. Duration is from December 2018 to February 2020 (Semester 6,7,8)

Scope of Project

Multipath TCP was designed to be backward compatible with regular TCP. As such, it can support any application. However, some specific deployments leverage the ability of simultaneously using different paths.

Apple uses Multipath TCP to support the Siri application on iPhone. Siri sends voice samples over an HTTPS session to Apple servers. Those servers reply with the information requested by the users. According to Apple engineers, the main benefits of Multipath TCP with this application are :

Other deployment use Multipath TCP to aggregate the bandwidth of different networks. For example, several types of smartphones, notably in Korea, use Multipath TCP to bond WiFi and 4G through SOCKS proxies. Another example are the Hybrid Access Networks that are deployed by network operators willing to combine xDSL and LTE networks. In this deployment, Multipath TCP is used to efficiently balance the traffic over xDSL and the LTE network.

In a more simpler terms, MPTCP has also proven well to provide client side load balancing without any need of nulky/costly equipments.

Henceforth, MPTCP not only has extended the capabilities of internet in households but also in industries areas and cloud networking.

Other than these, It has been noted that since the subflows are split across multiple interfaces it prevents even the capturing of packets there by preventing MITM and identical attacks. DNS resolution over MPTCP allows faster internet resolutions, and seggregation of workload enables far more effective utilisation.

If these were not enough, it is something that is even being developed (or rather have its tools developed by NASA itself) Software Details

Literature Review

The first and foremost location from where the entire research began were rfc documents, summaries of each of these is henceforth added:

RFC: 793 TRANSMISSION CONTROL PROTOCOL

This document describes the DoD Standard Transmission Control Protocol (TCP). There have been nine earlier editions of the ARPA TCP specification on which this standard is based, and the present text draws heavily from them. There have been many contributors to this work both in terms of concepts and in terms of text. This edition clarifies several details and removes the end-of-letter buffer-size adjustments, and redescribes the letter mechanism as a push function.

Our Intention upon referring this documentation was to understand the crucial features of transmission control protocol, tcp so as to know what all there is to know about it.

RFC 768 USER DATAGRAM PROTOCOL

In this User Datagram Protocol (UDP) is defined to make available a datagram mode of packet-switched computer communication in the environment of an interconnected set of computer networks. This protocol assumes that the Internet Protocol (IP) is used as the underlying protocol. Though not right away related to MPTCP, we referred it so as to get a decent idea on the thought process that goes in defining a protocol.

RFC 6182 Architectural Guidelines for Multipath TCP Development

In supporting the use of multiple paths, Multipath TCP has the following two functional goals.

RFC 6897 Multipath TCP (MPTCP) Application Interface Considerations

Multipath TCP adds the capability of using multiple paths to a regular TCP session. The motivations for this extension include increasing throughput, overall resource utilization, and resilience to network failure, and these motivations are discussed, along with high-level design decisions, as part of the multipath TCP architecture . MPTCP offers the same reliable, in-order, byte-stream transport as TCP and is designed to be backward compatible with both applications and the network layer. It requires support inside the network stack of both endpoints. This document first presents the effects that MPTCP may have on applications, such as performance changes compared to regular TCP. Second, it defines the interoperation of MPTCP and applications that are unaware of the multipath transport. MPTCP is designed to be usable without any application changes, but some compatibility issues have to be taken into account. Third, this memo specifies a basic Application Programming Interface (API) for MPTCP-aware applications. The API presented here is an extension to the regular TCP API to allow an MPTCP-aware application the equivalent level of control and access to information of an MPTCP connection that would be possible with the standard TCP API on a regular TCP connection.

C. Paasch and S. Barre, “Multipath TCP in the Linux Kernel, available from.” [Online].

This is where most of the interesting things happen, this site and basic implementation of MPTCP has been the core of our entire series of work which allows installation on many devices. Other than that this was also our guide to finding multiple resources and sources for more research papers.

Furthermore it provides a crisp documentation on how to achieve and perform multiple things ranging from documentation to hacks.

“Multipath-tcp patch residence.” [Online].

These are very crucial patches available for NS2/3, https://code.google. com/archive/p/multipath-tcp/downloads

This contains various examples and various things which aid us in patching ns3 with mptcp support.

G.and,“patchforinstallingNS2.”

https://github.com/wangzhizhou/Network-Simulator-Installation-Guideline-For-Ubuntu

This was a comprehensive guide for installing and patching network simulation, albeit it was short on error resolution but it was still a great help and guide.

Reviewing the source code, there were few bits that had to be modified because of different version of GCC, which necessarily meant a lot of coverage and work in installation.

Obviously, it was all worth the effort because the results were astounding.

Paasch, Christoph; Detal, Gregory; Duchene, Fabien; Raiciu, Costin; Bonaventure, Olivier (2012). Exploring mobile/WiFi handover with multipath TCP. ACM SIGCOMM workshop on Cellular Networks (Cellnet’12). p. 31.

DOI:10.1145/2342468.2342476. ISBN 9781450314756.

This Particular paper was revolutionary, it talked about setting up mptcp on mobile phones and a lot many more things, about how to aggregate bandwidth. It also implements a kernel which can be installed and worked through.

C. Paasch; G. Detal; S. Barré; F. Duchêne; O. Bonaventure.“The fastest TCP connection with Multipath TCP”. Retrieved 2013-09-20

There were even more research paper from which substantial amount of data was obtained, ideas more ideas and lots of experiments.

Methodology

Tools and Technologies

The Entire MPTCP has a plethora of tools and technologies to explore the possibilities and perform experiments, these experiments show the nature of MPTCP and its feasibility in the real world. We are not only going to use some standard tools but also going to create a few specialised tools/scripts of our own so as to assist us in parsing as well as fetching the data.

Each of these tools assist us in a specific place, or a specific way so we will be seeing them in that precise order and try to cover as much as we can about the tools

Installation

Linux
                   [Figure 5: Ubuntu Repository]

At client side, a package manager helps installing from and updating the repositories, there are many package managers which fortunately aid us in easier and smooth management of packages. At server side, a software repository is typically managed by source control or repository managers. Some of the repository managers allow to aggregate other repository location into one URL and provide a caching proxy. Such proxies allow faster and efficient access.The repositories can be available in multiple regions so as to facilitate easier hosting and faster access to various locations.When doing continuous builds many artifacts are produced and often centrally stored, so automatically deleting the ones which are not released is important.

Many software publishers and other organizations maintain servers on the Internet for this purpose, either free of charge or for a subscription fee. Repositories may be solely for particular programs, such as CPAN for the Perl programming language, or for an entire operating system.CRAN is also such a repository store for R programming language. Operators of such repositories typically provide a package management system, tools intended to search for, install and otherwise manipulate software packages from the repositories. For example, many Linux distributions use **Advanced Packaging Tool (APT)**, commonly found in Debian based distributions, or yum found in Red Hat based distributions. There are also multiple independent package management systems, such as **pacman, used in Arch Linux** and equo, found in Sabayon Linux. As software repositories are designed to include useful packages, major repositories are designed to be malware free. If a computer is configured to use a digitally signed repository from a reputable vendor, and is coupled with an appropriate permissions system, this significantly reduces the threat of malware to these systems. As a side effect, many systems that have these capabilities do not require anti-malware software such as anti-virus software.

Most major Linux distributions have many repositories around the world that mirror the main repository.

Most of the software repos are well equipped with the MPTCP kernels, which save us from the hassle of compiling it ourselves and fixing it along the way. This reduces the installation which could take over half a day to the matters of few minutes or at worse few hours. Also, it is much safer and less riskier way of setting up MPTCP on machines, and it must be noted that it allows us an even faster means for scripting. Ofcourse, if one needs their own modifications or patches then they must compile and install it.

Android

Simulation Programsamsamsams

Analysis Tools

The tools generate a lot of data, which needs parsing or refinements. Analysis tools are the ones which are used for the same way.

      		       [Figure 12: EtherApe example]

It can filter traffic to be shown, and can read packets from a file as well as live from the network.

Node statistics can be exported.

It is used solely for visualisation purposes.

Research Tools

Data Flow Diagram

Our Entire project is research based, Meaning there is no single straight forward data flow diagram, though the entire experimentation series can be summarized as following diagram.

                  			  [Figure 15: Data flow Diagram]

Since there are no interaction between the classes and processes, as in a program it cannot be fit into a sequence diagram and since its not a program for an end user, this is not supposed to have any use case or use case diagram.

Certainly the process could be used by an end user to get MPTCP up and running onto his machine but that will not pose any benefit without multiple interfaces.

Implementation

As we have seen in our Data flow diagram, the entire process can be broken down into three phases:

Now we shall be seeing each of these phases in great detail and with understanding.

Setup Phase

The setup installation will be performed on following machines/systems:

  1. Linux : primarily Ubuntu and fedora/Arch will be discussed.

  2. Simulation Softwares Such as NS2.

  3. Raspberry pi 3b+ using Arch/Raspibian base.

  4. Vagrant boxes i.e, virtual machines.

  5. progMP on Linux Machines (Debian, Ubuntu).

  6. Android 4.4 kitkat, available implementation will be discussed.

  7. The Tools, their installation will be discussed with their usage wherever they will be used these will be installed as they will be used.

Linux

Linux is an Opensource platform, meaning the changes can be easily done and used, this allows us to effectively develop our own systems without worrying about lawsuits.

For the purpose of simplicity, we shall be considering Ubuntu operating system. Ofcourse, MPTCP has been ported to many systems and can be installed on any linux machine.

About

Ubuntu today

The first official Ubuntu release — Version 4.10, codenamed the ‘Warty Warthog’ — was launched in October 2004, and sparked dramatic global interest as thousands of free software enthusiasts and experts joined the Ubuntu community.

Ubuntu today has many flavours and dozens of specialised derivatives. There are also special editions for servers, OpenStack clouds, and connected devices. All editions share common infrastructure and software, making Ubuntu a unique single platform that scales from consumer electronics to the desktop and up into the cloud for enterprise computing.

The Ubuntu desktop is by far the world’s most widely used Linux workstation platform, powering the work of engineers across the globe. Ubuntu Core sets the standard for tiny, transactional operating systems for highly secure connected devices. Ubuntu Server is the reference operating system for the OpenStack project, and a hugely popular guest OS on AWS, Azure and Google Cloud. Ubuntu is pre-installed on computers from Dell, HP, Asus, Lenovo and other global vendors.

We hope Ubuntu will bring something wonderful to your computing — and we hope that you’ll join us in helping to shape and build the future of free software together.

Installation

MPTCP is a kernel patch, or more precisely an entire kernel modification. Fortunately, MPTCP team has prepared out the packages and created repositories for allowing researchers to install and create MPTCP systems. We shall be using the default availabele MPTCP system, and shall be seeing on how to do so.

Steps:

          		 [Figure 17: MPCTP verification]

Other linux systems

Other than ubuntu/debian fedora,arch linux,gentoo,opensuse and centos also have their own repository. The process is very identical, but has different commands.

The configuration will be discussed in the research phase.

Simulation Software

There are several softwares, that allow simulation of MPTCP networks and enable us to modify the network architecture on the fly and study the system. NS2/3 is one such system that is effectively used for the same.

There is also mininet based systems which we shall see in the Vagrant setup as they are quick and easy to install using the vagrant boxes.

NS2

ns (from network simulator) is a name for a series of discrete event network simulators, specifically ns-1, ns-2, and ns-3. All are discrete-event computer network simulators, primarily used in research[2] and teaching. ns-2

Ns-2 began as a revision of ns-1. From 1997-2000, ns development was supported by DARPA through the VINT project at LBL, Xerox PARC, UCB, and USC/ISI. In 2000, ns-2 development was supported through DARPA with SAMAN and through NSF with CONSER, both at USC/ISI, in collaboration with other researchers including ACIRI.

Ns-2 incorporates substantial contributions from third parties, including wireless code from the UCB Daedelus and CMU Monarch projects and Sun Microsystems. ns-3

In 2006, a team led by Tom Henderson, George Riley, Sally Floyd, and Sumit Roy, applied for and received funding from the U.S. National Science Foundation (NSF) to build a replacement for ns-2, called ns-3. This team collaborated with the Planete project of INRIA at Sophia Antipolis, with Mathieu Lacage as the software lead, and formed a new open source project.

In the process of developing ns-3, it was decided to completely abandon backward-compatibility with ns-2. The new simulator would be written from scratch, using the C++ programming language. Development of ns-3 began in July 2006.

Current status of the three versions is:

* ns-1 development stopped when ns-2 was founded.
        It is no longer developed nor maintained.
* ns-2 development stopped around 2010.
        It is no longer developed nor maintained.
* ns-3 is actively being developed and maintained.

Simulation workflow

The general process of creating a simulation can be divided into several steps:

1) Topology definition: To ease the creation of basic facilities and define their interrelationships, ns-3 has a system of containers and helpers that facilitates this process. 2) Model development: Models are added to simulation (for example, UDP, IPv4, point-to-point devices and links, applications); most of the time this is done using helpers. 3) Node and link configuration: models set their default values (for example, the size of packets sent by an application or MTU of a point-to-point link); most of the time this is done using the attribute system. 4) Execution: Simulation facilities generate events, data requested by the user is logged. 5) Performance analysis: After the simulation is finished and data is available as a time-stamped event trace. This data can then be statistically analysed with tools like R to draw conclusions. 6) Graphical Visualization: Raw or processed data collected in a simulation can be graphed using tools like Gnuplot, matplotlib or XGRAPH.

The reason we have chosen to use NS2 is because, it has already been covered in our curriculum thereby allowing us to create code faster. Also, since its stable at this moment there have been a lots of important development that allows us to fix any issue or bugs that we might encounter.

Steps:

and then wget -c "https://sourceforge.net/projects/nsnam/files/allinone/ns-allinone-2.35/ns-allinone-2.35.tar.gz/download" so as to download it in the workdir.

tar -zxvf ns-allinone-2.35.tar.gz
cd ns-allinone-2.35


          		[Figure 18: NS2 extraction]

then you must download the patch for MPTCP support in ns2,

wget -c https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/multipath-tcp/mptcp.patch-for-ns2.35-20130810

patch -p1 < mptcp.patch-for-ns2.35-20130810


            [Figure 19: NS2 patching]

sudo apt-get update 
sudo apt-get install build-essentials libx11-dev 
libxkbcommon-x11-dev libxt-dev


      [Figure 20: NS2 dependency Installation]

by executing, sudo ./install

Most probably we are bound to encounter few errors, they can be one of the following three:

  1. Missing dependency: In most of the system not all packages are available, and sometimes such error do arrive. The general trick is to simply copy paste the error into the search engine and explore. If its a missing dependency error then a general search on “How to install " helps, (without angular brackets.)

  2. linkstate error: This is one of the most common error found in Ns2 package and it can be resolved by modifying certain files,

    Error

    linkstate/ls.h:137:25: error: ‘erase’ was not declared in this scope, and
no declarations were found by argument-dependent lookup at the
point of instantiation [- fpermissive]
 void eraseAll() {erase(baseMap::begin(), baseMap::end());}
linkstate/ls.h:137:25: note: declarations in dependent base‘std
::map<int, LsIdSeq,std::less<int>,std::allocator<std::pair<constint
, LsIdSeq> > >’ are not found by unqualified lookup
linkstate/ls.h:137:25: note: use ‘this-
>erase’ instead
Makefile:93: recipe for target ’ linkstate/ls.o’ failed
make:***[linkstate/ls.o] Error 1
Ns make failed!
Seehttp://www.isi.edu/nsnam/ns/ns-problems.html for problems

   so as to fix this error, navigate to `linkstate/ls.h` file in source code and then scroll down to line number 137,

   the function `eraseAll()`

   now modify the function,

   ```C
   void eraseAll() {erase(baseMap::begin(), baseMap::end());}

to

    void eraseAll() {this -> erase(baseMap::begin(), baseMap::end());}


          [Figure 21: Before fixing]


          [Figure 22: After Fixing]

After that, simply re-run sudo ./install in the source directory.

  1. Mdart Errror mdart/mdart_adp.cc: If one encounter error like this:

    Error

     mdart/mdart_adp.cc: In member function ‘void ADP::sendDarq(nsaddr_t, int)’: 
 mdart/mdart_adp.cc:108:21: error:
  reference to ‘hash’ is ambiguous 
 nsaddr_t dstAdd_ = hash(reqId); 
 ^~~~ 
 In file included from ./mdart/mdart.h :52:0, 
 from ./mdart/mdart_adp.h :51, from mdart/mdart_adp.cc :47: 
 ./mdart/mdart_function.h:230:17:
  note: candidates are: nsaddr_t hash(nsaddr_t) 
 inline nsaddr_t hash(nsaddr_t id) { ^~~~
   
....

then this is an issue of Compiler version and it can be fixed by running

sudo apt-get install g++-5
export CC =gcc-5 CXX=g++-5
# in main directory
sudo ./install

Upon Successfull installation one should get the following message:

           [Figure 23: Final Step]

After which one can setup the following path variables to finish the installation.

#Modify the path variables AS PER YOUR SYSTEM.
export PATH=$PATH:/home/shiroi/mptcp/ns -allinone-2.35/bin
export PATH=$PATH:/home/shiroi/mptcp/ns-allinone-2.35/tcl8.5.10/unix
export PATH=$PATH:/home/shiroi/mptcp/ns-allinone -2.35/tk8.5.10/unix
 #Add the following lines at the end of your .bashrc file
export NS2_HOME=/home/shiroi/mptcp/ns-allinone-2.35/ 
export PATH=$PATH:$NS2_HOME/bin
export PATH=$PATH:$NS2_HOME/tcl8.5.10/unix:$NS2_HOME/tk8.5.10/unix 
export LD_LIBRARY_PATH=$NS2_HOME/otcl-1.14:$NS_HOME/lib 
export TCL_LIBRARY=$NS2_HOME/tcl8.5.10/library

Raspberry pi 3b+

The Raspberry Pi (/paɪ/) is a series of small single-board computers developed in the United Kingdom by the Raspberry Pi Foundation to promote teaching of basic computer science in schools and in developing countries. The original model became far more popular than anticipated,selling outside its target market for uses such as robotics. It now is widely used even in research projects, such as for weather monitoring because of its low cost and portability. It does not include peripherals (such as keyboards and mice) or cases. However, some accessories have been included in several official and unofficial bundles.

The organisation behind the Raspberry Pi consists of two arms. The first two models were developed by the Raspberry Pi Foundation. After the Pi Model B was released, the Foundation set up Raspberry Pi Trading, with Eben Upton as CEO, to develop the third model, the B+. Raspberry Pi Trading is responsible for developing the technology while the Foundation is an educational charity to promote the teaching of basic computer science in schools and in developing countries.

According to the Raspberry Pi Foundation, more than 5 million Raspberry Pis were sold by February 2015, making it the best-selling British computer. By November 2016 they had sold 11 million units, and 12.5 million by March 2017, making it the third best-selling “general purpose computer”. In July 2017, sales reached nearly 15 million, climbing to 19 million in March 2018. By December 2019, a total of 30 million devices had been sold.

Most Pis are made in a Sony factory in Pencoed, Wales, while others are made in China and Japan.

These pi’s are excellent devices, fo rthey have both ethernet and Wifi capabilities built in. This enables a very neat and lenient feature set for MPTCP.

Installation

Since there is no standard repository available for MPTCP kernel on raspberry pi we will have to compile the kernel from source.

For installation,

You will need a PC or laptop running a recent Linux distribution so that we can use the Raspberry Pi compiler and toolchain to cross-compile the MPTCP Linux kernel for ARM. I assume that you have a working knowledge of Linux to understand the rest of the guide.

You will need at least a 8GB micro-SD memory card. I have use the 16gb sdcard so I can safely state that it works well. Archlinux ARM should be installed on it according to the official guide. (please see references for the link.) All other software you need should already be installed beforehand. This is because an improper build may make your Raspberry Pi unbootable unless the SD card is re-imaged back into its working condition.

For the pc we have, Ubuntu 18.04 as our operating system, the cross tool chain and system must be configured accordingly.

 sudo apt-get install build-essential bc make ncurses-dev wget unzip git

One must have git configured onto his system.

Cross Compilation tool chain:

Since we are doing the compilation process on a 64-bit Intel/AMD PC running a Linux distro, compiling the kernel right away will build a kernel for the x86_64 architecture. Instead, what we need to do is use a cross-compiler to build for ARM instead. The Raspberry Pi team provides a cross-compiling toolchain at raspberry pi github, (link in references) which we can freely use to compile any program to run on the Raspberry Pi 2 and 3.

git clone https://github.com/raspberrypi/tools ~/tools
# add following to the bashrc
export PATH=$PATH:~/tools/arm-bcm2708/  \
gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin 
source ~/.bashrc

raspberry pi kernel must be fetched so as to make proper modifications,

 git clone https://github.com/raspberrypi/linux.git

We should add the mptcp branch code to our repository as well and fetch it,

git remote add mptcp https://github.com/multipath-tcp/mptcp.git
git fetch mptcp

Now that all the kernel sources are ready, we need to create a new version of the kernel sources where the changes from MPTCP are merged into the Raspberry Pi kernel. As of writing this, the latest version of MPTCP, i.e. v0.94, is based on the Linux 4.14 kernel.

So first we need to make a new version of the 4.14 kernel (where we’re going to make changes) by creating a git branch based on Raspberry Pi kernel 4.14.

git checkout -b rpi_mptcp origin/rpi-4.14.y
#Then we need to merge changes from MPTCP,
#preferring MPTCP’s change in case a conflict arises.
git merge -s recursive -X theirs mptcp/mptcp_v0.94


              [Figure 24: git merge]

Prepare the files for compilation with

make mrproper

At this point, the Raspberry Pi custom kernel compilation guide will suggest you to run make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- bcm2709_defconfig to generate the default kernel build options but using that lead to kernel panic in arch linux, and worked pretty well with raspibian. If you want to compile it for arch linux, check this link https://archlinuxarm.org/packages/armv7h/linux-raspberrypi/filesconfig which shows the default configs for Archlinux ARM kernel. Make a new file named .config in the current directory and copy and paste everything from the text block in that web page into that file.

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 4.14.61-1 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_ARM_HAS_SG_CHAIN=y
CONFIG_MIGHT_HAVE_PCI=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_LOCALVERSION="-MPTCP"
....

CONFIG_SG_POOL=y
CONFIG_ARCH_HAS_SG_CHAIN=y
CONFIG_SBITMAP=y
# CONFIG_STRING_SELFTEST is not set
# CONFIG_VIRTUALIZATION is not set

this must be put into .config file.

After saving to .config,

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig

so as to start the cross compilation process.

Once done this command starts the menu:

              [Figure 25: Kernel menu]

This menu can be navigated in the following manner:

One can select a menu option using Space key. The selection will rotate between unchecked [ ], compile into kernel [*] and compile as module [M]. One can go into a menu sub-option using the Enter key. So as to go back up an option level up pressing Esc twice in quick succession.

In this menu, follow: Networking options > IP advanced router (compile to kernel) and then the same for Policy routing

             [Figure 26: menu setup]

Go to IPv6 protocol and choose to compile into kernel. As soon as we do that, a new menu option ‘MPTCP protocol (NEW)’ will show up. Choose to compile that into kernel. Go to ‘MPTCP: advanced path-manager control (NEW)’ sub-option. Check everything to compile into kernel. Keep default path manager as ‘fullmesh’. Go one level back. Then go into ‘MPTCP: advanced scheduler control (NEW)’. Repeat the same as we did with the last option and keep default scheduler as ‘default’.

             [Figure 27: Path manager setup]

Go one step back. Scroll upwards to ‘TCP: advanced congestion control’ and enter it. Checkmark ‘MPTCP Linked Increase’, ‘MPTCP Opportunistic Linked Increase’, ‘MPTCP WVEGAS CONGESTION CONTROL’ and ‘MPTCP BALIA CONGESTION CONTROL’ to be installed into the kernel. Choose ‘Lia’ as the Default TCP congestion control.

Go back all the way to the home screen of the menu. Then press Esc twice. we will get a screen as shown below.

             [Figure 27: Kernel final message]

Now that we have made the necessary configuration, type this line into the terminal to compile the kernel, modules and the device tree:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j$(nproc) zImage modules dtbs

        [Figure 28: making the kernel]

Now this will take a lot longer than you can imagine, with my 4 core processor system running at 1.8 ghz it took 3 hrs, to compile and all the time running at 100% cpu utilization.

[Figure 29: Left: mounting, bottom right: raspberrypi verification]

After the last step, the latest and the greatest MPTCP kernel is built and ready for use on your Raspberry Pi. Now, lets install it.

Remember the micro-SD card on which Archlinux ARM is installed? We will need it now. Plug it into your card reader.

Make two folders under /mnt to mount the boot and OS root partitions. We can do it by typing the following commands in a root shell:

mkdir -p /mnt/boot
mkdir -p /mnt/root

Now we need to mount the two SD card partitions. On an Archlinux ARM based system, the first partition (FAT32) is the boot partition and the second one (EXT4) holds the operating system and user files.

If you have an internal card reader, use the following commands in a root shell to mount:

mount -t vfat /dev/mmcblkXp1 /mnt/boot
mount -t ext4 /dev/mmcblkXp2 /mnt/root

Else, if you use an external card reader (like me), then use these instead:

mount -t vfat /dev/sdX1 /mnt/boot
mount -t ext4 /dev/sdX2 /mnt/root

#Create backup of old kernel
mkdir /mnt/boot/oldkernel
mv /mnt/boot/kernel7.img /mnt/boot/oldkernel/
mv /mnt/boot/*.dtb /mnt/boot/oldkernel/
mv /mnt/boot/overlays /mnt/boot/oldkernel/

#copying the new kernel image and overlays
sudo cp arch/arm/boot/zImage /mnt/boot/kernel7.img
sudo cp arch/arm/boot/dts/*.dtb /mnt/boot/
sudo mkdir /mnt/boot/overlays
sudo cp arch/arm/boot/dts/overlays/*.dtb* /mnt/boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /mnt/boot/overlays/

The kernel is now installed. But one crucial step is still left. We need the kernel modules for this MPTCP kernel to also be installed. Without it, most hardware connected to the Raspberry Pi will not work or a kernel panic may occur. As this step is critical, do not skip.

To install the modules run this command:

sudo make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- \
INSTALL_MOD_PATH=/mnt/root -j$(nproc) modules_install

#Now we are done, simply bootup and verify
sync
sudo umount /mnt/boot
sudo umount /mnt/root
sudo rm -r /mnt/boot
sudo rm -r /mnt/root

Now after booting up the sdcard in pi,

root@pi: uname -a
Linux alarmpi 4.14.67-MPTCP+ #5 SMP Sat Sep 1 16:06:46 IST 2018 armv7l
GNU/Linux

Vagrant Boxes

Vagrant is an open-source software product for building and maintaining portable virtual software development environments, e.g. for VirtualBox, KVM, Hyper-V, Docker containers, VMware, and AWS. It tries to simplify software configuration management of virtualizations in order to increase development productivity. Vagrant is written in the Ruby language, but its ecosystem supports development in a few languages. Vagrant uses “Provisioners” and “Providers” as building blocks to manage the development environments. Provisioners are tools that allow users to customize the configuration of virtual environments. Puppet and Chef are the two most widely used provisioners in the Vagrant ecosystem (Ansible has been available since at least 2014). Providers are the services that Vagrant uses to set up and create virtual environments. Support for VirtualBox, Hyper-V, and Docker virtualization ships with Vagrant, while VMware and AWS are supported via plugins.

Vagrant sits on top of virtualization software as a wrapper and helps the developer interact easily with the providers. It automates the configuration of virtual environments using Chef or Puppet, and the user does not have to directly use any other virtualization software. Machine and software requirements are written in a file called “Vagrantfile” to execute necessary steps in order to create a development-ready box. “Box” is a format and an extension ( .box) for Vagrant environments that is copied to another machine in order to replicate the same environment.

Some of the excellent simulation softwares, are available in Vagrant which allows a close to real understanding of MPTCP on outdated machines such as windows.

Installation

So as to install vagrant on ubuntu machine, it is necessary to have virtual box.

sudo apt install virtualbox
sudo apt update
cd /tmp
url=https://releases.hashicorp.com/vagrant/2.2.6/vagrant_2.2.6_x86_64.deb
wget -c $url
sudo dpkg -i vagrant*.deb
# to verify 
vagrant --version

This should finish and configure the vagrant box.

In research phase we shall be seeing many of the boxes and source code to some of the program that utilize mininet for simulation.

ProgMP

ProgMP is a programming model for Multipath TCP scheduling. It provides powerful abstractions to develop own application- and preference-aware schedulers. This page provides a getting started tutorial, scheduler examples, an overview of the extended socket API and the language primitives.

Installation

The process of installation is very simple, albeit restricted to debian and ubuntu based machines.

sudo -i
# enter root password adn login
wget -c http://progmp.net/tools/linux-image-4.1.20-ProgMp.deb
sudo dpkg -i linux-image-4.1.20-ProgMp.deb
# It is assumed that you have followed the MPTCP installation steps 
# referred above.
# reboot to grub menu and then select kernel 4.1.20

This should basically finish installing the progmp kernel onto your machine, currently there is no means to install it on other systems other than compiling from source.

Android

Android is a mobile operating system based on a modified version of the Linux kernel and other open source software, designed primarily for touchscreen mobile devices such as smartphones and tablets. Android is developed by a consortium of developers known as the Open Handset Alliance, with the main contributor and commercial marketer being Google.

Initially developed by Android Inc., which Google bought in 2005, Android was unveiled in 2007, with the first commercial Android device launched in September 2008. The current stable version is Android 10, released on September 3, 2019. The core Android source code is known as Android Open Source Project (AOSP), which is primarily licensed under the Apache License. This has allowed variants of Android to be developed on a range of other electronics, such as game consoles, digital cameras, PCs and others, each with a specialized user interface. Some well known derivatives include Android TV for televisions and Wear OS for wearables, both developed by Google.

Android’s source code has been used as the basis of different ecosystems, most notably that of Google which is associated with a suite of proprietary software called Google Mobile Services (GMS), that frequently comes pre-installed on said devices. This includes core apps such as Gmail, the digital distribution platform Google Play and associated Google Play Services development platform, and usually apps such as the Google Chrome web browser. These apps are licensed by manufacturers of Android devices certified under standards imposed by Google. Other competing Android ecosystems include Amazon.com’s Fire OS, or LineageOS. Software distribution is generally offered through proprietary application stores like Google Play Store or Samsung Galaxy Store, or open source platforms like Aptoide or F-Droid, which use software packages in the APK format.

Since an android operating system is well equipped with data as well wifi network interfaces, it can benefit a lot from MPTCP.

Sadly the update of gnulibc in android 5, it kinda broke the compatibility and requires recompilation.

We shall be installing MPTCP on an Android KitKat device.

Installation

The image has been prepared for android kk by some great contributors (see references).

Unlocked bootloader is a must, and having rotted phone sincerely helps in debugging and fixing if an issue occurs.

download corresponding heimdall from the link in reference and install it if you are installing it on a samsung device.

sudo apt install adb fastboot

then,wget -c http://www.multipath-tcp.org/android/boot_20150421_mptcp0.89.5_android4.4.4.img)so as to download the kernel boot image that has been pre-prepared.

After that installation is as simple as using fastboot to boot into this kernel,

# With your phone connected, and adb working.
adb reboot bootloader
fastboot flash boot boot_20150421_mptcp0.89.5_android4.4.4.img
fastboot reboot


                        [Figure 30: Android fastboot]

Then you can go ahead and use the provided apk to use multiple interfaces at once.

Please note, that if you are on a samsung device you must use heimdall to flash.

Research phase

In this phase we shall be overseeing many of the experiments that we have conducted throughout the semester, Even more have been performed which could not be documented because of lack of screenshot or distinct results.

Configuring MPTCP and “amiusingmptcp.de”

Aim: Configure and test MPTCP.

We have successfully installed MPTCP, but the crucial step will be to configure the routing table to use it.

This can be done in the following two ways:

  1. Manual Ip configurations:

Imagine we have two interfaces, eth0 and wlan0, with ip and gateway as follows:

# eth0
ip: 10.1.1.2
subnet: 255.255.255.0
gateway: 10.1.1.1
# wlan0
ip: 192.168.1.2
subnet: 255.255.255.0
gateway: 192.168.1.1

then this can be configured as follows:

  # This creates two different routing tables,
  # These will be used as per the source address.
  ip rule add from 10.1.1.2 table 1
  ip rule add from 192.168.1.2 table 2

  # Configure the two different routing tables
  ip route add 10.1.1.0/24 dev eth0 scope link table 1
  ip route add default via 10.1.1.1 dev eth0 table 1

  ip route add 192.168.1.0/24 dev wlan0 scope link table 2
  ip route add default via 192.168.1.1 dev wlan0 table 2

  # default route for the selection process of normal
  # internet-traffic
  ip route add default scope global nexthop via 10.1.1.1 dev eth0

  root@shiro:~# ip rule show
  0:      from all lookup local
  32764:  from 10.1.2.2 lookup 2
  32765:  from 10.1.1.2 lookup 1
  32766:  from all lookup main
  32767:  from all lookup default

  root@shiro:~# ip route
  10.1.1.0/24 dev eth0  proto kernel  scope link  src 10.1.1.2
  10.1.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.2
  default via 10.1.1.1 dev eth0

  root@shiro:~# ip route show table 1
  10.1.1.0/24 dev eth0  scope link
  default via 10.1.1.1 dev eth0

  root@shiro:~# ip route show table 2
  10.1.2.0/24 dev wlan0  scope link
  default via 192.168.1.1 dev wlan0
  1. Automatic Configuration:

This process can be cumbersome henceforth we usually use the automation script for the same.

A simple script can be written which can be used for automation of the same.

Step 1: Assign following variables, (since the longer link are subject to format, they are assigned and used as variables.)

mptcp_down="https://github.com/multipath-tcp/mptcp-scripts/blob/master/scripts/rt_table/mptcp_down"

mptcp_up="https://github.com/multipath-tcp/mptcp-scripts/blob/master/scripts/rt_table/mptcp_up"

Step 2: Now we are ready to download and set it up.

#!/bin/bash
#Enter super user mode
sudo -i 
cd /tmp
wget -c $mptcp_down
wget -c $mptcp_up
cp ./mptcp_up /etc/network/if-up.d/
chmod +x /etc/network/if-up.d/mptcp_up
cp ./mptcp_down /etc/network/if-post-down.d/
chmod +x /etc/network/if-post-down.d/mptcp_down
ls -alh /etc/network/if-post-down.d/
ls -alh /etc/network/if-up.d/
# for restarting and applying settings
reboot

This script can automatically fetch the script and set it up, it shall be done in a go.

After connecting the multiple network interfaces and then rebooting allows us to interpret it well and then we can use “amiusingmptcp.de” to testour mptcp connection

   [Figure 31: MPTCP verified and Success ]

MPTCP Reliability Test

Aim: This is a simple experiment to verify and assert the reliability of MPTCP.

We have all read how stable MPTCP is, time to put it to test.

For the purpose of experimentation we have used the mptcp snapshot server, meaning the server is mptcp capable and we are MPTCP capable as well, the two interfaces used were:

  1. Ethernet : Maxing out at 50KBps

  2. USB Mobile tethering: Maxing out at 1-3MBps

During the download the connections were delieberately interrupted to see the effect on download and was monitored as well.

[Figure 32: enp3s0 and enp0s25lu5 interfaces report]

Conclusion:

NS2 Experimentation

Aim: Scripting a MPTCP model and make conclusions.

We have successfully installed and configured MPTCP for NS2, time to put it in action.

For NS2, the process usually involves creating a program in tcl and then run it using ns2, which generates .nam file which allows us to run the simulations.

#
#
# sample script for mptcp implementation on ns-2
#
#      Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
#
#
set ns [new Simulator]
#
# specify to print mptcp option information
#
Trace set show_tcphdr_ 2

#
# setup trace files
#
set f [open out.tr w]
$ns trace-all $f
set nf [open out.nam w]
$ns namtrace-all $nf


#
# mptcp sender
#
set n0 [$ns node]
set n0_0 [$ns node]
set n0_1 [$ns node]
$n0 color red
$n0_0 color red
$n0_1 color red
$ns multihome-add-interface $n0 $n0_0
$ns multihome-add-interface $n0 $n0_1

#
# mptcp receiver
#
set n1 [$ns node]
set n1_0 [$ns node]
set n1_1 [$ns node]
$n1 color blue
$n1_0 color blue
$n1_1 color blue
$ns multihome-add-interface $n1 $n1_0
$ns multihome-add-interface $n1 $n1_1

#
# normal tcp 1
#
set n2 [$ns node]
set n3 [$ns node]
$n2 color yellow
$n3 color yellow

#
# normal tcp 2
#
set n4 [$ns node]
set n5 [$ns node]
$n4 color green
$n5 color green

#
# intermediate nodes 
#
set r1 [$ns node]
set r2 [$ns node]
set r3 [$ns node]
set r4 [$ns node]

$ns duplex-link $n0_0 $r1 10Mb 5ms DropTail
$ns duplex-link $r1 $r3   1Mb 5ms DropTail
$ns queue-limit $r1 $r3 30
$ns duplex-link $n1_0 $r3 10Mb 5ms DropTail

$ns duplex-link $n0_1 $r2 10Mb 5ms DropTail
$ns duplex-link $r2 $r4   1Mb 5ms DropTail
$ns queue-limit $r2 $r4 30
$ns duplex-link $n1_1 $r4 10Mb 5ms DropTail

$ns duplex-link $n2 $r1 10Mb 5ms DropTail
$ns duplex-link $r3 $n3 10Mb 5ms DropTail
$ns duplex-link $n4 $r2 10Mb 5ms DropTail
$ns duplex-link $r4 $n5 10Mb 5ms DropTail


#
# create mptcp sender
#
#     1. create subflows with Agent/TCP/FullTcp/Sack/Multipath
#     2. attach subflow on each interface
#     3. create mptcp core 
#     4. attach subflows to mptcp core
#     5. attach mptcp core to core node 
#     6. attach application to mptcp core
#
set tcp0 [new Agent/TCP/FullTcp/Sack/Multipath]
$tcp0 set window_ 100 
$ns attach-agent $n0_0 $tcp0
set tcp1 [new Agent/TCP/FullTcp/Sack/Multipath]
$tcp1 set window_ 100
$ns attach-agent $n0_1 $tcp1
set mptcp [new Agent/MPTCP]
$mptcp attach-tcp $tcp0
$mptcp attach-tcp $tcp1
$ns multihome-attach-agent $n0 $mptcp
set ftp [new Application/FTP]
$ftp attach-agent $mptcp


#
# create mptcp receiver
#
set mptcpsink [new Agent/MPTCP]
set sink0 [new Agent/TCP/FullTcp/Sack/Multipath]
$ns attach-agent $n1_0 $sink0 
set sink1 [new Agent/TCP/FullTcp/Sack/Multipath]
$ns attach-agent $n1_1 $sink1 
$mptcpsink attach-tcp $sink0
$mptcpsink attach-tcp $sink1
$ns multihome-attach-agent $n1 $mptcpsink
$ns multihome-connect $mptcp $mptcpsink
$mptcpsink listen


#
# create sack TCP connection
#
set reno0 [new Agent/TCP/FullTcp/Sack]
$reno0 set window_ 100 
$ns attach-agent $n2 $reno0
set renosink0 [new Agent/TCP/FullTcp/Sack]
$ns attach-agent $n3 $renosink0
$ns connect $reno0 $renosink0
$renosink0 listen
set ftp0 [new Application/FTP]
$ftp0 attach-agent $reno0


#
# create sack TCP connection
#
set reno1 [new Agent/TCP/FullTcp/Sack]
$reno1 set window_ 100 
$ns attach-agent $n4 $reno1
set renosink1 [new Agent/TCP/FullTcp/Sack]
$ns attach-agent $n5 $renosink1
$ns connect $reno1 $renosink1
$renosink1 listen
set ftp1 [new Application/FTP]
$ftp1 attach-agent $reno1

proc finish {} {
    global ns f 
    global nf
    $ns flush-trace
    close $f
    close $nf

    set awkcode {
        {
 if ($1 == "r" && NF == 20) {  
   if ($3 == "1" && $4 == "10" && $5 == "tcp") { 
     print $2, $18 >> "mptcp"
   } 
   if ($3 == "2" && $4 == "11" && $5 == "tcp") { 
     print $2, $18 >> "mptcp"
   } 
 }
 if ($1 == "r" && NF == 17) {  
   if ($3 == "6" && $4 == "10" && $5 == "tcp") { 
     print $2, $11 >> "normal-tcp1"
   } 
   if ($3 == "8" && $4 == "11" && $5 == "tcp") { 
     print $2, $11 >> "normal-tcp2"
   } 
}
        }
    } 
    exec rm -f mptcp normal-tcp1 normal-tcp2
    exec awk $awkcode out.tr
    exec xgraph -M -m -nl mptcp normal-tcp1 normal-tcp2 
    exit
}

$ns at 0.1 "$ftp start"        
$ns at 0.1 "$ftp0 start"  
$ns at 0.1 "$ftp1 start" 
$ns at 300 "finish"

$ns run

save it as mptcp-sample.tcl and then we are ready to run and simulate it.

So as to execute it,

akuma@shiro ~: ns2 mptcp-sample.tcl

which shall generate .nam file and also show some output.

            [Figure 33: NS2 simulation]

The layout might look differently on your machine and it can be adjusted by clicking on readjust button. In here the one with two paths are the nodes which are MPTCP network capable.

Analysis Graph:

                    [Figure 34: MPTCP NS2 graph]

This here is the graph of subflows and the red one is the combined bandwidth, that demonstrate aggregation of Bandwidths. Obviously it is bound to be undeterred in simulation environment and is subject to change in real world scenarios.

progMP and Configurations.

Aim: To test the basics of algorithms modification in progmp system, and loading.

So as to achieve this it is assumed that one has already booted into progMP kernel.

The process of loading a scheduling algorithm is very simple, one needs to obtain or create their algorithm in DSl, for this experiment we shall be using the pre-provided scripts.

FIrst of all, one can start a simple text editor and write down following content

/*
 * Scheduler sending packets on the subflow with the lowest RTT
 *  which has cwnd.
 */

SCHEDULER illustratingMinRTT;

VAR sbfCandidates = SUBFLOWS.FILTER(sbf => sbf.CWND > sbf.SKBS_IN_FLIGHT
 + sbf.QUEUED AND !sbf.THROTTLED AND !sbf.LOSSY);

IF(sbfCandidates.EMPTY) {
  RETURN;
}

IF (!RQ.EMPTY) {
  VAR sbfCandidate = sbfCandidates.FILTER(sbf => 
sbf.HAS_WINDOW_FOR(RQ.TOP) AND !RQ.TOP.SENT_ON(sbf)).MIN(sbf => sbf.RTT);
  IF (sbfCandidate != NULL) {
    sbfCandidate.PUSH(RQ.POP());
    RETURN;
  }
} 

IF (!Q.EMPTY) {
  sbfCandidates.FILTER(sbf => sbf.HAS_WINDOW_FOR(Q.TOP)).MIN(sbf => 
sbf.RTT).PUSH(Q.POP());
}

and save it as minRTT.progmp

Next step is to download or to save the following python (python 2) script.

from subprocess import check_call
import argparse
import os.path

def setDefaultScheduler(schedulerName):
    try:
        with open ("/proc/net/mptcp_net/rbs/default", "w") as dst:
  dst.write(schedulerName)
        return True
    except:
        return False

def loadScheduler(schedulerFileName):
    try:
        with open(schedulerFileName, "r") as src:
  content = src.read()

        with open("/proc/net/mptcp_net/rbs/schedulers", "w") as dst:
  dst.write(content)
        # TODO more checks
        return True
    except:
        return False

def getSchedulerName(schedulerFileName):
    with open(schedulerFileName, "r") as src:
        content = src.read()
        startIndex = content.index("SCHEDULER ") + len("SCHEDULER ")
        endIndex = content[startIndex:].index(";")
        return content[startIndex:startIndex + endIndex]

if __name__ == '__main__':
    parser = argparse.ArgumentParser()
    parser.add_argument("-f", "--file", 
    help="The file which contains the scheduler", required=True)
    args = parser.parse_args()

    if os.geteuid() != 0:
        print "You have to be root to load a new scheduler."
        exit()
    if not os.path.isfile(args.file):
        print "File ", args.file, " not found."
        exit()
    if not loadScheduler(args.file):
        print "Loading the scheduler in file ", args.file,
        " failed. Execute dmesg to check output."
        exit()
    schedulerName = getSchedulerName(args.file)
    if not setDefaultScheduler(schedulerName):
        print "Setting the scheduler as default failed."+
        "Execute dmesg to check output."
        exit()
    print "Scheduler", schedulerName, "loaded and set as default."

This script can be ported to python3 if so is desired.

The script can be loaded into system by:

sudo progmp_script.py -f "minRTT.progmp"
# upon success
sysctl -w net.mptcp.mptcp_scheduler=rbs

Then this can be tested again by going to “amiusingmptcp.de”

For out purpose we have yet again simply downloaded a file and observed the traffic.

        [Figure 35: Strong network minRTT]

The very same file was again downloaded on weak network, with minrtt.

                [Figure 36: Weak network minRTT]

A simple dns query resolution on mptcp with minrtt looks like this,

    [Figure 37: DNS query resolution]

Vagrant boxes and Vagrant based simulations

Vagrant are basically a means to automate spawning of virtual machines, and with mptcp kernel plugged into these machines and multiple interfaces setup we can not only run various simulation programs but also take benefit of low level containerization and effective spawning and automation.

Vagrant must be installed on host machine which can be done as follows. (The methods are subject to change in near future, so it is advisable to follow the latest guide on this.)

# First and foremost requirement for vagrant is virtual box
sudo apt install virtualbox
#After that we can use curl / wget to download the .deb package
u="https://releases.hashicorp.com/vagrant/2.2.6/vagrant_2.2.6_x86_64.deb"
wget -c $u
# once downloaded it can be installed by
sudo dpkg -i ./vagrant_*.deb
# remember to put it in "" on zsh based machines, 
# for bash this works fine
# To verify the installation
vagrant --version
# which should output something like this 
# output
# Vagrant 2.2.6

Once we have configured vagrant, its to start with the vagrant box.

git clone https://github.com/frawi/mptcp-tests.git
cd mptcp-tests

Once inside the directory we can edit the Vagrant file as following,

❯ tree                                                                                                                                                                                                           ─╯
.
├── benchmark.py
├── LICENSE
├── README.md
└── Vagrantfile

0 directories, 4 files

Now so as to edit the file,

# -*- mode: ruby -*-
# vi: set ft=ruby :

# All Vagrant configuration is done below. The "2" in Vagrant.configure
# configures the configuration version (we support older styles for
# backwards compatibility). Please don't change it unless you know what
# you're doing.
Vagrant.configure(2) do |config|
  config.vm.box = "comnets/mininet-mptcp"


  # this is useful because we might want to use xterms in mininet
  # and also in case you prefer to use gui based browser to simulate traffic
  config.ssh.forward_x11 = true

  config.vm.provider "virtualbox" do |vb|
    # we shall need the gui to modify the kernel if we will so. 
    vb.gui = true
    # Enable I/O APIC to use multiple CPUs
    #vb.customize ["modifyvm", :id, "--ioapic", "on"]
    #vb.cpus = 2

    # Customize the amount of memory on the VM:
    # This is the memory alocatted to VM, the mroe the better. 
     vb.memory = "4096"
  end
end

Once done editing we are ready to spin our VM,

vagrant up
vagrant ssh 
# if you desire to use X forwarding with ssh,
# use vagrant ssh-config to obtain the private
# key to the box, and use ssh -X to connect to it.

Now we shall be dropped in the vagrant “box’s” terminal, which is basically ssh access to the machine. Navigate to /vagrantand there we shall find the benchmark.py which shall allow us to simulate the traffic in our vagrant box.

sudo ./benchmark --paths 10

Also, you can use the –help to get the help on benchmark script.

The command generates two files, h1.pcap and h2.pcap which can be viewed in wireshark/etherape

     [Figure 38: Benchmark.py h1.pcap file]

Other than that, the progmp kernel can also be installed on vagrant machine, and switched to in similar way.

Result and Discussions

Results and discussions have been summarised in the last phase of our Series of Experimentations, i.e the conclusive analysis phase.

Conclusive Analysis phase

Throughout our series of experiments we did many things, these were not limited to downloads, changes, comparison of algorithms. Apart from them we also made installations and looked into the content. All these results have been concluded henceforth and their results have been discussed.

Various methods and their installations

We saw how the various methods have been installed, it could be very well seen that because of the diveristy of platforms MPTCP has varied steps of installation. Each installation is a lot mroe different from the other, which means that if their is a network of multi natured devices then each of these devices will need to be configured and setup individually, meaning this is not only a hassle but seemingly impossible task.

Infact, the extent of automation so far is limited to shell scripts and configuration managers.

Simulation Methods and their correctness

It has been seen how the simulations are run and also how the simulations are. They can been seen very errorneous and a bit far from correctness, other than that teh installation methods were not seemingly complex nor there was any difficulty in simulating programs. These went effectively and easily, perhaps the program can be finetuned to introduce errors and try to simulate real world traffic but that is a task still left.

progMP and its effectiveness

progMP is very effective tool in our discovery, it works flawlessly with various algorithm systems and not simulates them but rather allows us to effectively use it right away into our system. This enables us to generate our own specific traffic and study (as we did in case of DNS resolution). Apart from that, we have seen that the code can be modified in steps as simple as running scripts, which leads to portability and also gives hope when it comes down to Automation.

Apart from these progMP sincerely allows us to do various things which would have required very long amount of studies and research into kernel.

The only downfall with progMP is the lower kernel version which not only introduces various security bugs but also forces us to not effectively utilise kernel optimisation. This can be changed by packaging progMP with more latest kernels and compiling them, which would again require time and efforts. But it can be seen in near future.

Some of the very specific hardwares such as rtl8723 series do not have a functioning driver in regards to wifi, which though is hardware limitation but poses challenges to progMP.

Android and its future with MPTCP

We have seen the installation of MPTCP on a kk 4.4 device, which went flawlessly. Currently the android version is very far ahead of 4.4, which is something that is disappointing. It might be a very beautiful future with MPTCP on handheld devices but it shows that it needs works to be done. With current changes in libc version and also major modifications, MPTCP might be far away. Again being caught between proprietory solutions and non proprietory ones will certainly hamper the progress of MPTCP in future.

Conclusion

Throughout the seirs of Experiments, we have observed the following things:

Future scope

Multipath TCP was designed to be backward compatible with regular TCP. As such, it can support any application. However, some specific deployments leverage the ability of simultaneously using different paths.

Apples usage of MPTCP demonstrate how effective it can be in real life scenarios and works flawlessly. It can be even said that MPTCP is a far more secure model,.

Other deployment use Multipath TCP to aggregate the bandwidth of different networks. For example, several types of smartphones, notably in Korea, use Multipath TCP to bond WiFi and 4G through SOCKS proxies.

In a more simpler terms, MPTCP has also proven well to provide client side load balancing without any need of nulky/costly equipments.

Henceforth, MPTCP not only has extended the capabilities of internet in households but also in industries areas and cloud networking.

Other than these, It has been noted that since the subflows are split across multiple interfaces it prevents even the capturing of packets there by preventing MITM and identical attacks. DNS resolution over MPTCP allows faster internet resolutions, and seggregation of workload enables far more effective utilisation.

If these were not enough, it is something that is even being developed (or rather have its tools developed by NASA itself)

The further developments points that could be summarized from analysis and discussion:

References