Open Access

ARTICLE

Coupled CUBIC Congestion Control for MPTCP in Broadband Networks

by Jae Yong Lee¹, Byung Chul Kim¹, Youngmi Kwon^1,*, Kimoon Han²

1 Department of Information and Communications Engineering, Chungnam National University, Daejeon, 34134, Korea
2 Agency for Defense Development, Daejeon, 34186, Korea

* Corresponding Author: Youngmi Kwon. Email:

Computer Systems Science and Engineering 2023, 45(1), 99-115. https://doi.org/10.32604/csse.2023.030801

Received 02 April 2022; Accepted 14 June 2022; Issue published 16 August 2022

Abstract

Recently, multipath transmission control protocol (MPTCP) was standardized so that data can be transmitted through multiple paths to utilize all available path bandwidths. However, when high-speed long-distance networks are included in MPTCP paths, the traffic transmission performance of MPTCP is severely deteriorated, especially in case the multiple paths’ characteristics are heavily asymmetric. In order to alleviate this problem, we propose a “Coupled CUBIC congestion control” that adopts TCP CUBIC on a large bandwidth-delay product (BDP) path in a linked increase manner for maintaining fairness with an ordinary TCP traversing the same bottleneck path. To verify the performance excellence of the proposed algorithm, we implemented the Coupled CUBIC Congestion Control into Linux kernels by modifying the legacy MPTCP linked-increases algorithm (LIA) congestion control source code. We constructed asymmetric heterogeneous network testbeds mixed with large and small BDP paths and compared the performances of LIA and Coupled CUBIC by experiments. Experimental results show that the proposed Coupled CUBIC utilizes almost over 80% of the bandwidth resource in the high BDP path, while the LIA utilizes only less than 20% of the bandwidth for the same path. It was confirmed that the resource utilization and traffic transmission performance have been greatly improved by using the proposed Coupled CUBIC in high-speed multipath networks, as well as maintaining MPTCP fairness with competing single-path CUBIC or Reno TCP flows.

---

Keywords

---