From: Jendaipou Palmei <jendaipoupalmei@gmail.com>
To: chromatix99@gmail.com
Cc: Dave Taht <dave.taht@gmail.com>,
dave@taht.net, cake@lists.bufferbloat.net
Subject: Re: [Cake] COBALT implementation in ns-3 with results under different traffic scenarios
Date: Sun, 9 Dec 2018 14:07:45 +0530 [thread overview]
Message-ID: <CAFLFmiWsHxbVH-_6x6mxZf6yhR=0W3Ojc3iVPD2saPZhBgOMvw@mail.gmail.com> (raw)
In-Reply-To: <70BDD881-B509-43FE-81BB-E9C4B1145FA1@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2418 bytes --]
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 <chromatix99@gmail.com>
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
>
>
[-- Attachment #2: Type: text/html, Size: 3574 bytes --]
next prev parent reply other threads:[~2018-12-09 8:38 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-22 13:57 Jendaipou Palmei
2018-11-22 15:32 ` Dave Taht
2018-11-23 10:52 ` Jendaipou Palmei
2018-11-23 16:05 ` Dave Taht
2018-11-23 16:43 ` Dave Taht
2018-11-23 17:13 ` Jonathan Morton
2018-11-24 2:59 ` Jonathan Morton
2018-11-25 6:22 ` Jendaipou Palmei
2018-11-27 14:10 ` Jendaipou Palmei
2018-11-27 14:36 ` Jonathan Morton
2018-11-30 11:53 ` Jendaipou Palmei
2018-11-30 11:58 ` Jonathan Morton
2018-12-04 10:31 ` Jendaipou Palmei
2018-12-04 14:39 ` Dave Taht
2018-12-04 15:02 ` Jonathan Morton
2018-12-04 15:20 ` Dave Taht
2018-12-05 12:23 ` Jendaipou Palmei
2018-12-05 14:23 ` Jonathan Morton
2018-12-06 17:36 ` Jonathan Morton
2018-12-09 8:37 ` Jendaipou Palmei [this message]
2018-12-09 13:21 ` Jonathan Morton
2018-12-10 12:30 ` Jendaipou Palmei
2018-12-10 15:15 ` Jonathan Morton
2018-12-15 19:06 ` Shefali Gupta
2018-12-15 20:10 ` Dave Taht
2018-12-21 10:37 ` Shefali Gupta
2018-12-21 12:48 ` Jonathan Morton
2019-01-21 11:35 ` Shefali Gupta
2019-01-21 12:57 ` Jonathan Morton
2019-01-23 16:19 ` Shefali Gupta
2019-01-23 16:23 ` Jonathan Morton
2019-01-23 17:27 ` Shefali Gupta
2019-01-25 8:35 ` Shefali Gupta
2019-01-25 9:16 ` Jonathan Morton
2019-01-25 14:48 ` Shefali Gupta
2019-01-25 15:07 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFLFmiWsHxbVH-_6x6mxZf6yhR=0W3Ojc3iVPD2saPZhBgOMvw@mail.gmail.com' \
--to=jendaipoupalmei@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@gmail.com \
--cc=dave.taht@gmail.com \
--cc=dave@taht.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox