From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 9EBFC3B29D for ; Sat, 7 Dec 2024 16:27:38 -0500 (EST) Received: by mail-pj1-x1032.google.com with SMTP id 98e67ed59e1d1-2ef6ee55225so316594a91.0 for ; Sat, 07 Dec 2024 13:27:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733606857; x=1734211657; darn=lists.bufferbloat.net; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=XBl+TkYc2CC9gPFcWqRyj3bDfLQnGRhzPPwJqDUuRNM=; b=Fdj6/cVUCwecM27MSAh2DFrbvbnu7qgobu7NKySU6swASrFCqm7EpAwrCq+s/OOMNX cVaedh7a0kEQMOoEf8d7ZkqOqw6Fn6eAKsRDWR2j+ZWsVw7HqnrMd0CuA9wsgvQMHyHE mqIn2bBC0Qj8YWyclMr4tTrtzWKGjm12sVdpD+G7gGKBqe8PSf9jBwGlywnNiv0Dz6qH jXkSZ/oqwPjKV+hRNtWchUgZZIqWK/LOt2zs79V748Hl6LPVxGfDpZ/Pixg4VTwls73Q 33Bpgc09+sn1UfHuF/ye/MWoxKUrwTUHFjqS+bAJ99rwYGw99G5aaQWChL43cryMk/1t oOWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733606857; x=1734211657; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=XBl+TkYc2CC9gPFcWqRyj3bDfLQnGRhzPPwJqDUuRNM=; b=wT1nGMjTp+VCSY/PRuIQDLFJFz16Vs3hYSf6Q8oPRj74B+danMtDwgctQSvLmUvQU0 vpfhLkPZk2FWlbUDinoQyXhM1IEtw6dNp6PQMj7qo6KhzYuoByeU93sSW9OzL65V7rqK skWUmH5MeB9a9lNT+WE0m2zgqZ5J9Yy7GITN4+jNVfd4VowBGBLObTgOU21zTOMIvqZ6 aKfV6AxygHFRHWwEqUkPMiW/U49XJnj0As4SvdEjgYWI1ET9s0WzzvlVrSBMmxP1/WpW FuyIwcuJQmLbPpeacfyEtbvtxpF2E1jDnZR6sRtB0R4VeN9FGFlDF9EiHNl5XensMRmj CzMQ== X-Gm-Message-State: AOJu0YwNBVskMUCC9JDNDb3Vvb3o2qmcbTlgnKkU0op9HBzBj/d3HYgN iSd8sWrxNONYnTUsqqiPpx8VrKdP5H/IQJKqpNsInYLKWK4lw7VVLoRbQAZsqAAr9TZiNiUcf5r PIToNRdQ0bO3Q/3DyBxc+i3udGQJXtQ5h X-Gm-Gg: ASbGncuKDgXiblfkOMGvGIeWgNJXZkTcwjkehG4ffoLK8MvvjrDPjt052KVoYteGkeY YJxMSv6BhwX24iJEhcLCHaACUu8rRL0N5g9rD8aJmie5L63hZEKQLy7YeT6WKeKprmQ== X-Google-Smtp-Source: AGHT+IHDV4eUPu2H/jFyff6mPr3+s6pf3DprSgwyqx/dxfmeWtkwankU8X+Z+7LrkZUCyeq84jml4Z8YrfDkvILUmHw= X-Received: by 2002:a17:90b:1e05:b0:2ee:6d73:7ae6 with SMTP id 98e67ed59e1d1-2ef6ab28880mr4276855a91.7.1733606857173; Sat, 07 Dec 2024 13:27:37 -0800 (PST) MIME-Version: 1.0 From: Evan Mesterhazy Date: Sat, 7 Dec 2024 16:27:26 -0500 Message-ID: To: codel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000e6f6470628b4cc68" Subject: [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: Sat, 07 Dec 2024 21:27:38 -0000 --000000000000e6f6470628b4cc68 Content-Type: text/plain; charset="UTF-8" As far as I can tell, the fq-codel algorithm ( https://www.rfc-editor.org/rfc/rfc8290.html) doesn't use link bandwidth as a parameter. From reading the description, it seems like it should be able to work without knowing the link bandwidth since it decides to drop packets based on the amount of time they have waited in a queue. In fact, the original codel rfc (https://www.rfc-editor.org/rfc/rfc8289#section-4.1) even says that it's designed to be non-starving and work over variable bandwidth links. 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. In OPNsense I tried setting the bandwidth to a large number above the actual link bandwidth and then manually setting the fq-codel parameters to their Linux defaults, but that resulted in poor performance. My concern, of course, is that I'm leaving throughput on the table by artificially limiting the bandwidth at a value that may be less than the actual available bandwidth depending on the time of day, etc. I'm not sure what exactly OPNsense is doing with the bandwidth parameters, and I've asked on its forum ( https://forum.opnsense.org/index.php?topic=44501.0). My question for all of you is whether I am misunderstanding something about fq-codel. Does it need to be configured with the link bandwidth, or can it work nicely in its default configuration with variable bandwidth links (let's consider a typical home fiber connection between 300 and 1000 Mbps). Thanks for any insight you can share. --000000000000e6f6470628b4cc68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As far as I can tell, the= fq-codel algorithm (https://www.rfc-editor.org/rfc/rfc8290.html<= span style=3D"color:rgb(0,0,0)">) doesn't use link bandwidth as a param= eter. From reading the description, it seems like it should be able to work= without knowing the link bandwidth since it decides to drop packets based = on the amount of time they have waited in a queue. In fact, the original co= del rfc (https://www.rfc-editor.org/rfc/rfc8289#section-4.1) even says that it's designed to be = non-starving and work over variable bandwidth links.

However, I have noticed that the commercial implementations for at leas= t two firewalls that I have used (OPNsense and a Unifi gateway) both requir= e the user to input the upload and download bandwidths of the link.<= div style=3D"color:rgb(0,0,0)">
In= OPNsense I tried setting the bandwidth to a large number above the actual = link bandwidth and then manually setting the fq-codel parameters to their L= inux defaults, but that resulted in poor performance. My concern, of course= , is that I'm leaving throughput on the table by artificially limiting = the bandwidth at a value that may be less than the actual available bandwid= th depending on the time of day, etc.

I'm not sure what exactly= OPNsense is doing with the bandwidth parameters, and I've asked on its= forum (https://forum.opnsense.org/index.php?topic=3D44501.0). = My question for all of you is whether I am misunderstanding something about= fq-codel. Does it need to be configured with the link bandwidth, or can it= work nicely in its default configuration with variable bandwidth links (le= t's consider a typical home fiber connection between 300 and 1000 Mbps)= .

Thanks for any insight you can share.
--000000000000e6f6470628b4cc68--