From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 6B3243B29E for ; Sun, 9 Dec 2018 03:38:25 -0500 (EST) Received: by mail-wm1-x334.google.com with SMTP id y185so4310264wmd.1 for ; Sun, 09 Dec 2018 00:38:25 -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=3Cg3AgC408jU8xdXuEE43afK36bVx9XXGrSfgL54els=; b=t+RNEzHpWni/3po5fPmCoqHatL6Q//q8QRv6jWVN6yuQZWcCtWRwOFAsGTHdU3uSX+ GaSqLUMUcNkdEPki7AaNP+LDd6/3gWcRE+8PReKXI8i51O++RcjwqIPa4G0iXUTTicGR bV0ko2DKsGUf8WeE8AS4nHCdeY+zm2bVhFeabdI0EGPHx6W49vTsMIGQvEka7c3AYOiR 9d3QUOmOVzj+31Vgy6jw5Dw7Ygte44zBOA5Uf3knqth8tzawFfHX2H7Tr2n9vTBklFSK EtscFJxNMqO6Nuh+GjWG7ZFMdq6AiQouLTdXheWTVjbOh+FD6hzyda+/Vyqfm36UZhn1 TXQQ== 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=3Cg3AgC408jU8xdXuEE43afK36bVx9XXGrSfgL54els=; b=E5U3qEBTTUzbiQimqU0GaJePB8Xk4xuYU7Xz5VWZ40/35vXLdEcR/DPFQEa9lrwwjR pQASfQFS+xr5N2WpHqSN8KAHuOuYcdmC22EPhL9qkL2sw37C15zRRe8quEJXh8yWwwcB XzZ6ec0SYctSgpGvSSr9IRHye7PahDVgAs+Xt2VDpVi/m395iBiGWE2EofH1ickX+S4J eA5Bm8AAx8f/2VjFJX+dljrHgeEQGmsoL29801rnb8QCobkAqUtAv7BnFW2wH+QZpRMm Rg7dVCURJG/Yi0DfNj46miYznrI7fB/nBDlWm7jZi0L6uFV8MYD0hWqQMwpVbEK+j/9e 0Q/g== X-Gm-Message-State: AA+aEWbt1qXnHZN0N11bg6MJl7gKlTDQUbGKEpSVEZj/A6Wcs1paECIe NDwJIyYxDLo1eiCop9UwmJaDfH+ZdLleOpgiRDo= X-Google-Smtp-Source: AFSGD/UvivqQ+h2n7msjAZR+hIh84BRavmt6qHEIz3R84+I61cu7LoxUYl9BU8aIrCnHwSg2m5mal/f0Y9mNU0XT3bc= X-Received: by 2002:a1c:4e08:: with SMTP id g8mr6783572wmh.46.1544344704226; Sun, 09 Dec 2018 00:38:24 -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> In-Reply-To: <70BDD881-B509-43FE-81BB-E9C4B1145FA1@gmail.com> From: Jendaipou Palmei Date: Sun, 9 Dec 2018 14:07:45 +0530 Message-ID: To: chromatix99@gmail.com Cc: Dave Taht , dave@taht.net, cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000819cea057c92c544" 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: Sun, 09 Dec 2018 08:38:25 -0000 --000000000000819cea057c92c544 Content-Type: text/plain; charset="UTF-8" Hi Jonathan, Yes, we are using TCP NewReno at the moment. There was a typo in labeling the Y-axis; instead of "Throughput" it should be "Link Utilization" in the following graphs (now corrected): https://github.com/Daipu/COBALT/wiki/Light-Traffic throughput graphs for the same scenario are here: https://github.com/Daipu/COBALT/wiki/Instantaneous-throughput:-Light-Traffic and cwnd graphs here: https://github.com/Daipu/COBALT/wiki/cwnd-plots:-Light-traffic So, now what we see is that although queue occupancy is under control and link remains fully utilized, the senders cwnd gets synchronized in one scenario (only when packet size is 1000 bytes and with COBALT). For all other cases, there is no synchronization of cwnd (including COBALT with packet size 1500 bytes). 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. The tasks that we're currently working on are listed here: https://github.com/Daipu/COBALT/issues/1 Thanks a lot for your help. We really appreciate it. Regards, Jendaipou Palmei Shefali Gupta On Thu, Dec 6, 2018 at 11:06 PM Jonathan Morton wrote: > >> We're currently working on the following: > >> > >> 1. plots for the actual number of marks/drops per time interval for > COBALT, CoDel, and PIE. > >> 2. zoomed in plots on small time intervals to show the dynamic behavior > of the algorithm. > >> 3. a file showing the timestamp of each drop. > > > > I await these with interest. > > I noticed that some progress has been made here already, in particular I > can now see cwnd graphs which make a very interesting datapoint when > directly compared with the throughput and queue-occupancy graphs. It's now > definitely clear that the senders are using TCP Reno or some close variant > thereof. > > In fact, the three graphs are mutually inconsistent. Aside from the sharp > cwnd reduction events, the cwnd of all the flows increases roughly linearly > over time, but the throughput remains flat while the queue is almost always > empty (for Codel and COBALT). This can only be explained if there's a > hidden queue at the bottleneck, perhaps associated with the simulated NIC > immediately downstream of the AQM. > > I would suggest checking the simulation setup carefully for hidden queues > of this sort. > > - Jonathan Morton > > --000000000000819cea057c92c544 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

Yes, we are usin= g TCP NewReno at the moment.

There was a typ= o in labeling the Y-axis; instead of "Throughput" it should be &q= uot;Link Utilization" in the following graphs (now corrected):



https://gi= thub.com/Daipu/COBALT/wiki/Instantaneous-throughput:-Light-Traffic
<= /div>

and cwnd graphs here:


So, now what we see is that although qu= eue occupancy is under control and link remains fully utilized, the senders= cwnd gets synchronized in one scenario (only when packet size is 1000 byte= s and with COBALT). For all other cases, there is no synchronization of cwn= d (including COBALT with packet size 1500 bytes).

= By hidden queues, do you mean the NIC buffers? ns-3 has a Linux-like traffi= c control wherein the packets dequeued by a queue discipline are enqueued i= nto NIC buffer.

The tasks that we're currently= working on are listed here:


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

Regards,
Jendaipou = Palmei
Shefali Gupta

On Thu, Dec 6, 2018 at 11:06 PM Jonathan Morton <chromatix99@gmail.com> wrote:=
>> We'= ;re currently working on the following:
>>
>> 1. plots for the actual number of marks/drops per time interval fo= r COBALT, CoDel, and PIE.
>> 2. zoomed in plots on small time intervals to show the dynamic beh= avior of the algorithm.
>> 3. a file showing the timestamp of each drop.
>
> I await these with interest.

I noticed that some progress has been made here already, in particular I ca= n now see cwnd graphs which make a very interesting datapoint when directly= compared with the throughput and queue-occupancy graphs.=C2=A0 It's no= w definitely clear that the senders are using TCP Reno or some close varian= t thereof.

In fact, the three graphs are mutually inconsistent.=C2=A0 Aside from the s= harp cwnd reduction events, the cwnd of all the flows increases roughly lin= early over time, but the throughput remains flat while the queue is almost = always empty (for Codel and COBALT).=C2=A0 This can only be explained if th= ere's a hidden queue at the bottleneck, perhaps associated with the sim= ulated NIC immediately downstream of the AQM.

I would suggest checking the simulation setup carefully for hidden queues o= f this sort.

=C2=A0- Jonathan Morton

--000000000000819cea057c92c544--