# On Cross-Layer Interactions for Congestion Control in the Internet
## 5 Performance Evaluation
### Data Center Scenario, Common TCP
\begin{table}
\begin{tabular}{c c c c c} \hline \hline  & \multicolumn{2}{c}{**DT**} & **PIE** & **CoDel** \\ \hline \multirow{3}{*}{UC} & NReno & 56.72/83.54/145.79 & 100.83/102.17/105.78 & 98.32/99.55/108.67 \\ \cline{2-5}  & Cubic & 49.91/84.06/138.36 & 96.60/100.70/109.61 & 98.67/99.84/108.67 \\ \cline{2-5}  & C-TCP & 85.47/107.47/118.63 & 86.29/89.57/130.91 & 81.03/90.47/136.61 \\ \hline \multirow{3}{*}{MC} & NReno & 2.40/5.65/14.15 & 9.98/10.45/10.85 & 10.02/10.44/10.82 \\ \cline{2-5}  & Cubic & 0.00/0.04/23.41 & 9.93/10.26/10.89 & 10.07/10.46/10.84 \\ \cline{2-5}  & C-TCP & 7.52/10.09/11.14 & 10.05/10.41/10.91 & 10.00/10.43/10.79 \\ \hline \multirow{3}{*}{HC} & NReno & 0.00/0.00/0.00 & 0.95/1.05/1.14 & 0.98/1.06/1.14 \\ \cline{2-5}  & Cubic & 0.00/0.00/0.00 & 0.94/1.04/1.16 & 0.94/1.05/1.17 \\ \cline{2-5}  & C-TCP & 0.00/0.00/0.02 & 0.96/1.05/1.14 & 0.98/1.06/1.14 \\ \hline \end{tabular}
\end{table} 
Table 2: Quartiles of flows’ throughput [Mbps] in the Data center scenario with common TCPs, UC—uncongested, MC—mildly congested, HC—heavily congested network. \begin{table}
\begin{tabular}{c c c c c} \hline \hline  & \multicolumn{2}{c}{**DT**} & **PIE** & **CoDel** \\ \hline \multirow{3}{*}{UC} & NReno & 0.75 & 1.00 & 0.99 \\ \cline{2-5}  & Cubic & 0.70 & 1.00 & 1.00 \\ \cline{2-5}  & C-TCP & 0.97 & 0.96 & 0.94 \\ \hline \multirow{3}{*}{MC} & NReno & 0.48 & 1.00 & 1.00 \\ \cline{2-5}  & Cubic & 0.25 & 0.99 & 1.00 \\ \cline{2-5}  & C-TCP & 0.88 & 1.00 & 1.00 \\ \hline \multirow{3}{*}{HC} & NReno & 0.16 & 0.98 & 0.99 \\ \cline{2-5}  & Cubic & 0.12 & 0.97 & 0.98 \\ \cline{2-5}  & C-TCP & 0.19 & 0.98 & 0.99 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: [PERSON]’s index (fairness) among long-lived flows in the Data center scenario with common TCPs, UC—uncongested, MC—mildly congested, HC—heavily congested network. During heavy congestion, PIE results in notably smaller average queue size and much lower queue size variations than any other buffer management strategy. In Figure 4, it is visible that PIE allows filling the buffer at first but eventually stabilizes the queue around the target value. CoDEL with any TCP introduces enormous variability. The queue oscillates between the maximum and the target value, which results in high latency variations. In Table 5, the summarized drop ratio at the bottleneck bandwidth is listed. In the uncongested network, the drop ratio is negligible. When the traffic load increases, the number of losses intensifies. It may appear that the best results in terms of packet loss ratio may be achieved when DT is used, but we have to keep in mind that in the mildly or heavily congested networks, only some part of all flows can perform an effective transmission. In all cases with any AQM, the drop ratio is comparable. Note that PIE with all TCPs causes a slightly higher drop ratio than CoDel and TCP Cubic with any AQM leads to more losses in comparison to New Reno or C-TCP. The presented results reveal that regardless of the applied TCP, there are problems that can be addressed by improving the buffer management strategy. As the congestion grows, CoDel has difficulty in maintaining a short and stable queue. The CoDel's sensitivity to network load was suggested in [11], and the above results confirm this dependence in a high-speed network scenario. CoDel allows filling the whole buffer because, during the dropping state, it drops a packet every \(\mu\), which is updated as per Equation (5) and under heavy congestion, it is not enough. To prevent this behavior, the update parameter should be tuned to provide faster response time in high-speed networks. The default value of \(\lambda\) is set to the value of nominal RTT, and in this scenario the average RTT is 500 times