From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 160C73CB3D for ; Fri, 21 Dec 2018 05:37:58 -0500 (EST) Received: by mail-yb1-xb31.google.com with SMTP id q145so336298ybq.9 for ; Fri, 21 Dec 2018 02:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uz8ym67GnsmZ1aZzp9sYrF+Yj2XIvbqw0UutrKEHEK4=; b=CQGLJ2bR+dSJpFVw1NFpvPQKEpEWyT3+u+KnB6kpuzZouLtsBi0mgLJvBN25L6f97g ysA0bQiI40hYdc4W4Mh46Bj2k+NxAdMDiUXR+yHngXdTiYvqMUbt82y+McKpx9q+P226 1kDkJ87wJxP7wYZJjyaYDImuqFj1KaQz73os0Y600e/xbBLNQZsevsKA4wQvvAW3yQej RHj4DMqfjyAJ+ImW3Q/vgtROA2BZvYaK8AFZf/QSXNnihhO+xkU61mWmL/8cU1IWFvyk wFPCedriZTz4h1A357peYu8onRrz2YOCUGai0Dnn9o0QbcIa2GdIXj0E0ZHuGZmKusrR ZN6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uz8ym67GnsmZ1aZzp9sYrF+Yj2XIvbqw0UutrKEHEK4=; b=k2IlXyFL9uPalrZ50xZK0+CcDlozi62RUHdoOfakQKGKG3vyspuwgfCTIy8Po/7xY3 dhOemPN6nLAWUerRKLQCFuyICj4G7mwDPhZ3uh8aHLdfULw3x8HpDXXTL3VSgLaG8bU2 cWZcWstjL9W+Jzka+EPbhu17IssIReMcDAugysY6Ry7gdMX3kpiSd/7K9bJ4v2+vz/mu BTEmyl6gkMvCHJrKTDIZnFtdBGQpaq3wbfrETmvlr6oL2ATIhUvPaY6Aiw1+oPQS3PH3 c7yxaGCaPNt2Zboc1eSL33UfFh0G9/YpsBNwnWHi2WcVZYAxSHSStk47Fr4WHyb7ibHP illA== X-Gm-Message-State: AA+aEWZrWFz2v+IjKWaTo9G/WElRwfUL1QcOE99tGhaO6knf7b6AnLJJ xibnxX1lxaqqKln1FkHoHM1/hfxN3TIMSGn0XIY= X-Google-Smtp-Source: ALg8bN5bh5TMflUZJBM1J1nAXYDCubzOPJV1Td0voZilavl9O3/R4m9X9XsJOVL/yI4ObZo9HqO7ZWFS45aKxOAkDjA= X-Received: by 2002:a25:bb90:: with SMTP id y16-v6mr1783784ybg.321.1545388677414; Fri, 21 Dec 2018 02:37:57 -0800 (PST) MIME-Version: 1.0 References: <87va4nzsn4.fsf@taht.net> <6578A0D1-FF6A-474E-A6D5-98185F98CB45@gmail.com> <08381337-F99A-46D1-87AF-B0F71A8753BC@gmail.com> <949D58FF-9C2F-4516-8547-20A712EC0C92@gmail.com> <271B3584-068F-4FED-B037-B8E920A9EE55@gmail.com> <70BDD881-B509-43FE-81BB-E9C4B1145FA1@gmail.com> <8467184E-7C35-4AFE-9CC6-292215022FDB@gmail.com> <4487BE09-D5D9-4F54-B652-409E50CB4BF4@gmail.com> In-Reply-To: From: Shefali Gupta Date: Fri, 21 Dec 2018 16:07:46 +0530 Message-ID: To: Dave Taht Cc: Jonathan Morton , Cake List Content-Type: multipart/alternative; boundary="00000000000028458c057d85d7dc" Subject: Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2018 10:37:58 -0000 --00000000000028458c057d85d7dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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'al= l > (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 buffe= r >> and uploaded the corresponding graphs. >> >> Link: >> https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Differ= ent-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 < >>> jendaipoupalmei@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 Compo= und >>> 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 accoun= ts >>> for about 120ms of latency at 10Mbps, which should definitely be visibl= e 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=C3=A4ht > CTO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-831-205-9740 > --00000000000028458c057d85d7dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dave,

Thanks for th= e feedback.

We will check with the maintainer of traffic-control module in ns-3 about=20 the correctness of BQL, and also try to obtain plots that show the=20 steady state behaviour as you suggested.

In the me= antime, we have added the following plots to our wiki:

=
1. Number of packet drops per time interval


<= /div>
2. A file showing the timestamp of each drop

=

I believe our advisor might have a= lready communicated with you and Jonathan for the timings of the videoconfe= rence.

Thanks and Regards,
Shefali Gupta=
Jendaipou Palmei

On Sun, Dec 16, 2018 at 1:40 AM Dave Taht <dave.taht@gmail.com> wrote:
Thank you for doi= ng 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 construc= t a paper out of this that could be published at=C2=A0
usenix or = acm next year. It's getting towards the holidays but would y'all (a= nd 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 She= fali Gupta <shefaligups11@gmail.com> wrote:
Hello Jonathan,

Thanks for your feedback.

As suggested, we have p= roduced CoDel and PIE graphs with small NIC buffer and uploaded the corresp= onding graphs.


We have also uploaded one way end-to-end delay=C2=A0graphs in Light= traffic scenario for CoDel, COBALT and PIE.


<= div dir=3D"ltr">On Mon, Dec 10, 2018 at 8:45 PM Jonathan Morton <chromatix99@gmail.com> wrote:
&g= t; On 10 Dec, 2018, at 2:30 pm, Jendaipou Palmei <jendaipoupalmei@gmail.com> = wrote:
>
> As suggested, we changed the NIC buffer size to 1 packet for the simul= ation 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 k= eep the NIC buffer size small.

Yes, that's what I'd expect to see from Reno-type congestion contro= l, and is one good reason why alternatives to Reno were developed (eg. Comp= ound, CUBIC, BBR).=C2=A0 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 realis= tic deployment.

If you were to add TCP (or parallel UDP/ICMP) RTT measurements, you'd s= ee that the peak latency was correspondingly improved by removing the dumb = FIFO hidden within the NIC.=C2=A0 I estimate that a 100-packet buffer accou= nts for about 120ms of latency at 10Mbps, which should definitely be visibl= e 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 t= hat you haven't already produced graphs of that sort.=C2=A0 They would = have identified this problem much earlier.

At present you only have COBALT graphs with the small NIC buffer.=C2=A0 For= a fair comparison, Codel and PIE graphs should be (re-)produced with the s= ame conditions.=C2=A0 The older graphs made with the large NIC buffer are p= otentially misleading, especially with respect to throughput.

=C2=A0- 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=C3=A4htCTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
--00000000000028458c057d85d7dc--