From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 07CAE3CB35 for ; Tue, 27 Nov 2018 09:10:55 -0500 (EST) Received: by mail-wr1-x432.google.com with SMTP id j2so22868138wrw.1 for ; Tue, 27 Nov 2018 06:10:54 -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=fLL1/AWB8oOBVCSONpeBS+LzNhwn/hRRyaDj2v8p2VY=; b=nqoQ9BMz9Wv8IZ3hxtDp6/taIfujSK8C0LIWn2Z6ZXz7on7uplWyKv2/mDfBrAoeIs UhtyV3LWvCz0eU0cTrYwdMCtIhg49CCGFnp3gGhGPwBgKbIp4N7i459Eon+if3lyFjMJ a4FDwC6G0j5K1ZPMw/p52J0WLBqS5BJQMNwliJNhOa+s5k3flUGwRLd5Rwa1tlp9XWGN kF3VBhIi9Z6g6u0xNeeLDYtxvzxGvFqHe65ltqJLGzl6vSssotW5Mytuvrg/YIZ3AC/T hVnYY4Y9IPr1Jh23CSiDvF2oIApKmgw9CPTktNtGixX8v9F+3LRe9vEF+i7ZbEfa+vAy NWeQ== 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=fLL1/AWB8oOBVCSONpeBS+LzNhwn/hRRyaDj2v8p2VY=; b=p0lUz8vVt0xDqy5oJ/uunlQr1DHkwPMjkTwK+903Cl9e9hIHibg1FaC8jsehV/Z/bX BjWzmvM/6qbGz9TkRqfsuTbUz5vabHgtt+DqrBzrn3ZiWobe7BgRX+zQ8K3awrZpm4Hi /o/LsERDY5MlHtKbl6fKtEIEf/HezUwxL0D50NsurNdMiR4YQnYD5gmg/JymimRxtlUF F5/rgTsYn+VfT22SPhe/9wPn8usQj+dR/mXbMntleY1y3OtbhxK1CxJtL2qoW5SbGuAb S8ZtGHlUf1Vm2+foCCJ4JHd0yyIslGWlsgJ0x6MP3j91QqJ0QDjmHuf/WifE4e71+PGH dMGQ== X-Gm-Message-State: AA+aEWakwJvguOYA2FI/zc7zJ1T28fr4JD6YgUREIVzoKusPKZZ/N5VG ryrcrgbjAmt8/Cj10NyMrIa7457lI4PnGH0IES4= X-Google-Smtp-Source: AFSGD/Wxg9l8Ar/UYQRlAY1Ddbz1mAnveJYyOnSQULkErcUTG2wrSpnwF4Iet+kEIBA2oOAjlhu7giVq0nRjrWDfbSc= X-Received: by 2002:a5d:4586:: with SMTP id p6mr26826467wrq.69.1543327853806; Tue, 27 Nov 2018 06:10:53 -0800 (PST) MIME-Version: 1.0 References: <87va4nzsn4.fsf@taht.net> <6578A0D1-FF6A-474E-A6D5-98185F98CB45@gmail.com> In-Reply-To: From: Jendaipou Palmei Date: Tue, 27 Nov 2018 19:40:16 +0530 Message-ID: To: chromatix99@gmail.com Cc: Dave Taht , dave@taht.net, cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000007f878c057ba604d0" 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: Tue, 27 Nov 2018 14:10:55 -0000 --0000000000007f878c057ba604d0 Content-Type: text/plain; charset="UTF-8" Hello Jonathan, We have made the changes in the code as suggested. Here is the diff after making the changes: https://github.com/Daipu/COBALT/commit/033db330287e2072bad94ac441f8aed774678a7d Additionally, we have also updated the values of 'Pincrement' and 'Pdecrement' (parameters of BLUE) in ns-3 to match the ones used in the Cake implementation in Linux. Does the diff look correct? Thanks and Regards, Jendaipou Palmei Shefali Gupta On Sun, Nov 25, 2018 at 11:52 AM Jendaipou Palmei wrote: > Thanks a lot for taking out time to review our code, Jonathan. > > We'll make the changes according to your suggestions and produce new plots. > > Thanks, Dave for the feedback. Yes, we will run the simulations with > fq-codel once we fix the code as suggested by Jonathan, and also run > simulations with higher bandwidths as you suggested. > > I'll upload the source code of the programs in the same repo, and give you > the link. > > Regards, > Jendaipou Palmei > Shefali Gupta > > On Sat, Nov 24, 2018 at 8:29 AM Jonathan Morton > wrote: > >> >> This is possibly a correct result in your simulation!! - the periodic >> >> throughput drop you are showing in cobalt at this bandwidth and rtt. >> >> I'm happy to see cobalt kick in early on slow start but not happy to >> >> see the periodic drop. Jon, do you have time for a code review? >> > >> > I looked at it briefly, but the code structure is different enough that >> I need to sit down and study it carefully to figure out whether there are >> any relevant differences. >> > >> > The throughput drops most likely occur because the TCPs become >> synchronised and remain so under AQM action. You can see that the >> frequency of the system is lower in the later part of the COBALT run than >> in the Codel run, but the same as Codel in the earlier part where >> throughput drops don't occur. But this shouldn't really occur with a >> Codel-based AQM (as COBALT is), because a single mark is sufficient to tell >> TCP to back off over one RTT. An explanation might be if this >> implementation of COBALT isn't running down correctly when deactivated, so >> the mark frequency only rises while being turned on and off. The run-down >> behaviour is a major intentional difference between COBALT and reference >> Codel. >> > >> > I'll look at the code more closely with that in mind. >> >> Okay, I've had a look - not quite line by line, but the parts I consider >> important for the behaviour seen so far. >> >> There are a couple of small behavioural differences between your code and >> mine, which should be corrected if the model is to accurately reflect the >> prototype. These are probably not relevant for the results shown so far, >> but are likely show up on more aggressive tests involving unresponsive >> traffic. >> >> - On queue overflow, a tail drop is used to resolve it. While not >> technically part of COBALT, Cake performs head-dropping on queue overflow, >> doing so from the longest queue, and I consider that to be best practice. >> This gets the message to the offending sender ASAP, without having to >> bubble up through the jammed queue first. If the packets currently at the >> head of the queue are smaller than the one being offered, you might need to >> drop more than one to maintain the size invariant. >> >> - The hard-drop flag for BLUE is set at the top of the control-law >> function, and tested in order to bypass the Codel logic if already set. >> This is not how the COBALT code operates; the BLUE logic should come last, >> and the Codel logic run unconditionally. >> >> Everything else looks reasonably correct at first glance (though the >> amount of boilerplate is epic). I would recommend verifying that >> CobaltQueueEmpty() actually gets called when appropriate though. Without >> it, I suspect that the run-down logic won't work as intended. >> >> - Jonathan Morton >> >> > > -- > Yours Faithfully, > Jendaipou Palmei > --0000000000007f878c057ba604d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jonathan,

=
We have made the changes in the code as suggested.

Here is the diff after making the changes:

<= a href=3D"https://github.com/Daipu/COBALT/commit/033db330287e2072bad94ac441= f8aed774678a7d">https://github.com/Daipu/COBALT/commit/033db330287e2072bad9= 4ac441f8aed774678a7d

Additionally, we have als= o updated the values of 'Pincrement' and 'Pdecrement' (para= meters of BLUE) in ns-3 to match the ones used in the Cake implementation i= n Linux.

Does the diff look correct?

Thanks and Regards,
Jendaipou Palmei
Sh= efali Gupta

On Sun, Nov 25, 2018 at 11:52 AM Jendaipou Palmei <jendaipoupalmei@gmail.com> wrote:
<= /div>
Thanks a lot for takin= g out time to review our code, Jonathan.

We'll make = the changes according to your suggestions and produce new plots.
=
Thanks, Dave for the feedback. Yes, we will run the simulati= ons with fq-codel once we fix the code as suggested by Jonathan, and also r= un simulations with higher bandwidths as you suggested.

I'll upload the source code of the programs in the same repo, and= give you the link.

Regards,
Jendaipou P= almei
Shefali Gupta

On Sat, Nov 24, 2018 at 8:29 AM Jonathan Morto= n <chromatix9= 9@gmail.com> wrote:
>>= This is possibly a correct result in your simulation!! - the periodic
>> throughput drop you are showing in cobalt at this bandwidth and rt= t.
>> I'm happy to see cobalt kick in early on slow start but not ha= ppy to
>> see the periodic drop. Jon, do you have time for a code review? >
> I looked at it briefly, but the code structure is different enough tha= t I need to sit down and study it carefully to figure out whether there are= any relevant differences.
>
> The throughput drops most likely occur because the TCPs become synchro= nised and remain so under AQM action.=C2=A0 You can see that the frequency = of the system is lower in the later part of the COBALT run than in the Code= l run, but the same as Codel in the earlier part where throughput drops don= 't occur.=C2=A0 But this shouldn't really occur with a Codel-based = AQM (as COBALT is), because a single mark is sufficient to tell TCP to back= off over one RTT.=C2=A0 An explanation might be if this implementation of = COBALT isn't running down correctly when deactivated, so the mark frequ= ency only rises while being turned on and off.=C2=A0 The run-down behaviour= is a major intentional difference between COBALT and reference Codel.
>
> I'll look at the code more closely with that in mind.

Okay, I've had a look - not quite line by line, but the parts I conside= r important for the behaviour seen so far.

There are a couple of small behavioural differences between your code and m= ine, which should be corrected if the model is to accurately reflect the pr= ototype.=C2=A0 These are probably not relevant for the results shown so far= , but are likely show up on more aggressive tests involving unresponsive tr= affic.

=C2=A0- On queue overflow, a tail drop is used to resolve it.=C2=A0 While n= ot technically part of COBALT, Cake performs head-dropping on queue overflo= w, doing so from the longest queue, and I consider that to be best practice= .=C2=A0 This gets the message to the offending sender ASAP, without having = to bubble up through the jammed queue first.=C2=A0 If the packets currently= at the head of the queue are smaller than the one being offered, you might= need to drop more than one to maintain the size invariant.

=C2=A0- The hard-drop flag for BLUE is set at the top of the control-law fu= nction, and tested in order to bypass the Codel logic if already set.=C2=A0= This is not how the COBALT code operates; the BLUE logic should come last,= and the Codel logic run unconditionally.

Everything else looks reasonably correct at first glance (though the amount= of boilerplate is epic).=C2=A0 I would recommend verifying that CobaltQueu= eEmpty() actually gets called when appropriate though.=C2=A0 Without it, I = suspect that the run-down logic won't work as intended.

=C2=A0- Jonathan Morton



--
Yours Faithfully,
Jendaipou Palmei
--0000000000007f878c057ba604d0--