From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 0D0923B29D for ; Tue, 21 Apr 2020 14:40:03 -0400 (EDT) Received: by mail-lf1-x135.google.com with SMTP id f8so11942640lfe.12 for ; Tue, 21 Apr 2020 11:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5D5OW90Zdos73Ns0UZYRqgbPWKzURR07M+c9osILWqo=; b=mhjfyYZPLFCaGpoaHnickPjVTiayKmrUevkGIx5aYymmoGj4VwUWOq9u+yuFt67hsz uxzk/KdBUStkAmuALCpxxNby23GHtYVL3boD8jJdYHchUb4kqcMefXYUrxQBxhKldYp7 sUwMTvimo4NGOkXlbYs2tHBChrJwKf50aUoXHJnCixi+2EVZASGbK5uLHG/fCFomOwgy QfWqDFjZeVz1oCBY7cbTvdt150VGayuFFBO47jddFMI3k1PTXFOG1AJV9Hi1MplRw/uN Y1xZJoMLmBdWARCMaCMdvl+usNygrGOvij0iIEWoTSsQ3L8Bf0SfG2GwuMfxKXMPh+un 4H1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5D5OW90Zdos73Ns0UZYRqgbPWKzURR07M+c9osILWqo=; b=BkDvcH9i2hxmVBv3f5ShoGiYFHeIdsgrefHt4sxiXgK8p2JLFXHWG8jA317XtV/UV3 tbkfBhW5wldVH60uEfAoMiACAOEg5vbthj3n0bKndXvvjoKpCfLWsDsaoohXneQ+njjO 00iS7waEqyXs8ZarR+/QSzHPLEwhQn92KN6fhK6FRqhYKRRQKaAfC3kj+glmTlZBTNMp VYeAO2vDDo6tVPyttiyuw7Z2T27EPK+9tUJP4qchf7m6CpOJuNYt6LxrCJZzM3BAmoC9 ue+UzoYPpXaxE0rqcs9+9Avfml9vSIbDsTOoDrmS+aD7mht1ph7ZRlT+Sm4FErJptPOS Aonw== X-Gm-Message-State: AGi0PublArwIbF+/Jkozg9Pgvhe16TKF4imbioeMkYgl0PfmKBGtjsiW ZNrlsAnM4DF3fXa4okj015F2aB+Y X-Google-Smtp-Source: APiQypJTOf8EjVApzyBB2b1V+dO+Rct914tpBPt44kx6uSmz5OGRKp21j+a4zm1plDwpj6aYPh3uqA== X-Received: by 2002:a19:700b:: with SMTP id h11mr14766699lfc.89.1587494402739; Tue, 21 Apr 2020 11:40:02 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-235-192-nat-p.elisa-mobile.fi. [83.245.235.192]) by smtp.gmail.com with ESMTPSA id b9sm2997428lfp.27.2020.04.21.11.40.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 11:40:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jonathan Morton In-Reply-To: Date: Tue, 21 Apr 2020 21:40:00 +0300 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <75FEC2D9-BFC8-4FA2-A972-D11A823C5528@gmail.com> References: To: Justin Kilpatrick X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] Advantages to tightly tuning latency 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: Tue, 21 Apr 2020 18:40:04 -0000 > On 21 Apr, 2020, at 9:22 pm, Justin Kilpatrick = wrote: >=20 > I have a frequently changing link I'm using automated tools to monitor = and tune using Cake. Currently I'm only tuning bandwidth parameter using = latency and packet loss data. >=20 > My reading of the codel RFC seems to say that trying to tune the = 'interval' value using known path and link latency won't provide any = advantages over just tuning the bandwidth parameter. >=20 > Obviously codel is just one part of the Cake setup and I'm wondering = if there are any advantages I'm missing by not providing this extra = input using data I already gather.=20 The default latency parameters are tuned well for general Internet = paths. The median path length on the public Internet is about 80ms, for = which the default interval of 100ms and target of 5ms works well. Codel = is also designed to accommodate a significant deviation from the = expected path length without too much difficulty. I think it's only worth trying to adjust this if your typical path is = substantially different from that norm. If all your traffic goes over a = satellite link, for example, the default parameters might be too tight. = If the vast majority of it goes to a local CDN, you could try the = "metro" keyword to tighten things up a bit. Otherwise, you'll be fine. Also, most protocols are actually not very sensitive to how tight the = AQM is set in the first place. Either they don't really care about = latency at all (eg. bulk downloads) or they are latency-sensitive but = also sparse (eg. DNS, NTP, VoIP). So they are more interested in being = isolated from the influence of other flows, which Cake does pretty well = regardless of the AQM settings. It's *considerably* more important to ensure that your shaper is = configured correctly. That means setting not only the bandwidth = parameter, but the overhead parameters as well. A bad shaper setting = could result in some or all of your traffic not seeing Cake as the = effective bottleneck, and thus not receiving its care. This can be an = orders-of-magnitude effect, depending on just how bloated the underlying = hardware is. - Jonathan Morton=