From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 946223B2A4 for ; Mon, 10 Dec 2018 07:31:24 -0500 (EST) Received: by mail-wm1-x333.google.com with SMTP id a62so3315772wmh.4 for ; Mon, 10 Dec 2018 04:31:24 -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=OTcgI7SDG3HJtsseonxM0pxbmwtRLcaoGz6Yc9SihHw=; b=HIgJSR1uOjcW7gwU3YVCGO8xaFqmilVnWdb0fVmH2tccxSfz7KkDUMuLsdRIvecwyb PdR16lAm/LkHINd4zzHm5oruWcK8tB8YpylNd1Oy7oLwRHtNKYwuVTzLuFPI8wdt2CIb 86JKN6b/kv6Z4bRv40+T+MY60FsImUS2ndBS1SiXbwU69eVJ83IhzD8vbJNYVDDoqGPI 6qtcg9HSJVGADw1QCWLye1/40kr1LCpOuL48wHOCUfAEg9ZAcEV/xdhpZWcN0y/cMwu9 NtpoB1089I/r9XQUQU6SwpdUhjQIxDPe2tyAfDgEY3fw2/9gOpAKO/BUsuyv6r3YWxSz tZJA== 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=OTcgI7SDG3HJtsseonxM0pxbmwtRLcaoGz6Yc9SihHw=; b=afJf7NkgdAMxl4/qaf5wmb6InCZkDjNfe1DphENIWeOKGPIW5tvbDkAtdf5VW1sWhB 7hsGzl6uVfT3g753fpyPSuuuf/7aCbbPoz2eWEJexqYvmc4Fx/XVRsOyMgJ2O71/1QWm XoBeF5MQUpEtTuqeOyuMgePXuUJBNLa328xdedKVO+PiOgiQTba3iv7eNGnawltbt92L ACCUIAfug/fZRrmW3bgY7uadZRxXsOFIvh8tSov0saoP04vxKK+trlfFsfq74hjuDUvG PhXMAiiRSilDeRa5iq2WkWt/VJ30nkgN7QUuqFvErIl0KEOz7M/O6yAdUqQknQG5eoAS hN3g== X-Gm-Message-State: AA+aEWaQM0/bkvNkuyFH/kFYtDMTZVxvq3KGxLXvLsptUA43eofC7EpK Ci7XjpyC1xZmyNZnrS8Nv/wv0/9ijuKjdY//0c8= X-Google-Smtp-Source: AFSGD/W0vBssHJPasJkQXRJcZ335CvYWmMfgl04GwroB8kBuiiw2hteVGxhcN/Z2QJOEYw6yvz7tOeUctsO91rCn2Ek= X-Received: by 2002:a1c:3c06:: with SMTP id j6mr9542417wma.27.1544445083402; Mon, 10 Dec 2018 04:31:23 -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> In-Reply-To: <8467184E-7C35-4AFE-9CC6-292215022FDB@gmail.com> From: Jendaipou Palmei Date: Mon, 10 Dec 2018 18:00:45 +0530 Message-ID: To: chromatix99@gmail.com Cc: Dave Taht , dave@taht.net, cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000924804057caa240d" 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: Mon, 10 Dec 2018 12:31:24 -0000 --000000000000924804057caa240d Content-Type: text/plain; charset="UTF-8" Hello Jonathan, Thanks for your feedback. 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. The results are put up on the following link: https://github.com/Daipu/COBALT/wiki/Link-Utilization-Graphs-with-Different-NetDeviceQueue-size Thanks and Regards, Jendaipou Palmei Shefali Gupta On Sun, Dec 9, 2018 at 6:51 PM Jonathan Morton wrote: > > On 9 Dec, 2018, at 10:37 am, Jendaipou Palmei > wrote: > > > > By hidden queues, do you mean the NIC buffers? ns-3 has a Linux-like > traffic control wherein the packets dequeued by a queue discipline are > enqueued into NIC buffer. > > That's right. Linux now uses BQL, which (given compatible NIC drivers) > limits the number of packets in the NIC buffers to a very small value - > much smaller than is evident from your data. If you were to measure the > end-to-end RTT of each, I'm certain you would see this effect dominating > the mere 50ms latency you're trying to model. > > Ideally, AQM would applied to the hardware queue anyway. For simulation > purposes, I recommend reducing the NIC buffer on the bottleneck interface > to 1 packet, so that the simulated AQM's effects are easiest to measure. > > - Jonathan Morton > > --000000000000924804057caa240d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jonathan,

Thanks for your feedbac= k.

As suggested, we changed the NIC buffer size to 1 packet for the=20 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 affec= ted when we keep the NIC buffer size small.

The re= sults are put up on the following link:


Thanks and Regards,
Jendaipou Palmei
Sh= efali Gupta

= On Sun, Dec 9, 2018 at 6:51 PM Jonathan Morton <chromatix99@gmail.com> wrote:
> On 9 Dec, 2018, at 10:37 am, Jen= daipou Palmei <jendaipoupalmei@gmail.com> wrote:
>
> By hidden queues, do you mean the NIC buffers? ns-3 has a Linux-like t= raffic control wherein the packets dequeued by a queue discipline are enque= ued into NIC buffer.

That's right.=C2=A0 Linux now uses BQL, which (given compatible NIC dri= vers) limits the number of packets in the NIC buffers to a very small value= - much smaller than is evident from your data.=C2=A0 If you were to measur= e the end-to-end RTT of each, I'm certain you would see this effect dom= inating the mere 50ms latency you're trying to model.

Ideally, AQM would applied to the hardware queue anyway.=C2=A0 For simulati= on purposes, I recommend reducing the NIC buffer on the bottleneck interfac= e to 1 packet, so that the simulated AQM's effects are easiest to measu= re.

=C2=A0- Jonathan Morton

--000000000000924804057caa240d--