From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (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 20D7D21F2D9; Sun, 14 Jun 2015 10:19:23 -0700 (PDT) Received: by lbbtu8 with SMTP id tu8so41262369lbb.2; Sun, 14 Jun 2015 10:19:21 -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=BrIL0t5lUzQ7hhXm5wQlv/CbZZfcODpN/JSW9vD29lc=; b=Z3cm9+RCAD4ZGCogMg3qrjRLs22j5Gc4PG0bdakeUB34pHmJDh2T2BCvMxwsfEWA6w EQRIkFnOVyC8MDq550ArNYg7jlfIHsEgK6APhA0PcmCbgfGiS1jnaxXBn4mA/3FKao9t K0E/Z3VRzENGtyiK3fMyI6698mk+OWsB2TZwNZdBHFwy8afMPZkebUo0Ta/peoIqVHwH ThPAKRfOduAN4eKkCwVCid6mUxElSdqfmDvlLKw8ctLsAGpXQok5mbiVWtqAmfEPbeSa GnQc90XqJ1rMevIRf09yp0QFhAfEUB+vzFYBuIyVayTjkcraZHdNATgdHV3o0Ltdb7pj Ft3g== X-Received: by 10.152.197.2 with SMTP id iq2mr23775633lac.103.1434302361444; Sun, 14 Jun 2015 10:19:21 -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 j2sm961217lbs.24.2015.06.14.10.19.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Jun 2015 10:19:20 -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 20:19:15 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0CFA8991-9F5E-4988-82ED-6CA0E4E08676@gmail.com> References: To: Dave Taht X-Mailer: Apple Mail (2.2098) Cc: cake@lists.bufferbloat.net, Alan Jenkins , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] [Cake] openwrt build available with latest cake and fq_pie X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 17:19:52 -0000 > On 14 Jun, 2015, at 19:09, Dave Taht wrote: >=20 > I do pretty strongly think count - 1 is the rightest thing still. I really don=E2=80=99t. Here=E2=80=99s why: 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. With count decremented by 2 on recovery, it is possible for count to = decrease slowly in that ideal case, but it=E2=80=99ll remain constant if = two signals were sent before the queue cleared, and - this is important = - it will always continue to increase if three or more signals are sent = before the queue empties. If one signal did suffice to clear the queue, then logically the value = of count was irrelevant to that congestion episode and shouldn=E2=80=99t = be preserved. This is true regardless of the actual reason the queue = emptied. The problem arises when more than one signal is sent before the queue is = observed to clear. This could be a sign of several distinct network = conditions: - The RTT is longer than interval / sqrt(count), in which case one = signal would still have been sufficient, and the ideal value of count is = less than its current value. On non-ECN TCP flows, this results in more = retransmissions than necessary. - The RTT is much shorter than interval / sqrt(count), so the congestion = window is recovering faster than the signalling rate, and count needs to = increase to compensate for that. - There is more than one flow sharing the queue, and it was necessary to = signal to all of them, in which case count should reflect the flow count = and be capable of adjusting both up and down. - The flow is unresponsive, so count should adjust to provide the = correct dropping rate, and RTT is irrelevant. With default parameters, = the maximum drop rate is presently 25600 pps (which would cause count to = wrap after a few seconds, until I put in the saturating arithmetic). How does Codel distinguish between those cases? It can=E2=80=99t - at = least, not reliably. So it must allow count to increase until the queue = is observed to be controlled, and then decrease count by some other = means to cover the case where it was overestimated. For this latter = phase, count-2 is obviously insufficient to cope with the case where = count is actually correct, but more than one signal per episode is = required. *That* is why I put in count/2. A multiplicative decrease allows count = to stabilise at some value which adequately controls the queue, rather = than continuously increasing past it. For the typical cake case where = there is one flow per Codel instance and the RTT is of Internet scale, = this should work at least as well as an additive decrease; in = particular, the behaviour is identical where count ended at 2, 3 or 4 = (it can=E2=80=99t end at 1). Of course, hard data would help to evaluate it, but I do think it=E2=80=99= s theoretically sound. - Jonathan Morton