<div dir="ltr">Thank you for doing this. I'm now unconvinced the BQL emulation in NS3 is accurate.<div><br></div><div>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.</div><div><br></div><div>I'd kind of like to take a step back and try to construct a paper out of this that could be published at </div><div>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.</div><div><br><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Dec 15, 2018 at 11:06 AM Shefali Gupta <<a href="mailto:shefaligups11@gmail.com">shefaligups11@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello Jonathan,<div><br></div><div>Thanks for your feedback.</div><div><br></div><div>As suggested, we have produced CoDel and PIE graphs with small NIC buffer and uploaded the corresponding graphs.</div><div><br></div><div>Link: <a href="https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Different-NetDeviceQueue-size" target="_blank">https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Different-NetDeviceQueue-size</a></div><div><br></div><div>We have also uploaded one way end-to-end dela<em>y</em> <span class="gmail-m_-4579320136542864124gmail-m_-8594344936332727117gmail-m_-831754824358113493gmail-st"><em></em></span>graphs in Light traffic scenario for CoDel, COBALT and PIE.<div class="gmail-m_-4579320136542864124gmail-yj6qo gmail-m_-4579320136542864124gmail-ajU"><div id="gmail-m_-4579320136542864124gmail-:oh" class="gmail-m_-4579320136542864124gmail-ajR"><img class="gmail-m_-4579320136542864124gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div></div><div>Link: <a href="https://github.com/Daipu/COBALT/wiki/End-To-End-Delay-Graphs" target="_blank">https://github.com/Daipu/COBALT/wiki/End-To-End-Delay-Graphs</a></div><div><br></div><div><div><div>Thanks a lot for your help. We really appreciate it.</div><br class="gmail-m_-4579320136542864124gmail-m_-3569562379966085847gmail-m_-6857784068908698292gmail-Apple-interchange-newline"></div><div>Regards,</div><div>Shefali Gupta<br></div><div>Jendaipou Palme</div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 10, 2018 at 8:45 PM Jonathan Morton <<a href="mailto:chromatix99@gmail.com" target="_blank">chromatix99@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> On 10 Dec, 2018, at 2:30 pm, Jendaipou Palmei <<a href="mailto:jendaipoupalmei@gmail.com" target="_blank">jendaipoupalmei@gmail.com</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
> The default NIC buffer size in ns-3 is 100 packets.<br>
> <br>
> Additionally, we also enabled BQL and tried.<br>
> <br>
> We see that the link utilization gets significantly affected when we keep the NIC buffer size small.<br>
<br>
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.<br>
<br>
I would suggest using BQL, since it's available and represents a realistic deployment.<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
 - Jonathan Morton<br>
<br>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div>
_______________________________________________<br>
Cake mailing list<br>
<a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/cake" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><br>Dave Täht<br>CTO, TekLibre, LLC<br><a href="http://www.teklibre.com" target="_blank">http://www.teklibre.com</a><br>Tel: 1-831-205-9740</div>