From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 83CF53CB42 for ; Sun, 25 Nov 2018 01:22:56 -0500 (EST) Received: by mail-wm1-x32d.google.com with SMTP id y1so11843272wmi.3 for ; Sat, 24 Nov 2018 22:22:56 -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=A/QOw+wvZLHHf0ayGXCDVNQV5GSAY4CoMFRijYOVJ0s=; b=pq3/V53NNZ4S1Vd3pIOycbYhQFyOxuhS0l7ZjvdwNAl8ggj44e1f2fSwRZCG+LZN9u 7xTalKHCpmYmGjc7Zvss5q2dc2m4YWI7zguuVLHcuLoIx//orLRSwPeiZndI5VD7GrlN nBMliugdxhdxfwDDcgDsVNII1IA4jJnYAzVI+3blREoOT5ZRLuZe8bSdFD0aOu8sW9af EPPe5qvVUmgVbk99hNB4Z12gnt/qrsHUp22R1nMZZd1IyrLZ3y9oxn+WuUpbDhwF+6EM tU6lmzGwPahZ6+KpelK2jL6vsyUUhVTLv+XQzy9wm3Du3VDWeQETGP0P2xalA3Bj3BbJ E/Cg== 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=A/QOw+wvZLHHf0ayGXCDVNQV5GSAY4CoMFRijYOVJ0s=; b=aMqSmj+7FRlBhAqjR7BuHdsSKt6JaUbPXrOmqdqZLGG6S0qCLkEvVi0NJYhaEuUiaW BgkklvtsFzDJFjTZXnQuCJNoOA3FY0T/mNyfKpszlisDmpoI/ky5AmgtEjfiRJ7Lk16G INIcVO6hktiEUqyoBc8GWfZ2aGQJZ5fZ8tX7tJvk2a28ygWkjE10OrLyF46r/hWNhoT1 1oAqQgs0KW7BBOYX/os7JX2DP8Q6VQNUF2/ZLboT/iGQXutxD2lL0JRAkt5eKB2gLXeo JGLzOLtneSTPnwiIZ12EAZ4fVqMPrsfcacUwH23Td6qBsIRyQUHaEzdYNm8SBGQjxbrJ m11w== X-Gm-Message-State: AA+aEWYZ7mxaDGjMZCYZOZKglsKIhmAIePHGL35PWJ5/5vuogsW7vM62 JH+yBm1bvnYMvl6P95UfF0Ll3cZqwWzmhA8/v60= X-Google-Smtp-Source: AJdET5fel7ZE0Lzlui+B42KcfQwHgNBU9XgE/SvYsWf3NzR85inP8FMdfQwdOq7r5UyzbX9+trii+XbWgv45viwCaq8= X-Received: by 2002:a1c:63c2:: with SMTP id x185-v6mr17712529wmb.27.1543126974916; Sat, 24 Nov 2018 22:22:54 -0800 (PST) MIME-Version: 1.0 References: <87va4nzsn4.fsf@taht.net> <6578A0D1-FF6A-474E-A6D5-98185F98CB45@gmail.com> In-Reply-To: <6578A0D1-FF6A-474E-A6D5-98185F98CB45@gmail.com> From: Jendaipou Palmei Date: Sun, 25 Nov 2018 11:52:16 +0530 Message-ID: To: chromatix99@gmail.com Cc: Dave Taht , dave@taht.net, cake@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000002ef1ff057b773f75" 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, 25 Nov 2018 06:22:56 -0000 --0000000000002ef1ff057b773f75 Content-Type: text/plain; charset="UTF-8" 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 --0000000000002ef1ff057b773f75 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for taking out time to review our code, Jonat= han.

We'll make the changes according to your sugges= tions and produce new plots.

Thanks, Dave for the = feedback. Yes, we will run the simulations with fq-codel once we fix the co= de as suggested by Jonathan, and also run simulations with higher bandwidth= s as you suggested.

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

Regards,
Jendaipou Palmei
Shefali Gup= ta

On Sat,= Nov 24, 2018 at 8:29 AM Jonathan Morton <chromatix99@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



--
Yo= urs Faithfully,
Jendaipou Palmei
--0000000000002ef1ff057b773f75--