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 21BD53B29D for ; Sat, 7 Dec 2024 21:53:52 -0500 (EST) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-5401c52000fso75467e87.2 for ; Sat, 07 Dec 2024 18:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733626431; x=1734231231; darn=lists.bufferbloat.net; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=WxaWBfaXtg+qoIWc8Xq84e0I5rxx86DmOVu4DlU/USE=; b=HcqhTGNX1LGkTs6XbjTuVB/hh4ZD7yvYDGet2NoT16HrddoDU8rbVr+sDpH3eCP64a kPpVBbTXHgiTWfzm2edm3a4Eb07m8YkigfuQu3HIP/nwDXU1kqD4/YNyBti5N22PMi16 sEbmXc3/IPvQYUAIR0iJniQcwA6sJ2PWbpa66SuZlNZ5DGp12g8Fs+oPIIaLZF0oJhZu CkqBQHhLR9jHP18B9atD3QhkWIWER1FiauT2ALqkrK/uA9/eaw4Ji/ibZDl60JGsqwUJ NEOekUi0b5tGxsqK3bD0q/kTyzgPS/SY5NqY+Fe7pQqnydlrNpm921gU0WjcAQ97V7DG mbjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733626431; x=1734231231; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WxaWBfaXtg+qoIWc8Xq84e0I5rxx86DmOVu4DlU/USE=; b=updGkWKu4oO9UthUUhMCxREMLx/epBle8Btfd6zP+rDF0YzDYKGox3bDlrn4Qm//QM 74wQx5Cx9tgMlIvctBuUpJH2zOgRCYvP8TUrBs6vQuyBg6DTmhVBY7zz3hdxe27e/2Z7 XCJy69lDqOQpM5v/hYIyvI0IwFBAGgHO9jktD1BpQ7UUFMPeu6T2uUdVSh2hQ9vtw6h8 QG43d5ieR8CNie/jNuotd+kQNU8UdX1qyDN9UMe1P0kLSdfN45UqQCWZHBRVUfGkmjE3 5JGkw7b1ZlyFyFHNPuj8tx2KMBRP9vk0J+2dFHvqjjXCDgu2+Dt9Ha4lhgmXvApAzuSU 4cww== X-Gm-Message-State: AOJu0YxR8UgAH/h61I2MyhmaKaK/TWEmbq1G2lRjFOwGVQ8zD1ADi91s 43Ge+/+4TCf7PD0Xn2Z3AqWYva43P0FWhdw0WnMeS0VEq9vk3Ep6 X-Gm-Gg: ASbGncv7vU7koa6M53bztmV8xL74mzmODbntUuWR3hAOTShnJ2NUqKQ/7HKksNWHORR H+VSA8CroqN8gMvtiiV5Tlw2hl4ipxnOL+9OSxx8ExKnXjk8xz3KfS2ht71C7/kP8A1JzVz78/v abpfggzP9pFl5oQirahjbO6/p1GJ8EhiysuwO4dtsRK8OebJuuC5j6f3aYgQ5OoYYTqnsUXy+k+ e1dhVoDujxK0F7kitctfbOGFn7QgcURJTuHPjxU2QqcW8GbfCz+Zk74J0hKgaVyHQPLLYqQ6G5N yK2jPZbGinTkxRkk0NuRGQSa4tFd X-Google-Smtp-Source: AGHT+IEpk2HlgbaBjQrEP3MKk0Pfr8HTbl04kpka9zGyO8AWX8OhS8IPQlO5qxvbEyCN9jRn1J12aQ== X-Received: by 2002:a05:6512:3d28:b0:53e:27d2:ad92 with SMTP id 2adb3069b0e04-53e2c30cce7mr2791949e87.55.1733626430415; Sat, 07 Dec 2024 18:53:50 -0800 (PST) Received: from smtpclient.apple (188-67-132-152.bb.dnainternet.fi. [188.67.132.152]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-53e229ba886sm966932e87.166.2024.12.07.18.53.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 07 Dec 2024 18:53:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Jonathan Morton In-Reply-To: Date: Sun, 8 Dec 2024 04:53:46 +0200 Cc: codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Evan Mesterhazy X-Mailer: Apple Mail (2.3654.100.0.2.22) Subject: Re: [Codel] Do codel or fq-codel need to know the link bandwidth? X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Dec 2024 02:53:52 -0000 > On 7 Dec, 2024, at 11:27 pm, Evan Mesterhazy = wrote: >=20 > However, I have noticed that the commercial implementations for at = least two firewalls that I have used (OPNsense and a Unifi gateway) both = require the user to input the upload and download bandwidths of the = link. That's because they combine three algorithms into a coherent package. = All three algorithms do something different which is a crucial part of = the whole. FQ_Codel is a combination of two of these algorithms: the Codel AQM = (which signals to traffic when it's passing through a congested link) = and the DRR++ Fair Queuing algorithm, which essentially isolates = different flows from interfering with each other. The third algorithm is called a "shaper". It moves the bottleneck out = of the link hardware itself (which isn't smart enough to run FQ_Codel) = and into the CPU (which is). It is the shaper that needs to know what = bandwidth to use, because it can't directly sense the link = characteristics from where it is. - Jonathan Morton=