# Performance Impact of Nested Congestion Control on Transport-Layer Multipath Tunneling
## 6 Conclusions and Future Work  
In this paper, we examined the viability of employing transport-layer multipath tunnels alongside the CPF scheduler. The driving scenario behind this investigation was the aspiration to efficiently utilize both cost-effective and expensive wireless access, such as wireless LAN and cellular networks. Our analysis showed various performance challenges associated with such a scenario. These challenges existed for both of the server CCAs assessed in this study and can be expected to exist for other algorithms as well. Specifically, when the server used BBR, aggregation occurred more or less perfectly or not at all. When the server used Cubic, the performance tended to improve gradually over time, with aggregation occurring if the transfer time or file size was sufficiently large.  
\begin{table}
\begin{tabular}{c c c} \hline
**CCA Combination** & **DLCT for CPF** & **DLCT for SRTT** \\ \hline Cubic over CCID5 & 124.3\% & 101.6\% \\ Cubic over BBR & 94.2\% & 75.7\% \\ Cubic over CCID2 & 92.4\% & 90.6\% \\ BBR over NewReno & 87.0\% & 65.4\% \\ BBR over CCID2 & 77.5\% & 66.1\% \\ Cubic over NewReno & 77.8\% & 67.5\% \\ BBR over BBR & 76.2\% & 65.8\% \\ Cubic over NewReno (static) & 70.2\% & 60.0\% \\ BBR over CCID5 & 67.9\% & 66.4\% \\ Cubic over BBRv2 (static) & 65.6\% & 61.1\% \\ BBR over BBRv2 & 59.9\% & 58.9\% \\ \hline \end{tabular}
\end{table}
Table 3: Average DLCT relative to no tunnel.  
A helpful conceptual framework for understanding these issues is to consider the distribution of the server's congestion window over multiple paths. A larger server CWND or a smaller CWND over the primary path both increase the likelihood that the server CWND is distributed over the secondary path. Therefore, it is advantageous to inflate the server CWND whenever possible and manage congestion on the primary path. Strategies that may help in this regard include: (i) adjusting the deployment of the proxy relative to the user; (ii) adjusting the bottleneck buffer size; (iii) deploying an AQM at the bottleneck buffer; (iv) changing the CCA used at the tunnel; (v) using a reliable tunnel protocol to allow for re-transmissions of packets within the tunnel; (vi) changing CPF such that it becomes aware of congestion and considers congestion states when making packet scheduling decisions over the different paths.  
Related to (v), a potential solution could involve implementing semi-reliability at the scheduler level, which is a planned area of future work. Finally, with respect to (vi) efforts have already begun to adjust CPF [49; 50]. Specifically, work has been conducted using BBR in the tunnel to enable CPF to leverage the bandwidth-delay product knowledge, which in turn allows for a more intelligent scheduling to limit congestion. Future work on this enhanced CPF scheduler will include enhancing its ability to handle dynamic paths with fluctuating capacity.  
Conceptualization, M.P., A.K., A.B., V.R. and M.A.; Methodology, M.P., A.K., A.B. and M.A.; Software, M.P.; Validation, M.P.; Formal analysis, V.R.; Investigation, V.R.; Resources, A.K. and M.A.; Writing--original draft, M.P.; Writing--review & editing, M.P., A.K., A.B., V.R. and M.A.; Visualization, M.P.; Supervision, A.K. and A.B.; Project administration, A.K. and M.A. All authors have read and agreed to the published version of the manuscript.  
The work has been partly funded by the Knowledge Foundation of Sweden grant 20220072-H-01, and the Bavarian State Ministry for Science and Art through the Hightech Agenda (HTA).  
No data is being made available for the work presented in the paper.  
[PERSON] is an employee of Deutsche Telekom (Germany). The authors declare no conflicts of interest.