From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 EB0593CB40 for ; Sat, 15 Dec 2018 14:06:16 -0500 (EST) Received: by mail-yw1-xc2a.google.com with SMTP id v20so2291237ywc.0 for ; Sat, 15 Dec 2018 11:06:16 -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=db+KtrDDeYgpTllQarGvbkC7HlqQ0eJmY8Wb3AZGABw=; b=GOuqV12IgZHExw9RqY7c/XCTeGLVxgDN/k9ObVG8g1IXR+5I2oVJ9DaRXZZiEs4n/4 uwsFUqGTJcoUEuQusWPABabyUZvq+K5BRPzVcxNMLz3zUaNtH4y6kd69ql0n3Xu/k1cj g8aq35BMZa89U8/4xQ8kFfZL/xwpwtw+FqJnUU/TA1OMwUS5C28GFN7ZbL8jJv7yj4FH M4Yyusuq9RmmsmfCUQ9xCJLZZTlCyzryko8BTrLyrBB4LKiwYj1NPt56tBIvFDX0rC6/ QkVlH3fmES9u6A2QKNXzpJqghG/UnVMrz5XDEInGKr5xJ9fghOppSBMCKj7qRV2N0nWf ozCQ== 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=db+KtrDDeYgpTllQarGvbkC7HlqQ0eJmY8Wb3AZGABw=; b=thmoAZhtnww0Wx3dLq2c/8ezPSlCyUlqP54mB4/nThJXCHEBpnsQhZ4OgElC66n9Ci pNwpFRHJ2Rpc7CR+n7zMhLRqqRmllGzK63PxbOvrR1Qg7wuS0cP+m35FE9CfKqXbs3dO BtjxconVqJcwzdTXji311gjtAkVX8OfLjI3s/LuivMGRgaS7m9sier2U6vpfMAWHx4gl AeGJiri2mHwT7zpYP68jCP9GAUlmfM/T2uHlrUtH5eosvfpZh7uK25P6HaYJ9HbHIl/0 C0rWRXdMuVRD3rtmNBOIAKMVCGSjKu7gYigUTX7klH71LYDiz24WzIeptAdotqxRECEC qYHg== X-Gm-Message-State: AA+aEWZO4BEXCNjdvTP1RLDz2mhDvYmojmrttTdmjwB9VoOzh82vqshS sFBWOqzLljQtLWHw0GSwlenuc+p5KK1wfBZSS1g= X-Google-Smtp-Source: AFSGD/WGpO/Yyu7dvYEGjVCRK5vEsNR64KxCXnVlNi8C7NF3oG6dP4VETM/UtygGjM95sqbJtu7SdacF56WFsbm4j1g= X-Received: by 2002:a81:8284:: with SMTP id s126mr6165266ywf.23.1544900776395; Sat, 15 Dec 2018 11:06:16 -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: <4487BE09-D5D9-4F54-B652-409E50CB4BF4@gmail.com> From: Shefali Gupta Date: Sun, 16 Dec 2018 00:36:04 +0530 Message-ID: To: Jonathan Morton Cc: Jendaipou Palmei , cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000fd8984057d143d13" 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 19:06:17 -0000 --000000000000fd8984057d143d13 Content-Type: text/plain; charset="UTF-8" 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 > --000000000000fd8984057d143d13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jonathan,

Thanks for your feedbac= k.

As suggested, we have produced CoDel and PIE gr= aphs with small NIC buffer and uploaded the corresponding graphs.


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

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

Regards,
Shefali Gupta
Jen= daipou Palme

On Mon, Dec 10, 2018 at 8:45 PM Jonathan Morton <chromatix99@gmail.com> 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 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
--000000000000fd8984057d143d13--