From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6610321F403; Sun, 14 Jun 2015 11:07:29 -0700 (PDT) Received: by lbbti3 with SMTP id ti3so4135405lbb.1; Sun, 14 Jun 2015 11:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TJHPqL/KBtfoJsGMd4DN+5u4D07qJYbUP4XXMflhKwE=; b=CJgB2aP73R4fJ1C60T4mC3xsWHidsCTzEQ+5sRXcQCjJAEOP7pfCGrTdW83VMqMdIP o0un/oN8kMOrJHNivR15z35jQo43zWoGdTynvIn/XrPpZiWKM37hDxUO8tqbxABj5g/w I4mtYy71KkUUVS+Vzvu+vkZDdxC9DKyjpV90Pb5B8fJB/6NH98LiOdlY1HNmCyeyhm0F zE+J1oRfz6mdw9Mxzu5ZZKZCxa1MCgn2e1kaeStiT75J8blfjGx6jiV2yknAii+tt1iC TF5Guq9lVu9xtCr04kKDR7ahnZZ2E20ydaw4H5lqimzm8j1hpgWa5Kc8GmOrNgGP5vgD 8n8g== X-Received: by 10.152.204.7 with SMTP id ku7mr23730085lac.38.1434305248038; Sun, 14 Jun 2015 11:07:28 -0700 (PDT) Received: from bass.home.chromatix.fi (87-93-133-238.bb.dnainternet.fi. [87.93.133.238]) by mx.google.com with ESMTPSA id p9sm2151358laf.11.2015.06.14.11.07.25 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jun 2015 11:07:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: Date: Sun, 14 Jun 2015 21:07:21 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0CFA8991-9F5E-4988-82ED-6CA0E4E08676@gmail.com> To: Dave Taht X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net, Alan Jenkins , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Codel] [Cake] openwrt build available with latest cake and fq_pie X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 18:07:59 -0000 > On 14 Jun, 2015, at 20:38, Dave Taht wrote: >=20 >> Every time Codel triggers the dropping state, it will mark or drop at = least one packet, and increment count by that number. With count = decremented only by 1 on recovery, it will effectively remain constant = *if*, by some miracle, the queue empties before the second signal was = sent; it cannot decrease between episodes unless it resets or wraps. >=20 > It aint a miracle, it is hopefully within an rtt. No, it is *at minimum* one RTT. It takes that long for the congestion = signal to reach the receiver, be reflected back to the sender, the = sender=E2=80=99s reaction to *begin to* appear at the queue. Then the = queue *starts* to empty, if the signal is what=E2=80=99s required to = make it do so. > When resuming the drop phase of codel, it is almost *already* too late > to catch that burst incurring the latency. Yes, but that=E2=80=99s what FQ is for. And ELR, if we ever get that = properly started. > Sometimes I think we need to do away with the count idea and measure > slopes of curves instead, and "harmonics=E2=80=9D. > Is there any reason why the decrease couldn't be some sort of decay? > I.e. a function of how long ago the drop state was exited? Such things are theoretically possible, but require further thought to = determine how best to do them. - Jonathan Morton