[Cake] Testing Scenarios for Validation of Ack_Filter implementation in ns-3
Hello everyone, I have implemented Ack_Filter component of CAKE in ns-3. Link: https://github.com/ShefaliGups11/Ack_Filter/commits/Ack_Filter It would really help if you could suggest the testing scenarios so that I can validate Ack_Filter implementation in ns-3. Thanks and regards, Shefali Gupta ___ 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, We have added CoDel and PIE graphs for Heavy and Mix scenarios. Link: https://github.com/Daipu/COBALT/wiki/Heavy-Traffic https://github.com/Daipu/COBALT/wiki/Mix-Traffic Also we have added drop-event logs for the same scenarios. Link: https://github.com/Daipu/COBALT/wiki/Drop-Timestamp-Files Thanks and Regards, Shefali Gupta Jendaipou Palmei On Fri 25 Jan 2019, 2:46 p.m. Jonathan Morton > On 25 Jan, 2019, at 10:35 am, Shefali Gupta > wrote: > > > > We have updated all the graphs with updated COBALT code and BQL enabled. > > The graphs available so far do show a big improvement in behaviour. Could > you also add comparative data for Codel and PIE in the Heavy and Mix > scenarios? It seems reasonable to also generate drop-event logs for those > scenarios. > > - 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
Hi Jonathan, Thanks! First, we noticed that cobalt_cache_init method was not implemented in ns-3 COBALT, so we implemented it (but this wasn't the main reason for the wrong behaviour). Later, we found that the data types used in the implementation of COBALT in ns-3 were different from those used in Linux. e.g., uint32_t was used instead of int64_t for the variables with datatype ktime_t in Linux. Results improved considerably after these changes. We will update the wiki with latest results. Regards, Shefali Gupta Jendaipou Palmei On Wed 23 Jan 2019, 9:53 p.m. Jonathan Morton > On 23 Jan, 2019, at 6:19 pm, Shefali Gupta > wrote: > > > > We believe we have spotted the issue now. The new plot is attached below. > > That does look considerably improved. What was the problem in the end? > > Now would be a good time to regenerate all the test graphs, and make sure > there are results for each test for each qdisc tested. Ideally all graphs > should be generated from the same run(s), to ensure their data is mutually > consistent. > > - 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
Hi Jonathan, We believe we have spotted the issue now. The new plot is attached below. Does it look as expected? [image: Updated_Graphs.png] Thanks and regards, Shefali Gupta Jendaipou Palmei On Mon, Jan 21, 2019 at 6:27 PM Jonathan Morton wrote: > > On 21 Jan, 2019, at 1:35 pm, Shefali Gupta > wrote: > > > > We re-looked into the COBALT implementation to understand why it drops > the first packet later than CoDel. > > > > There was a bug in the data that was collected in 'drop timestamp > files'. We tried using a different approach to store packet drop times, and > now we see that COBALT indeed drops the first packet prior to CoDel's first > packet drop (image below). So the issue was that our previous approach of > storing the packet drop times in a file was not correct. > > > > Let us know your opinion. > > Okay, good catch. > > But the more serious problem is with the pattern of drops, which presently > looks much more like BLUE activity (random) than Codel (ramping > frequency). That seems to be unchanged in your new graph. > > Have you made any progress towards finding out why the queue is apparently > too short? Perhaps log the actual length of the queue when overflow drops > occur. > > - Jonathan Morton > > ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
[Cake] Query regarding COBALT implementation in CAKE
Hello Jonathan and Dave, We were trying to look into Linux Kernel CAKE code to understand COBALT implementation. We are unable to understand how over_target variable is being used to change the dropping state, on the line number 535 of CAKE code. We are referring to this CAKE code: https://elixir.bootlin.com/linux/latest/source/net/sched/sch_cake.c Thanks and regards, Shefali Gupta Jendaipou Palmei ___ 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
Hi Dave, Thanks for the feedback. We will check with the maintainer of traffic-control module in ns-3 about the correctness of BQL, and also try to obtain plots that show the steady state behaviour as you suggested. In the meantime, we have added the following plots to our wiki: 1. Number of packet drops per time interval Link: https://github.com/Daipu/COBALT/wiki/Proactive-Drop-Count-per-time-interval-graphs 2. A file showing the timestamp of each drop Link: https://github.com/Daipu/COBALT/wiki/Drop-Timestamp-Files I believe our advisor might have already communicated with you and Jonathan for the timings of the videoconference. Thanks and Regards, Shefali Gupta Jendaipou Palmei On Sun, Dec 16, 2018 at 1:40 AM Dave Taht wrote: > Thank you for doing this. I'm now unconvinced the BQL emulation in NS3 is > accurate. > > Loved the combined graphs! While it is important to capture that initial > load spike and indeed, draw it out in the paper, being able to see a bit > more detail in steady state would be good. So showing T-0 -> T-3 and T-3 > forward would let you use different scales for each. > > I'd kind of like to take a step back and try to construct a paper out of > this that could be published at > usenix or acm next year. It's getting towards the holidays but would y'all > (and your advisor(s)) be available to meet via videoconference sometime > next week? I'm in california, jonathon - somewhere in europe - so that > might be hard. > > > > > On Sat, Dec 15, 2018 at 11:06 AM Shefali Gupta > wrote: > >> Hello Jonathan, >> >> Thanks for your feedback. >> >> As suggested, we have produced CoDel and PIE graphs with small NIC buffer >> and uploaded the corresponding graphs. >> >> Link: >> https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Different-NetDeviceQueue-size >> >> We have also uploaded one way end-to-end dela*y* graphs in Light traffic >> scenario for CoDel, COBALT and PIE. >> Link: https://github.com/Daipu/COBALT/wiki/End-To-End-Delay-Graphs >> >> Thanks a lot for your help. We really appreciate it. >> >> Regards, >> Shefali Gupta >> Jendaipou Palme >> >> On Mon, Dec 10, 2018 at 8:45 PM Jonathan Morton >> wrote: >> >>> > On 10 Dec, 2018, at 2:30 pm, Jendaipou Palmei < >>> jendaipoupal...@gmail.com> 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 >>> >> ___ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >> > > > -- > > 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
Hello Jonathan, Thanks for your feedback. As suggested, we have produced CoDel and PIE graphs with small NIC buffer and uploaded the corresponding graphs. Link: https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Different-NetDeviceQueue-size We have also uploaded one way end-to-end dela*y* graphs in Light traffic scenario for CoDel, COBALT and PIE. Link: https://github.com/Daipu/COBALT/wiki/End-To-End-Delay-Graphs Thanks a lot for your help. We really appreciate it. Regards, Shefali Gupta Jendaipou Palme On Mon, Dec 10, 2018 at 8:45 PM Jonathan Morton wrote: > > 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 > ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Query Regarding Ack_Filter
Hello Jonathan, Thanks for the help. The information you provided was useful. We'll let you know if we have any questions. Thanks and Regards, Shefali Gupta Jendaipou Palmei On Wed, Dec 12, 2018 at 5:33 PM Jonathan Morton wrote: > > On 12 Dec, 2018, at 1:42 pm, Shefali Gupta > wrote: > > > > We're trying to implement Ack_Filter in ns-3, while working on your > suggestions in parallel for validating the implementation of COBALT in ns-3. > > > > As far as we understand, we need TCP header information related to SACK > Blocks, ECN, Source Port, SYN flag, ACK Flag, etc for Ack_Filter to work. > > > > Since Cake will be deployed at network devices, we're not able to figure > out how will be the (higher layer) information accessible. > > > > Are we missing out on something that is very obvious? > > The ack-filter is essentially a Layer-4 feature, which does require > unpacking the packet a bit further than usual. In principle it's no > different from the steps needed to unpack a Layer-2 packet to read the > Layer-3 IPv4 or IPv6 headers for routing and flow hashing, or applying an > ECN mark. > > First check whether the next-level protocol is one that's relevant and > understood, then look at the appropriate offsets to find the header data > required. That's basically what Cake does, via some basic helper macros > which are provided by Linux. > > Probably ns-3 has some helper API to do that for you; if not to extract > the fields and flags of the TCP header, then at least to locate it. You > just need to find the right API. > > - Jonathan Morton > > ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
[Cake] Query Regarding Ack_Filter
Hello Jonathan and Dave, We're trying to implement Ack_Filter in ns-3, while working on your suggestions in parallel for validating the implementation of COBALT in ns-3. As far as we understand, we need TCP header information related to SACK Blocks, ECN, Source Port, SYN flag, ACK Flag, etc for Ack_Filter to work. Since Cake will be deployed at network devices, we're not able to figure out how will be the (higher layer) information accessible. Are we missing out on something that is very obvious? Thanks and Regards, Shefali Gupta Jendaipou Palmei ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
Re: [Cake] Query Regarding CAKE
Hi Jonathan, Thanks for your feedback. We're close to completing the implementation of COBALT based on that link which we shared in our earlier email. Yes, we will try and implement the Cake modules in ns-3 such that they can be used in different combinations. Thanks and Regards, Shefali Gupta Jendaipou Palmei ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
[Cake] Query Regarding CAKE
Hello Jonathan and Dave, Thanks for the quick replies. We took sometime to understand the whole framework and have come up with some more queries: 1. Can we use the COBALT code available on the following link as a reference: https://github.com/dtaht/sch_cake/blob/old-master/cobalt.c 2. Since ns-3 code is in C++, we're hoping to implement the different modules (four modules as mentioned in LANMAN paper) of Cake in separate classes. Is that approach fine? or you recommend us to implement all modules in a single file as done in Linux? Thanks and Regards, Shefali Gupta Jendaipou Palmei ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
[Cake] Query Regarding CAKE
Hi all, We're working on the implementation of CAKE in ns-3, but have been facing an issue about finding resources on COBALT (algorithm / pseudo code). In the LANMAN paper on CAKE, we did not find much detail about COBALT. Can anyone provide us resources on COBALT. Congratulations on getting CAKE in the Linux mainline! Thanks, Shefali Gupta Jendaipou Palmei NITK Surathkal, India ___ Cake mailing list Cake@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cake
