From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 B48623CB40 for ; Sat, 15 Dec 2018 15:10:57 -0500 (EST) Received: by mail-qk1-x72b.google.com with SMTP id g125so5046112qke.4 for ; Sat, 15 Dec 2018 12:10:57 -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=ySFKvsFrBSsb1GZqeuEDA2dsAyB+UXQORyjepGGGRXs=; b=VMIqWP5OjGMe/hXhUSyIprVyn9K1B4cNpdAD/lohJIYFkPQ9n7ItgrS3teQwGzr1Ir R37pCbwLM6bIK0xqnzADn9nKy5utzc1oEBukxxVzAMDF+RRW7u9GPGMpaJno48rhLSDf YJmrf7VhqSMITwUdK4GD//BQlOsYVbybTKkD/hFvav70rtkrrd9d6+8Lp6sc+68kPXfV YapyiB1hdReh1Q1CP/0YPjpwuzLSROUDALo1Hn6gW4Aa3QFnaMYryqsFdR14Q0sx2bls oqF/FRzvMGiLSNkVfqOIihXwZGhwLtsgq6nJHb1noqviL5INOqkm/VM5lwQYm9e9AlBY D/LQ== 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=ySFKvsFrBSsb1GZqeuEDA2dsAyB+UXQORyjepGGGRXs=; b=FPMBQU1Aeir5w0R63bxau0akqI8cXEQcF5yJG1gUuAlsPegT9PccRODIl7AggH2Zaz nXcWCux8rZRyLcQqXIy2chkKmVj7O0h82DSG32hGRluYNrIQ4hq2+XRxeJs7SJZaHzkG RQBMya2nmL7iMIJ6eMCIp20fsmjonE5D6Q0GiyRTMARfJRc9bu/FLfLAMyPZR7mQ1WXW K/ZdNjDqYTyE6h/yvmZNXadANiDz0wG51CWWxoD3qEf3lnCfc/DGgsuaQ+mkM373jZpI DX4LWU2DaWe9VBTDbrOhqL1b9InPV/fzd5ad4eI5U8UI+FXgrhxgrk98WYe3HBdDI7v6 cMVg== X-Gm-Message-State: AA+aEWbZ0uwUM3yVlb4Zf7F9N7p24aPFvYRF3mlqGCCycfnou0KIWlxN NNJsPjaRuGhLbwm7ZwogwFjZbcF5k9EgQ5GBFCw= X-Google-Smtp-Source: AFSGD/XGssU2tx2Tm3GvbL5fwilcPoTr3aupYJb2hglYiBGyMvz1d2PBjlPMwdGz7NfPKi/gKJKFB/Xb+HcuP6LJ10Y= X-Received: by 2002:ae9:ee02:: with SMTP id i2mr7124814qkg.179.1544904657107; Sat, 15 Dec 2018 12:10: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: Dave Taht Date: Sat, 15 Dec 2018 12:10:44 -0800 Message-ID: To: Shefali Gupta Cc: Jonathan Morton , Cake List Content-Type: multipart/alternative; boundary="0000000000004c80c9057d152570" 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: Sat, 15 Dec 2018 20:10:57 -0000 --0000000000004c80c9057d152570 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-Differe= nt-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, an= d >> is one good reason why alternatives to Reno were developed (eg. Compound= , >> CUBIC, BBR). You may wish to explore what happens with Compound and CUB= IC, >> 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 se= e >> that the peak latency was correspondingly improved by removing the dumb >> FIFO hidden within the NIC. I estimate that a 100-packet buffer account= s >> 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 s= ame >> 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 > --=20 Dave T=C3=A4ht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 --0000000000004c80c9057d152570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 wo= uld be good. So showing T-0 -> T-3 and T-3 forward would let you use dif= ferent scales for each.

I'd kind of like to ta= ke a step back and try to construct a paper out of this that could be publi= shed at=C2=A0
usenix or acm next year. It's getting towards t= he holidays but would y'all (and your advisor(s)) be available to meet = via videoconference sometime next week? I'm in california, jonathon - s= omewhere in europe - so that might be hard.




On= Sat, Dec 15, 2018 at 11:06 AM Shefali Gupta <shefaligups11@gmail.com> wrote:
Hello Jonathan,
Thanks for your feedback.

As sugg= ested, we have produced CoDel and PIE graphs with small NIC buffer and uplo= aded the corresponding graphs.

<= div>
We have also uploaded one way end-to-end delay= =C2=A0graphs in Light traf= fic scenario for CoDel, COBALT and PIE.

Thanks a lot for your help. = We really appreciate it.

Regards,
Shefali Gupta
Jendaip= ou Palme

O= n Mon, Dec 10, 2018 at 8:45 PM Jonathan Morton <chromatix99@gmail.com> wrote:
=
> On 10 Dec, 201= 8, 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=A4ht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
--0000000000004c80c9057d152570--