Article Preview
TopIntroduction
Nowadays, technology is evolving day by day and most of the work is done by the internet. Therefore, the demand for internet bandwidth is very popular. Another reason for increased internet bandwidth demand is due to coronavirus disease 2019 (COVID-19) pandemic and lockdown policy. COVID-19 changed our daily life drastically, mostly employees are working from home, patients are taking treatment online, students are learning from home, etc. for the same, a good internet bandwidth is required for everyone to do work seamlessly. Most internet-based devices, such as IoT devices, mobile phones, computers, etc., are multihomed devices that have multiple interfaces. In this COID-19 era, almost users have multihomed devices to use the internet and each user has multiple active networks at a time like Wi-Fi, cellular network, etc. Even though, most users are not able to use a high bandwidth internet due to traditional protocols (TCP, UDP) limitations. The traditional single-path TCP (SPTCP) does not acquire the advantage of multiple interfaces and hence, the researchers proposed a new Multipath TCP (MPTCP) mechanism that is an E-Adoption of Emerging technology, which utilizes the bandwidth of multiple connections simultaneously (Hesmans et al., 2015; Ramaboli et al., 2012). It is an extension of SPTCP and is applicable in all the applications used in SPTCP (Ford et al., 2012).
The MPTCP uses multiple connections for transmission simultaneously. If one or more connections fail in the middle of a transmission, data of that path will still be transferred through other paths and data transmission will continue. MPTCP provides the reliability, utilization of the available resources, and gives better performance. Whereas, the problem with SPTCP is the transmission of the data is stopped when the connection break in the mid of the transmission. Nowadays, SPTCP is used in various applications such as client server-based networks, Datacenter networks (DCN) (Chaturvedi & Chand, 2018; Lu, 2016), etc., but as authors know due to the increasing demands of internet applications, the size of a datacentre become increased. The Large DCN provides many paths between any two nodes, but SPTCP only uses one path at a time; hence it fails to utilize the available bandwidths of the network and gives poor performance. The MPTCP solves this problem by using all available paths (connections) in DCN simultaneously.
The MPTCP divides the single data stream into multiple subflows (c.f. Fig. 1). Each subflow has its round-trip time (RTT) and congestion window (CW) and it is treated as an individual path of SPTCP by other nodes. The main challenge with MPTCP is distributing the load among available subflows (load balancing) of a source due to path heterogeneity (paths with different CW, RTT, and data flow rates) so that the receiver can receive the packets in order with maximum throughput.
The MPTCP has two main components by which it distributes the data packets among multiple available paths: the congestion controlling component and the packet scheduling component. A congestion control algorithm chooses the breadth of CW for a path and a packet scheduler schedules packets for a path. The proper size selection of CW avoids the problems of load balancing, friendliness, and responsiveness (Chaturvedi & Chand, 2020b). An MPTCP algorithm is said to be TCP friendly if no one path of MPTCP takes the bandwidth more than the SPTCP on the best path and the rate of change in the network performance is measured by responsiveness. A good packet scheduler avoids the HoL-blocking problems by providing the in-order delivery, reducing the packet delay, and transferring the maximum number of packets with the minimum loss (Chaturvedi & Chand, 2020a). An MPTCP with a good congestion control algorithm and a good packet scheduler can better use the communication capacity of available paths and resolve the existing problems. Many researchers have proposed different MPTCP congestion control algorithms (Khalili et al., 2013; Raiciu et al., 2011; Walid et al., 2016) and packet schedulers (Paasch et al., 2014; Frömmgen et al., 2017; Hwang & Yoo, 2015; Kimura et al., 2017; Sarwar et al., 2013; Yang et al., 2014; Lim et al., 2017; Hurtig et al., 2018).