# A Brief Review of Multipath TCP for Vehicular Networks
## 2 TCP and MPTCP  
### Overview of Studies on TCP  
Nowadays, most of applications utilize TCP to transmit data since TCP has a retransmission mechanism to retransmit lost packets, which ensures that all the data packets could be correctly delivered to the receiver. TCP also utilizes a congestion control algorithm (CC) [12] to adjust sending rate based on packet loss or delay in order to avoid network congestion. In contrast, UDP does not conduct retransmissions and congestion control. Therefore, most of the voice over IP (VoIP) applications utilize UDP to provide real-time and uninterrupted call. Errors such as packets losses have minor impacts on the audio output and are usually not noticed. Quick UDP Internet Connection Protocol (QUIC) [13; 14] is developed by Google. The QUIC specification draft has been released by IETF on January 2021. QUIC runs on top of UDP. It combines the functions of HTTP/2, TLS and TCP. For example, QUIC handles the flow control, crypto, and HTTP. The design goal of QUIC is to reduce the connection establishment time by eliminating a lot of round trips and realize reliable transmissions without sacrificing security. Conventional TCP and UDP live in kernel space so that it is very hard to make fundamental changes to the protocol. In contrast, QUIC is implemented in user space, and therefore it can be customized to specific network scenarios more easily. Similar to HTTP/2, QUIC supports multi-streaming. Moreover, QUIC can solve a head-of-line blocking problem which HTTP/2 cannot handle. However, QUIC has not been massively deployed and further investigations are required to verify its effectiveness and maturity. One of the most important concerns about QUIC is security. It is pointed out that standard TCP underutilizes the bandwidth greatly due to its additive increase/multiplicative decrease (AIMD) scheme [15]. There have been many studies related to TCP to improve its bandwidth utilization. They are mainly classified into three types, respectively, loss-based, delay-based, and hybrid approach. Loss-based approaches such as TCP CUBIC [16], STCP (scalable TCP) [17], and BIC-TCP (binary increase congestion control) [18], adjust the sending rate based on the packet loss. Among them, TCP CUBIC congestion control is currently the default congestion control mechanism in many Linux systems. When a packet loss occurs, CUBIC increases the cwnd value drastically when the TCP cwnd size is far from reaching the maximum value, and increases cwnd slowly when it reaches near the maximum value. In another word, there is a larger increase at a lower cwnd value, and smaller increase at a higher cwnd value. This results in different effects on different congestion conditions. The delay-based approach such as FAST TCP [19] and bottleneck bandwidth and round-trip propagation time (BBR) [20] adjusts the sending rate based on round trip time (RTT) variations. The BBR congestion control algorithm is developed by Google. It utilizes the estimated real-time bandwidth and round trip time to determine the data transfer rate, which would result in a much more accurate prediction of the congestion. A model is built to determine the transfer rate to maximize the data rate, which always adjusts the model based on the real time congestion measurement. BBR considers that the loss-based congestion control is ineffective, since packet losses can occur due to many factors, in addition to congestion. When the estimated round trip time starts to increase, BBR knows the congestion exists. However, BBR results in a high packet retransmission rate in shallow buffer and lossy networks. The hybrid approach [21] considers both the loss and delay in the control process of congestion window. It was argued that a blameless TCP protocol has to meet the following three requirements, specifically, efficiency, RTT fairness, and TCP fairness. However, it is difficult to satisfy all these three requirements. While STCP and BIC-TCP can achieve a relatively higher sending rate, they cause RTT unfairness and TCP unfairness.