[Cake] NLNET's call for proposals w/funding avail
Amounts between 5k eu and 40k eu are available for the https://nlnet.nl/discovery/ & https://nlnet.nl/PET/ projects tackling search and discovery issues. Far, far, far more details are available off of those links. "Privacy isn't dead, but we lack the right tools to protect our intimacy." disclaimer: nlnet funded some of the cake and cerowrt work, and I sit on the commons conservancy's board currently, Proposals are due by feb 1. -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios
> On 10 Dec, 2018, at 2:30 pm, Jendaipou Palmei > wrote: > > As suggested, we changed the NIC buffer size to 1 packet for the simulation > and also tried these different buffer sizes: 10, 50 and 75. > > The default NIC buffer size in ns-3 is 100 packets. > > Additionally, we also enabled BQL and tried. > > We see that the link utilization gets significantly affected when we keep the > NIC buffer size small. Yes, that's what I'd expect to see from Reno-type congestion control, and is one good reason why alternatives to Reno were developed (eg. Compound, CUBIC, BBR). You may wish to explore what happens with Compound and CUBIC, once your basic measurement methodology has matured. I would suggest using BQL, since it's available and represents a realistic deployment. If you were to add TCP (or parallel UDP/ICMP) RTT measurements, you'd see that the peak latency was correspondingly improved by removing the dumb FIFO hidden within the NIC. I estimate that a 100-packet buffer accounts for about 120ms of latency at 10Mbps, which should definitely be visible on such a graph (being almost 250% of your baseline 50ms latency). Since latency is the main point of adding AQM, I'm a little surprised that you haven't already produced graphs of that sort. They would have identified this problem much earlier. At present you only have COBALT graphs with the small NIC buffer. For a fair comparison, Codel and PIE graphs should be (re-)produced with the same conditions. The older graphs made with the large NIC buffer are potentially misleading, especially with respect to throughput. - Jonathan Morton ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios
Hello Jonathan, Thanks for your feedback. As suggested, we changed the NIC buffer size to 1 packet for the simulation and also tried these different buffer sizes: 10, 50 and 75. The default NIC buffer size in ns-3 is 100 packets. Additionally, we also enabled BQL and tried. We see that the link utilization gets significantly affected when we keep the NIC buffer size small. The results are put up on the following link: https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Different-NetDeviceQueue-size Thanks and Regards, Jendaipou Palmei Shefali Gupta On Sun, Dec 9, 2018 at 6:51 PM Jonathan Morton wrote: > > On 9 Dec, 2018, at 10:37 am, Jendaipou Palmei > wrote: > > > > By hidden queues, do you mean the NIC buffers? ns-3 has a Linux-like > traffic control wherein the packets dequeued by a queue discipline are > enqueued into NIC buffer. > > That's right. Linux now uses BQL, which (given compatible NIC drivers) > limits the number of packets in the NIC buffers to a very small value - > much smaller than is evident from your data. If you were to measure the > end-to-end RTT of each, I'm certain you would see this effect dominating > the mere 50ms latency you're trying to model. > > Ideally, AQM would applied to the hardware queue anyway. For simulation > purposes, I recommend reducing the NIC buffer on the bottleneck interface > to 1 packet, so that the simulated AQM's effects are easiest to measure. > > - Jonathan Morton > > ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
