> On 22 Apr, 2019, at 2:45 pm, Shefali Gupta <shefaligup...@gmail.com> wrote: > > It would really help if you could suggest the testing scenarios so that I can > validate Ack_Filter implementation in ns-3.
It may help to understand the design intentions of the ack-filter: 1: Reduce the bandwidth consumed by pure acks, and possibly also the latency of the ack stream. 2: Avoid losing any relevant information from the ack stream. This particularly includes not erasing any "tail" acks and not interfering with any SYN, FIN or RST packets. To test the latter, you really need a correctness analysis, but it should be sufficient to observe no reduction in performance across a wide range of scenarios, including those involving application-limited workloads (with a lot of tail acks), many short flow starts, continuous transfers with various amounts of packet loss in the forward direction, and cases where ack-filter activity is intense. That last scenario will involve a demonstration of point 1, which is best achieved by setting up an asymmetric link, then running one flow over the "wide" direction but many flows over the "narrow" direction. A 10:1 bandwidth ratio with a 1:50 flow setup should do the trick. The ack filter should greatly improve the throughput of the single, fast flow, and also free up a little bandwidth on the slow side for the many flows. As an aside, in the current Cake version we treat the former NS bit the same way as the ECE and CWR bits in the ack filter, so you may want to ensure this tweak is also made in your version. This is to improve its behaviour on SCE traffic. The change should have no effect on non-SCE traffic. - Jonathan Morton _______________________________________________ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
