From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (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 C0D8921F299; Thu, 21 May 2015 08:26:23 -0700 (PDT) Received: by vnbf7 with SMTP id f7so6171707vnb.13; Thu, 21 May 2015 08:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zX13schQx4w3/ECkr1k+OrqJapvc9+hXW//ze5OB8p4=; b=Wsg3JCYX3f8OHYGf41QDo8rnKQfb1ofpDihc2MCfOZOfVc4avnlY8O+c1wHX4daoHy A8z80Ttr7sHldWxAUEoWgbwjz5NJuknlLyaCReHIr4rAZJ8k0zeQsKGlCza5Wn1MvSnk gdVbAWTt1XQATtAV0FrComju88XnXneVQVz6gbimymuNE6v9lajtDpmD+j6gD6rmzqZK ud7hnN+XLsoOy+CyXD02L51pOueCuaQLMcoixGa+iiDmAbzJs1r+5AeAIko1x44QW/Td hefPvqeTuGkHh4R4FnRrN/b3/UJsvRqmtZzCs6sNEONs1Nm9WL69i74WZtwSIsVI568L DHjw== MIME-Version: 1.0 X-Received: by 10.52.5.2 with SMTP id o2mr2607562vdo.97.1432221971252; Thu, 21 May 2015 08:26:11 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Thu, 21 May 2015 08:26:11 -0700 (PDT) Received: by 10.52.12.167 with HTTP; Thu, 21 May 2015 08:26:11 -0700 (PDT) In-Reply-To: <555DF4C9.7050207@pollere.com> References: <3BDE8792-3B33-4DD6-B662-C18B2CECD183@gmail.com> <555DF4C9.7050207@pollere.com> Date: Thu, 21 May 2015 18:26:11 +0300 Message-ID: From: Jonathan Morton To: Kathleen Nichols Content-Type: multipart/alternative; boundary=20cf302ef588d61e070516992999 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 15:27:23 -0000 --20cf302ef588d61e070516992999 Content-Type: text/plain; charset=UTF-8 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 --20cf302ef588d61e070516992999 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

When Codel is applied on the upstream side of a link, a burs= t 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 t= hat detection until it is certain that it's a standing queue and not si= mply a burst.

When applied on the downstream side of a link, however, it t= akes 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 5= ms queue, during which the receiver is acking data without any clue that co= ngestion is in place. At 95%, it requires at least 95ms. The delay in detec= tion 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 com= parable to egress. I'm proposing using a reduced interval parameter to = do that. A drawback is that the response will be stronger than designed, an= d this may have an impact on throughput, but the same is true (and more def= initely so) of a policer.

On the one hand, this might lead to an interim solution whil= e Bobbie gets fleshed out. On the other, it should provide more information= on whether Bobbie is likely to work.

- Jonathan Morton

--20cf302ef588d61e070516992999--