I found a logical error in the code.

[YuTao-Zhangyy]

Dear author,

I've noticed that the logic in the source code for determining whether to return ACK/NACK is incorrect. The logic in the source code only ensures that the return cycle of the first ACK/NACK is L2_ACK_INTERVAL, and after the first ACK/NACK, ACK/NACKs are returned for each packet. The reason for this phenomenon is that, as shown on the left side of Figure 1, m_milestone_rx of rxQp is updated every time a UDP packet is received. This update is incorrect. The update of rxQp->m_milestone_rx should be incremented after each return of ACK/NACK. Figures 1 and 2 below represent the correct combination.

Additionally, I've made a strange and novel discovery. When I modify the L2_ACK_INTERVAL configuration (for example, changing it from 1 to 20000, which means returning an ACK/NACK for every 20 packets) and the logic for returning ACK/NACK (as described above), and when the congestion control algorithm is HPCC, if the number of flows is greater than 1 (for example, there are more than two 10MB traffic flows), the simulation ends before the flows are completed (the QP still has remaining data, as shown in Figure 3). This phenomenon is specific to the HPCC algorithm. The DCQCN, TIMELY, and DCTCP algorithms can complete the traffic under the same conditions. Could you help me analyze the reason for this? This problem has troubled me for a long time, and I hope to get your response.