# Performance Impact of Nested Congestion Control on Transport-Layer Multipath Tunneling
## 3 Related Work  
The work described in this paper rests at the intersection of (i) transport-layer congestion control, (ii) multipath, and (iii) tunneling. Although there is a plethora of related research, previous work has focused only on some specific aspects. While there is work on TCP-in-TCP single-path tunneling, the effects investigated in this paper do _not_ appear _without_ a multipath packet scheduler and having multiple paths. Similarly, much of the work on multipath scheduling does not consider the performance if there is a congestion control algorithm running on top of the scheduler, _which is the case in the tunneling context_. Traditionally, CC in multipath networks has been considered an important challenge since the early works on integrated routing and CC in multipath networks [14] and in the general case of wireless mesh networks [15]. MPTCP, the dominant multipath transport-layer protocol, establishes a connection composed of multiple sub-flows, each one managing its own individual CC and re-transmission states. A known design problem with CC in MPTCP is presented in [16], and MPTCP CC approaches are summarized in [17]. Originally, each MPTCP sub-flow CC instance was independent, i.e., uncoupled. However, due to unfairness when run in parallel with single-path TCP flows [18], new semi-coupled and closely coupled algorithms emerged that limited the increase in the congestion window variable on some paths. Although the aforementioned research did address _parallel_ congestion control, it did not address the interactions between _nested_ congestion control approaches which arise when a transport-layer tunnel is deployed; the latter is the focus of this paper, and is made highly relevant by, e.g., the 5G ATSSS architecture. Other work [19] has shown the limitations of coupled CC in wireless networks, where the _head-of-line_ (HoL) blocking problem of MPTCP is further increased due to the volatility of wireless links, and packet loss due to transmission errors and re-transmissions negatively affect both the average throughout and its stability. MP-QUIC [3] can overcome HoL blocking with QUIC's stream-based semantic, demonstrating an advantage over TCP, which lacks streams. However, multipath HoL blocking remains a potential issue as long as a flow or a stream is _split_ over multiple paths and is particularly pronounced if the protocol is reliable and thereby _never_ release packets out of order. Other avenues that have been explored in CC in multipath environments include the application of reinforcement learning [20], or deep-Q learning [21]. While this is interesting from our perspective, our attempt in this paper is primarily to identify performance problems. Another approach is using forward error correction (FEC) to help with the head-of-line blocking [22]. FEC or network coding has been combined with rate allocation on different paths to maximize the performance in some of the works [23; 24]. Finally, solutions have been proposed for application-layer congestion management for video streaming and real-time video traffic in multipath [25; 26], utilizing delay information to address congestion earlier compared to when using loss-based algorithms. Multipath solutions may be deployed at different levels in the network stack. A multipath tunnel solution at the _network layer_[10; 27; 28] has the advantage that the Internet Protocol (IP) is universally used, and that _any_ transport-layer protocol can lay on top, i.e., _a single architecture can serve all traffic types._ The main advantage of splitting or converting at the _transport layer_[29; 30] is that many transport-layer protocols include CC and therefore also path state detection; however, any such solution can only handle a single transport-layer protocol; for instance, a solution that converts between TCP and MPTCP [31; 32] can only serve TCP traffic.