# Performance Impact of Nested Congestion Control on Transport-Layer Multipath Tunneling
## 2 The Multi-Access Framework
### The MP-DCCP Protocol  
The Linux kernel MP-DCCP framework [7] represents a novel IP-compatible multipath architecture designed to support 5G-ATSS mobile scenarios where multiple network interfaces are available at the user equipment (UE), typically WiFi and 5G. Additionally, it can be deployed to support home access network scenarios, where the access gateway contains both fixed access links (e.g., an ADSL uplink), and wireless access links (e.g., 5G cellular). Built upon DCCP [8], MP-DCCP inherits modular congestion control (CC) support similar to TCP, together with unreliable UDP-like transport services. MP-DCCP encapsulates packets and transmits them across distinct DCCP tunnels serving two main objectives: (i) the integrated DCCP CC facilitates path quality estimation in terms of loss rate, bandwidth, and round-trip time (RTT); (ii) the tunnels ensure traffic redirection to the aggregation termination point or proxy. Layer 3 compatibility is ensured via virtual network interfaces, facilitating seamless integration into both UE and home gateway environments. Packets entering the virtual network interface are distributed across individual DCCP tunnels by a  
Figure 2: Experimental results illustrating the impact of nested CC under different configurations; gray bars show the standard deviation.  
scheduler, which selects for the transmission of each packet an appropriate DCCP socket that is bound on a specific interface routing over a specific wireless access.  
Figure 3 depicts the placement of scheduling, reordering, and congestion control instances within an MP-DCCP-based framework assuming downlink traffic (from the server on the Internet towards the UE). Here, the scheduling component is located in the proxy, which runs two separate CC instances over the two different paths spanning over the different access networks. Apart from CPF, other schedulers such as Shortest Round-Trip Time First (SRTT) and Out-of-Order Delivery for In-Order Arrival (OTIAS) [9] are available within the MP-DCCP framework. At the UE (in the donwstream direction) or at the proxy (for upstream packets, not shown in the Figure), the MP-DCCP framework can optionally reorder packets. Here, the reordering module processes the packets after it receives them from the respective tunnel endpoints. When a flow is distributed across multiple paths, packet scrambling may occur due to differences in path delays, leading to packets arriving out of sequence. The reordering module can adjust the timing of packets (denoted as Wait in the Figure) arriving earlier than expected, up to a predefined limit. This limit may either be static or adapt to variations in path delay, known as adaptive or dynamic reordering. Packet encapsulation with both global and path-specific sequence numbers facilitates this reordering process. Additionally, a mechanism for fast loss detection analyses received sequence numbers to identify lost packets, enabling the early release of delayed packets. Another strategy to mitigate packet scrambling and jitter involves enforcing delay equalization [10], which artificially delays packets received via the faster path by the difference in path delay experienced. For instance, if two paths exhibit delays of 10 and 30 ms, packets that need to be sent over the shorter path are delayed by an additional 20 ms. This kind of flexible release mechanism, when tuned properly, minimizes both packet scrambling and multipath head-of-line blocking, thereby making MP-DCCP an excellent candidate for tunneling traffic.