From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 71B823B2A4 for ; Sat, 7 Sep 2019 19:09:53 -0400 (EDT) Received: by mail-lj1-x22c.google.com with SMTP id j16so9271143ljg.6 for ; Sat, 07 Sep 2019 16:09:53 -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=dW8PP4JrEpTxjEdQCkRn3oXxm2goz3vEXhaJdLu9QR4=; b=RnNxmzk1HqLnV85QLfwpcqaigWYeOt7aH46BqjLJWfsRyOq6T5geplF/kkHd5Jd+0V Y+DxqBxFkcdu1k4Yrij25NNTEO7Typ5Oe5/gC8CZkQM+1mYpTjaBjAsM4Ph+ErdHnCwe ctWuswLnJLRsRiYy3u03v3I56AYfwkqRrZPgXi6i05xKZ2+nOT78WQdpvDqPHDVEF+Oa K+ERu0lTKERosUljpjhRPVguD9mGiZMrJb/uNmBDv3IqJQ8DdOaTXHMRClSEfGaS4LNS +iZmdFlmIUb0X8bnKEQZ8UGWzGp1wqZAlknX/b+crGVbEpqlO7McfIhA59FKSjhLuTAj DmKw== 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=dW8PP4JrEpTxjEdQCkRn3oXxm2goz3vEXhaJdLu9QR4=; b=uNtKESkf48QcpOOSldEOKcLgoMWL1RDf7HOr2xTXoJHCNCv42SMCRi4kCIZOFzTEcf QXPGnEE08H2dy2nqyqJogv+1TXIqIJFi92QTPBPDvHCo3J+1ONw5nSHSijKSz4PBQynT lBaCchQbVXSqNFk4ZPwy1q313qknjUV11Haenomjsj4H3nirj4XCIjdMK58H7jabCZrN 8CJZ2hezn7tjc+kig+/LK7PZ5OYV95uOtu9cDE7au1d2/wRNx6zyH0ypPkr15fRDAPZ+ mmXV7sid0ymvu0MNNP27r7gQp3TxA2c+gOXueCpH7wynJQUoZRxLw2bUzG1VrA11AOfe slqQ== X-Gm-Message-State: APjAAAWl9/NnOSkpFr96xhiMjU4rJ6H0Kvw+YqX9YG+DEgQRNcpLPPhU +fQFAYBziU1MxLL9CsO2QDc= X-Google-Smtp-Source: APXvYqwL/MIAMty9dgFbuDfZ5//pjzcHJ8M22H4Phng9sNwgouaAN1UCb3MMmfEibBJHr8UjGYjfLg== X-Received: by 2002:a2e:9c99:: with SMTP id x25mr10471133lji.9.1567897792355; Sat, 07 Sep 2019 16:09:52 -0700 (PDT) Received: from jonathartonsmbp.lan (83-245-237-193-nat-p.elisa-mobile.fi. [83.245.237.193]) by smtp.gmail.com with ESMTPSA id t82sm1929591lff.58.2019.09.07.16.09.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Sep 2019 16:09:51 -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: Sun, 8 Sep 2019 02:09:50 +0300 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <2825CE14-2109-4580-A086-9701F4D3ADF0@gmail.com> References: To: Justin Kilpatrick X-Mailer: Apple Mail (2.3445.9.1) Subject: Re: [Cake] Fighting bloat in the face of uncertinty 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: Sat, 07 Sep 2019 23:09:53 -0000 > On 8 Sep, 2019, at 1:42 am, Justin Kilpatrick = wrote: >=20 > I'm using Cake on embedded OpenWRT devices. You probably saw this = video on the list a month or two ago.=20 >=20 > https://www.youtube.com/watch?v=3DG4EKbgShyLw I haven't actually watched that one yet... > Anyways up until now I've left cake totally untuned and had pretty = great results. But we've finally encountered a scenario where untuned = Cake allowed for unacceptable bufferbloat on a link. >=20 > Hand configuration in accordance with the best practices provided in = the RFC works out perfectly, but I need a set of settings I can ship = with any device with the expectation that it will be used and abused in = many non-standard situations. Producing non-optimal outcomes is fine, = producing dramatically degraded outcomes is unacceptable.=20 What was the scenario that gave you trouble? I note that Cake is not defined in an RFC. Were you referring to a = Codel RFC? Cake is a bit more sophisticated, with the aim of making it = easier to configure. > Which leads to a few questions >=20 > 1) What happens if the target is dramatically too low?=20 >=20 > Most of our links can expect latency between 1-10ms, but they may = occasionally go much longer than that. What are the consequences of = having a 100ms link configured with a target of 10ms? The default 'target' parameter is normally 5ms, which goes with a = default 'rtt' and 'interval' parameter of 100ms. You shouldn't normally need to set 'target' and 'interval' manually, = only 'rtt', and there are various keywords to assist with choosing an = appropriate 'rtt'. The default of 100ms is provided by the 'internet' = keyword, and this should be able to cope reasonably well with paths down = to 10ms. You could also try "regional" which gives you tuning for 30ms, = or "metro" which gives you 10ms, with good behaviour on paths within = about an order of magnitude of that. Remember, it's the path RTT that matters for this, not the link itself. Should the bandwidth setting correspond to a serialisation delay per = packet that approaches the 'target' implied by the above, 'target' will = automatically be tuned to avoid the nasty effects that might cause - = *unless* you manually override it. So don't do that. ECN enabled flows should not easily notice an 'rtt' setting that's too = small. RFC-3168 compliant transports only care about how many RTTs = contain at least one CE mark. Non-ECN flows may see elevated packet = loss, however, and thus more retransmissions, but the same congestion = control behaviour. Cake protects these flows from experiencing "tail = loss" which could lead to an RTO that the end-user would notice. > 2) If interval is dramatically unpredictable is it best to err on the = side of under or over estimating? >=20 > The user may select an VPN/exit server of their own choosing, the path = to it over the network may change or the exit may be much further away. = Both 10ms and 80ms would be sane choices of target depending on factors = that may change on the fly. Generally the default 'rtt' of 100ms is suitable for generic Internet = paths, including nearby 10ms hops and 500ms satellite-linked islands. = The default 5ms target actually puts a floor on the minimum effective = RTT that the marking schedule has to cope with. There's also a good = chance that the "hystart" algorithm in CUBIC will drop it out of = slow-start on very short-RTT paths before the AQM triggers. - Jonathan Morton