## 5 Performance Evaluation
### Basic Performance Evaluation
#### 5.1.2 Queuing Delay  
In this section, we evaluate the impact of different buffer management mechanisms on the queuing delay of individual packets across four different scenarios. The experimental results are shown in Figure 8. The colored dashed lines represent the average queuing delay across all packet sizes. In all scenarios, the queuing delay increases with packet size under each mechanism. This is because the data flows, simulated with a Pareto distribution, show a positive correlation between flow and packet sizes. Larger flows require more buffer space and processing time for reordering, resulting in higher buffer loads. In all scenarios, the queuing delay under the CS consistently remains high, particularly for larger packet sizes (512-1024 bytes), where the delay is significantly elevated. This suggests that the absence of a buffer management mechanism leads to excessive queuing delays. In contrast, the average queuing delays under the ST, DT, and DT + RED are noticeably lower than those of CS, as indicated by the dashed lines in the figure. These strategies allocate reserved buffer space, allowing them to retain incoming packets and evict packets with smaller sequence numbers when the threshold is reached. In contrast, CS evicts packets indiscriminately. Packets with smaller sequence numbers benefit more from the IP terminals' out-of-order correction capabilities, increasing the likelihood of successful delivery. Nevertheless, ST performs poorly for large packets, suggesting that a static threshold setting makes it difficult for the buffer to handle congestion caused by large packets. In Scenario 2, the queuing delay under the DT and DT + RED increases with packet size, with the DT + RED outperforming the DT across all packet sizes. However, in Scenario 1, which has significant delay differences, and in Scenarios 3 and 4, which have significant bandwidth differences, the queuing delays for different packet sizes begin to fluctuate. For instance, in Scenario 1, the queuing delay for 64-128 byte packets under the DT + RED is longer than that for packets sized 128-256 bytes; in Scenario 3, the queuing delays for packets sized 128-1024 bytes under the DT + RED are nearly identical; and in Scenario 4, the queuing delay for 64-128 byte packets under the DT + RED is longer than that for packets sized 128-128-128 byte; in Scenario 3, the queuing delays for packets sized 128-128-128 byte; in Scenario 4, the queuing delay for 64-128 byte packets under the DT + RED are nearly identical; and in Scenario 5, the queuing delay for 64-128 byte packets under the DT + RED  
Scenario 4, the queuing delay for 128-256 byte packets under the DT is longer than that for packets sized 256-512 bytes. These observations suggest that although the classical DT and DT + RED can reduce average queuing delays, there is still room for improvement in ensuring fairness. In the RCBRB method, the queuing delay increases with packet size across all scenarios without showing significant fluctuations. This can be attributed to RCBRB's approach of maintaining independent buffers for each flow, which effectively reduces competition among flows of different sizes. However, while the queuing delay for various packet sizes performs well, the method's consumption of buffer resources cannot be overlooked. RCBRB allocates a minimum buffer space for each flow (\(SFS\geq 2\times BDP_{i}\)) and dynamically adjusts this space based on the volume of data arriving within a time window. Although this mechanism minimizes congestion and packet loss, it results in notable buffer resource wastage. Specifically, in Scenarios 1 to 4, RCBRB consumes 1.711, 1.434, 1.359, and 1.783 times the buffer resources used by the RBMM method, respectively. Furthermore, the queuing delay for the largest packet size (512-1024 bytes) exhibits the greatest deviation from RBMM. This is because RCBRB frequently performs iterative searches within the queue to locate packets, which incurs significant network overhead when handling large flows, thereby impacting performance.