From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 9E2A33B2A4 for ; Wed, 29 Mar 2017 13:42:47 -0400 (EDT) Received: by mail-lf0-x234.google.com with SMTP id x137so13792938lff.3 for ; Wed, 29 Mar 2017 10:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oIeREEA9gg4xWuSqt/AIG241rmkqG/Ep5pUZ1ACK+Bs=; b=YSafDhTyIVKzdUKb4DLjY+DKHBDE+31JgIxsyhbUUvudbcIDRbf0sxqgvmXLexEdQM 2NLtFEOqbpwM3oSWeIETtdp2OgzIxcuLHDOlK5VnCP8/50LSqyltrpD8SlFvxrGj6CRM tdpJDbHiCXZgiKhuItCYwegMvuR/ZVET4lrC0DLNDbXJov3eL4ZSzVOPrJbDECmD0JgN gKwf0VpJ28F2qwrAQWADY8iSsMzG87zvBjwY4LrO0owhgDJyOItAnMop2seAFUi/1Se2 lgPTXANdV3HEGErYOeYkL+HDAafH3dbrCJVo4QRTNGJ8MhfhPNM+pIaqhJlaix1r7VU6 My5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oIeREEA9gg4xWuSqt/AIG241rmkqG/Ep5pUZ1ACK+Bs=; b=pvV3WG6hBugVjBzk/Zl8LwG4oiaac9VQsBGyYWN+4Ff/d7uh2wq2GoEa6LbSynYAdA 8jbJaOC2O/uZz1x8mYRJS4yMdYeKq2SujDW4ICdWs9ridjekQJR6NZ2AI8X3cixljYUz QLLk1CJc32QK4ZCz1z1rNdRR73gd4m1je5TGaupt1GoMPgmHXCpX0cv0ZdS0zV5IURcU y16T9S1/fylOFvluRqUOAUjHLb0Sai7M0RWuBmXN3KMwlnksoLa2JhkF4Dl/P1LxD+4j fyGOQmV4parFWBj6dPcyZT6W1L0eAeWu465IQ+DJrWmNn+vlB+RoKR2tYIL6BfZyQEFY fgFw== X-Gm-Message-State: AFeK/H0kbsVzZo9ggMr4jFuQYzibPp+8YhQMaeXkwDFfHZATvRsKkXbkMMgw27MG9BW2+Q== X-Received: by 10.25.40.21 with SMTP id o21mr482779lfo.45.1490809366331; Wed, 29 Mar 2017 10:42:46 -0700 (PDT) Received: from [192.168.100.14] (37-219-158-10.nat.bb.dnainternet.fi. [37.219.158.10]) by smtp.gmail.com with ESMTPSA id e91sm1442053lji.40.2017.03.29.10.42.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 29 Mar 2017 10:42:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Wed, 29 Mar 2017 20:42:43 +0300 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: vignesh kannan X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Doubt regarding the Linux implementation of Cake 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: Wed, 29 Mar 2017 17:42:48 -0000 > On 29 Mar, 2017, at 20:34, vignesh kannan = wrote: >=20 > I have also been following the discussions happening about Cobalt on = the Bufferbloat mailing list. So I am having problems relating the two = sources just mentioned above (the implementation and the discussion). = According to my understanding of the Codel algorithm, the count variable = (which keeps track of the number of packets dropped in the currently = running dropping state) is never really decremented iteratively. >=20 > However the Cobalt implementation reduces count iteratively (in line = 234 of the file cobalt.c) under certain circumstances and this is = happening in the function named cobalt_should_drop( ) which is called to = determine if Cobalt should drop the packet or dequeue it. It would be = great if someone could throw light on what is exactly happening in this = function and also a comprehensive explanation of Cobalt itself would be = appreciated.=20 An open question in Codel is exactly how best to choose the initial = value of =E2=80=9Ccount=E2=80=9D when re-entering the dropping state = after a relatively short period of not dropping. I was unsatisfied with the usual approaches, which in the reference = Codel implementation involve a rather opaque calculation, and in some = variants involve a halving of the previous count value, both with a hard = time cutoff before a full reset to 1. What I do in Cobalt is, while in non-dropping state, to decrement count = on the same schedule as it would increment in dropping state. This = completely eliminates the need for a hard time cutoff and seems like a = natural solution to the problem. I=E2=80=99m currently writing a series of articles for the Bufferbloat = website on the algorithms Cake uses, including their performance = relative to existing alternatives. - Jonathan Morton