From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by huchra.bufferbloat.net (Postfix) with ESMTP id B7F9421F293; Thu, 21 May 2015 09:31:47 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id DDE222005E80C; Thu, 21 May 2015 09:31:44 -0700 (PDT) Received: from kmnimac.local (c-50-156-111-45.hsd1.ca.comcast.net [50.156.111.45]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id 93B852005E808; Thu, 21 May 2015 09:31:43 -0700 (PDT) Message-ID: <555E086E.30605@pollere.com> Date: Thu, 21 May 2015 09:31:42 -0700 From: Kathleen Nichols User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jonathan Morton References: <3BDE8792-3B33-4DD6-B662-C18B2CECD183@gmail.com> <555DF4C9.7050207@pollere.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: cake@lists.bufferbloat.net, Justin Beech , bloat Subject: Re: [Bloat] [Cake] dslreports and inbound rate shaping X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 16:32:31 -0000 It sounds like you are defining congestion as packets experiencing 5ms of delay over a period of 5ms. When you evaluate this, what metrics do you use to evaluate the effect on the applications using this buffer? Kathie On 5/21/15 8:26 AM, Jonathan Morton wrote: > When Codel is applied on the upstream side of a link, a burst arrives in > it almost instantly, and thus it only takes 5ms to detect that 5ms of > queue has developed. The interval parameter then delays action on that > detection until it is certain that it's a standing queue and not simply > a burst. > > When applied on the downstream side of a link, however, it takes longer > for a burst to filter through to where Codel can see it. If the shaper > is set to 90% of the link rate, it takes at least 45ms to build a 5ms > queue, during which the receiver is acking data without any clue that > congestion is in place. At 95%, it requires at least 95ms. The delay in > detection might be even longer under some circumstances. > > This means Codel has to be more aggressive at responding to a detected > 5ms queue on ingress in order to provide control of the flow comparable > to egress. I'm proposing using a reduced interval parameter to do that. > A drawback is that the response will be stronger than designed, and this > may have an impact on throughput, but the same is true (and more > definitely so) of a policer. > > On the one hand, this might lead to an interim solution while Bobbie > gets fleshed out. On the other, it should provide more information on > whether Bobbie is likely to work. > > - Jonathan Morton >