From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (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 742773B260; Fri, 20 May 2016 10:36:50 -0400 (EDT) Received: by mail-lf0-x242.google.com with SMTP id m64so1310245lfd.1; Fri, 20 May 2016 07:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oUEV4fuFyjz39jAQMm7nYK+CDL5zk2/rjYLrRkT3cPc=; b=bI0YgcyEQENe/NkBKtZgqHMkxgROgmJTjU7ZS6Xz2iKtq5dfGVAd1UUZ/qz4RgkSk0 GP8WDuRVht2cCvwRjv0fxAHAIkakMG3rmhR24rlPhvy41j5vvRC8R3b/UWo185XbPvuD xdu8YRd0BxkSHfjVLhXK1MGj2OcOM5E/9Z+YkkOhe8fx9R9HtqMe9xlY4rh4GcJ3Z0LX Uyucp05AukO2JCa9zTiz4cvyKW+m0FeSRNsw/KXG5OLCsurZ+3ufnul1khYT83XubEVC f6j1Q7sO4xcblkmHa0KNJ07Fw2ikLfmjPxRqoXWvEnsySJry/UuKO2LdrSFy+DWPMB6T OGQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oUEV4fuFyjz39jAQMm7nYK+CDL5zk2/rjYLrRkT3cPc=; b=iFk6qu5+0jEr7eT3SYgdPBVLYzOIqf/Q6W2VuVz/CAr9CFuLpjyQI+sCyM/kypSJpr TEFFXqfsBDYhjr/voleT/V2zTNQy2oGcsEH8zk5alAk09q7eE1QiN4twqJjfboWqF2vw xE5H8FtmgzsDuQM2hpXrj9cJoghh5TWVZVw+i+/1H5O1BBAO4QRutXOBuZ10SV/7c1T0 TAD2+uWpVGNnMyuLBp97yHk/fmMFbQTlgLVEn5cvGGI/4tlgSW1otnGtWFbtBrTcvJkM Ibfb71eQx09h8rkkOW2pNl6TgPgjkQesFDTu2hTxABgQ4gYsG5ReXFJRVcPqrtRJS2tx Blhw== X-Gm-Message-State: AOPr4FU8HR2OYSrg2jYua8LpDwzWq7uZEbvzwTsayoxKtOTtMNK2MTrZ9gDl0E+yJ9pqPw== X-Received: by 10.25.141.131 with SMTP id p125mr1311525lfd.8.1463755009212; Fri, 20 May 2016 07:36:49 -0700 (PDT) Received: from bass.home.chromatix.fi (188-67-138-144.bb.dnainternet.fi. [188.67.138.144]) by smtp.gmail.com with ESMTPSA id di11sm1827029lbb.36.2016.05.20.07.36.48 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 20 May 2016 07:36:48 -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: Fri, 20 May 2016 17:36:46 +0300 Cc: cake@lists.bufferbloat.net, codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <857AEE56-E7DB-4981-B32E-82473F877139@gmail.com> References: <22371476-B45C-4E81-93C0-D39A67639EA0@gmx.de> To: moeller0 X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Proposing COBALT 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: Fri, 20 May 2016 14:36:50 -0000 >> If the relative load from the flow decreases, BLUE=E2=80=99s action = will begin to leave the subqueue empty when serviced, causing BLUE=E2=80=99= s drop probability to fall off gradually, potentially until it reaches = zero. At this point the subqueue is naturally reset and will react = normally to subsequent traffic using it. >=20 > But if we reach a queue length of codel=E2=80=99s target (for some = small amount of time), would that not be the best point in time to hand = back to codel? Otherwise we push the queue to zero only to have codel = come in and let it grow back to target (well approximately). No, because at that moment we can only assume that it is the heavy = pressure of BLUE that is keeping the queue under control. Again, this = is an aspect of Codel=E2=80=99s behaviour which should not be duplicated = in its alternate, because it depends on assumptions which have been = demonstrated not to hold. BLUE doesn=E2=80=99t even start backing off until it sees the queue = empty, so for the simple and common case of an isochronous flow (or a = steady flood limited by some upstream capacity), BLUE will rapidly = increase its drop rate until the queue stops being continuously full. = In all likelihood the queue will now slowly and steadily drain until it = is empty. But the load is still there, so if BLUE stopped dropping = entirely at that point, the queue would almost instantly be full again = and it would have to ramp up from scratch. Instead, BLUE backs off slightly and waits to see if the queue *remains* = empty during its timeout. If so, it backs off some more. As long as = the queue is still serviced while BLUE=E2=80=99s drop probability is = nonzero, it will back down all the way to zero *if* the traffic has = really gone away or become responsive enough for Codel to deal with. Hence BLUE will hand control back to Codel only when it is sure its = extra effort is not required. - Jonathan Morton