> On 25 May, 2020, at 8:17 am, Avakash bhat <[email protected]> wrote: > > We had another query we would like to resolve. We wanted to verify the > working of ack filter in ns-3, > so we decided to replicate the Fig 6 graph in the CAKE > paper(https://ieeexplore.ieee.org/document/8475045). > While trying to build the topology we realized that we do not know the number > of packets or bytes sent from > the source to the destination for each of the TCP connections ( We are > assuming it is a point to point connection with 4 TCP flows). > > Could we get a bit more details about how the experiment was conducted?
I believe this was conducted using the RRUL test in Flent. This opens four saturating TCP flows in each direction, and also sends a small amount of latency measuring traffic. On this occasion I don't think we added any simulated path delays, and only imposed the quoted asymmetric bandwidth limits (30Mbps down, 1Mbps up). > Also is this the best way to verify the correctness of our implementation? Obviously with limited space in our paper, we could only include a small selection of test results. Many other tests were run in practice, and we have expanded our test repertoire since. In particular, we now routinely run tests with a simulated typical Internet path delay inserted, eg. 20ms, 80ms, 160ms baseline RTTs to represent reaching a local-ish CDN, across the Atlantic, and from Europe to the US West Coast. You will also want to include multiple traffic mixes in the analysis, in particular different congestion control algorithms (at least Reno and CUBIC), and running with ECN both enabled and disabled at the endpoints. A useful torture test we used was to send many bulk flows up the narrow side of the link and a single bulk flow down the wide side. For example, 50:1 flow counts with 1:10, 1:20 and 1:30 bandwidth asymmetries. The acks of the single flow then have to compete with the heavy load of the many flows, and the total goodput of that single flow is an important metric, along with both the total goodput and the Jain's fairness of the upload traffic. This should show a particularly strong effect of the ack filter, as otherwise individual acks have to be dropped by the AQM, which Codel is not very good at adapting to quickly. In evaluating the above, you will want to be vigilant not only for observed gross performance, but also the extent to which the ack filter preserves or loses information from the ack stream. This is particularly true in the runs without ECN, in which congestion signals can only be applied through packet loss, and the feedback of that signal is through dup-acks and SACK. I think you will find that the "aggressive" setting loses some information, and its performance suffers accordingly in some cases. - Jonathan Morton _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
