From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 9D6D83B4A6 for ; Thu, 14 Apr 2016 04:45:54 -0400 (EDT) Received: by mail-lf0-x22a.google.com with SMTP id e190so100683691lfe.0 for ; Thu, 14 Apr 2016 01:45:54 -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=+thnawpQlte6EV/6z/qrvICzU3MQ8+aF0/Y2ga/zzm4=; b=bRl77mPrwYZR9I3vGH8NFgD61jlGKJ2ASuf9EUA9ZltSJffEiASKpCiSWj7iy3NNCa 8tqSSjKgIsK4H7fM2KMR4HpwRor2JmsbdOK85VY4m38zylACnm8RGfgrpkIpITAQtl7n QWRZ5AhKZ6l4s9IeEb5277EeA1jO0ExHFrNdHbWjjrULErxGBZ2n5SK6TXbf9T50xumg WE0hgszjErPh8233TuxAYpsXAHUSCLJOI7FD8wl7MnKZVhqgVKgcoMy4cj3XQW+locr4 FR2/6oW47BjrwPAjRr4fkvSiupQuvIl/QQdYO3ZuGEto/Ef4H2zTfyFU5SrxZ1NPnvZd Vlcw== 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=+thnawpQlte6EV/6z/qrvICzU3MQ8+aF0/Y2ga/zzm4=; b=dzmp4B6at0sfq3L60EM4AyYiDrcMvxpfs9FrvyP4Yf4m93zb6mtxjat9mIlfZTVRd8 YRYr7hZHyUxYBJO7gIxBAOdM+dAuURw63MpflFdJCSnLek17X8CAgymxzvU5YHUHcMNp RaoB5Y3DVcB+9P5bGqJtlqNNfWji4lFyhS2CeomFdonS8oPffcqdenis3M7AwD+31sjE g5rCSwtNRLhAJywrnOgzYVQkz7gBCrkuXcDPTzU/Eh2Y+vCHRToaoujKTZZ6mFn+QVP4 ntfxLq3I9OrGgrRAtkjpAmI0BmLql4lex3deGU7v6zvng0v/f9MiwrUmM+ZytCbjqydc xXdQ== X-Gm-Message-State: AOPr4FU//o9mP68GCUYTQPqAfCmnimcujiisTBRBPvIWhmXIE8VmfY/gur+cj88ijTWTiw== X-Received: by 10.25.145.149 with SMTP id t143mr6054354lfd.37.1460623553438; Thu, 14 Apr 2016 01:45:53 -0700 (PDT) Received: from bass.home.chromatix.fi (37-33-67-252.bb.dnainternet.fi. [37.33.67.252]) by smtp.gmail.com with ESMTPSA id a134sm6780195lfb.1.2016.04.14.01.45.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Apr 2016 01:45:52 -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: Thu, 14 Apr 2016 11:45:50 +0300 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Taht X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] pleased to see some patches land for cake 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: Thu, 14 Apr 2016 08:45:54 -0000 > On 13 Apr, 2016, at 23:15, Dave Taht wrote: >=20 > ... so I filed some bugs. It should build on normal kernels now, as well as net-next. I took = advantage of the fact that the bug was filed against kernel 4.5.0, = whereas net-next is on 4.6.0. The flow counters now rest at zero when a tin is idle. Previously they = didn=E2=80=99t (since a queue is only retired when it is serviced while = empty, and an empty tin never got that far), which was = counter-intuitive. I also made some small changes which should improve efficiency with = Diffserv handling on. These mostly revolve around increasing the quanta = of the Diffserv DRR carousel. The downside is that the Diffserv = prioritisation won=E2=80=99t be quite as smooth, since it runs a single = tin until the deficit is exhausted (or that tin is empty), which is the = efficient way to do it. Kevin noticed a small typo in the diffserv-llt setup code which was = causing the instability I mentioned. So that now works too. I could add a diffserv3 mode quite easily at this point. I looked at = the Cisco stuff, though, and immediately got a headache. I don=E2=80=99t = think there=E2=80=99s a clean way to map that to Cake, and I don=E2=80=99t= think we should try, either. One of the LLT codepoints (Lo) is identical to the legacy =E2=80=9CMax = Reliability=E2=80=9D TOS code. The other (La) would be interpreted as a = bizarre combination of the =E2=80=9CMax Reliability=E2=80=9D and =E2=80=9C= Min Delay=E2=80=9D codes by legacy equipment, but is a valid combination = under the original rules, which only forbid setting all three TOS bits = at once. I=E2=80=99m a bit surprised they didn=E2=80=99t simply reuse = the existing =E2=80=9CMin Delay=E2=80=9D legacy code, which has the = right intended meaning. I mapped =E2=80=9CLa=E2=80=9D, =E2=80=9CMin = Delay=E2=80=9D, =E2=80=9CEF=E2=80=9D and =E2=80=9CVA=E2=80=9D to the = =E2=80=9CLow Delay=E2=80=9D tin. However, the other Diffserv modes in Cake don=E2=80=99t provide the = specified LLT behaviour in any way. The =E2=80=9Clow latency=E2=80=9D = tin(s) have a different priority (higher or lower, depending on its = utilisation rate) to the best-effort/high-reliability tin(s), and often = end up with *higher* values for the Codel parameters, due to their low = threshold rates. The best policy is therefore to leave =E2=80=9CLa=E2=80=9D= traffic in the best-effort tin, where it at least benefits from = flow-isolation from best-effort traffic. Meanwhile, I=E2=80=99m about to embark on a deep spelunking mission into = one or more classful qdiscs=E2=80=99 code, to see whether I can write = something to make Allan Pinto=E2=80=99s use-case (which sounds generally = applicable for building-scale networks) work cleanly. This would also = be a good time to finally get around to writing a DSCP-remarking qdisc, = so I might end up combining the two jobs into one. - Jonathan Morton