From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 8C3B23CB39 for ; Sun, 10 Jan 2021 02:19:18 -0500 (EST) Received: by mail-lf1-x12c.google.com with SMTP id o13so33390510lfr.3 for ; Sat, 09 Jan 2021 23:19:18 -0800 (PST) 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=4UpMDP600dpOJlRkY908pK1etWvgadzPC7wYZ9Au2aE=; b=TYzy7UGEFDqLlZVU2kFaxuXibahNqXyfS9dctLW6obRtF1Tu9glL6QCssSp9OMFhMI SI093zCJzYE1OX4OF5zdqsNxgQqBzMjpc5a+KWH+aTZP3WgVB/ZOAUIB+N+dbRs6g350 l3JWQhieFABZq40HBQ8AzlwvzuK/1L0zTS4YWZVkZpB7XNBHodz1bAOUtQ+DkXxlZHYt kAkHhsqLw6IyqXJbazrjd97C7KUyxkcuDEaMxY67vUYyS4fLSTwtjfMmWc4NwJjx7ItA 3mH4rSnoqOLoxBWRuL7STrI3tDOQeB6PNl5KQu4fD0XtyxnyMPeHPdK6J5NJXVwPwx03 EYDA== 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=4UpMDP600dpOJlRkY908pK1etWvgadzPC7wYZ9Au2aE=; b=TwM594MqY0W8mwjzvhLK2+16+FvqKnVFB4Jzekyo4gYz8iTHh7r1yX2gR+5F/60JTO ZX5+AhjASP3B7jadvS6h++64VTRYLhKpjhR3gJDF+JigEvpzk7357l/qdpLNv2hYqEIk mot0GCjga0+q+QvzkOqZNc03pUabKPml6ZDjgjvvDMMTKHBndR9Wf6UY1rmwm9VJK6MB W25t/nGc2IpLD2k8LuT7yQ480Pp8FVsGCy3fI5QoHQ8p7uupBAZISb7sOnwK8uH+7Jkv 6CqYEilQshwzHNUAXwpfUdnVu/BZdicePpHiy6gMjayCa2F43Xvt86YXkJvV9gLyV/Ap /DNg== X-Gm-Message-State: AOAM532PA9zNwl8iaXwdeDRXR2dAL11Nnw08f2ygUAkBAqYjsK49frn1 2L2n8gJLwasSDzRUA3wqJ20ninF+/SM= X-Google-Smtp-Source: ABdhPJwrijg3FMr+cbKYxSKpvf6aIsOntg00PmXq6iKH9yAtoeSswLmuEBIsHIcWC5vwePkaxIm49w== X-Received: by 2002:a19:650:: with SMTP id 77mr5231932lfg.160.1610263157383; Sat, 09 Jan 2021 23:19:17 -0800 (PST) Received: from jonathartonsmbp.lan (178-55-231-236.bb.dnainternet.fi. [178.55.231.236]) by smtp.gmail.com with ESMTPSA id 192sm2628222lfa.219.2021.01.09.23.19.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Jan 2021 23:19:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Jonathan Morton In-Reply-To: <20210110053919.GA14073@unix-ag.uni-kl.de> Date: Sun, 10 Jan 2021 09:19:15 +0200 Cc: bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <20210110053919.GA14073@unix-ag.uni-kl.de> To: Erik Auerswald X-Mailer: Apple Mail (2.3445.9.7) Subject: Re: [Bloat] Rebecca Drucker's talk sounds like it exposes an addressable bloat issue in Ciscos X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 07:19:18 -0000 > On 10 Jan, 2021, at 7:39 am, Erik Auerswald = wrote: >=20 > In my experience, asking about token-bucket algorithm details is often > a sign for the asker to not see the forest for the trees. IMHO, token-bucket is an obsolete algorithm that should not be used. = Like RED, it requires tuning parameters whose correct values are not = obvious to the typical end-user, nor even to automatic algorithms. = Codel replaces RED, and virtual-clock algorithms can similarly replace = token-bucket. Token-bucket is essentially a credit-mode algorithm. The notional = "bucket" is replenished at regular (frequent) intervals by an amount = proportional to the configured rate of delivery. Traffic may be = delivered as long as there is sufficient credit in the bucket to cover = it. This inherently leads to the delivery of traffic bursts at line = rate, rather than delivery rate, and the size of those bursts may be as = large as the bucket. Conversely, if the bucket is too small, then = scheduling and other quantum effects may conspire to reduce achievable = throughput. Since the bucket size must be chosen, manually, in advance, = it is almost always wrong (and usually much too large). Many token-bucket implementations further complicate this by having two = nested token-buckets. A larger bucket is replenished at exactly the = configured rate from an infinite source, while a smaller bucket is = replenished at some higher rate from the larger bucket. This reduces = the incidence of line-rate bursts and accommodates Reno-like sawtooth = behaviour, but as noted, has the potential to seriously confuse BBR if = the buckets are too large. BBRv2 may handle it better if you add ECN = and AQM, as the latter will help to correct bad estimations of = throughput capacity resulting from the buckets initially being drained. The virtual-clock algorithm I implemented in Cake is essentially a = deficit-mode algorithm. During any continuous period of traffic = delivery, defined as finding a packet in the queue when one is scheduled = to deliver, the time of delivering the next packet is updated after = every packet is delivered, by calculating the serialisation time of that = packet and adding it to the previous delivery schedule. As long as that = time is in the past, the next packet may be delivered immediately. When = it goes into the future, the time to wait before delivering the next = packet is precisely known. Hence bursts occur only due to quantum = effects and are automatically of the minimum size necessary to maintain = throughput, without any configuration (explicit or otherwise). Since the scenario here involves an OpenWRT device, you should be able = to install Cake on it, if it isn't there already. Please give it a try = and let us know if it improves matters. - Jonathan Morton=