General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Sebastian Moeller <moeller0@gmx.de>
To: John D <j.w.r.dexter@gmail.com>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] SQM tuning question
Date: Sun, 4 Jun 2023 20:56:12 +0200	[thread overview]
Message-ID: <724593C4-0427-45EB-A12B-D1C372CFE780@gmx.de> (raw)
In-Reply-To: <CAKWkaxFkyc8xJdiAmzqQOPm1TpbEFGZV0SSDX0BnrzENVEwxUA@mail.gmail.com>

Hi John,


> On Jun 3, 2023, at 19:17, John D via Bloat <bloat@lists.bufferbloat.net> wrote:
> 
> Thanks for the detail. It makes sense but it kind of feels like in some (maybe many) cases the router could know the internet link performance.

	Sometimes they do, sometimes they do not, and sometimes the number the router might now is well above the contractual limit, e.g. my ISP for some time configured my VDSL2 link to sync at ~100/40 Mbps and restrict my capacity at an upstream device (BNG) to my contracted ~50/10 Mbps, so knowing the link speed will only give you an upper bound for some link technologies.


> Particularly home router-modems often monitor this already. Maybe that's just not exposed in any standardised way?

	Yes and no, all the link technologies I looked at (DSL/DOCSIS/PON) have some channel between the ISP side equipment (DSLAM/CMTS/OLT) and the equipment on the user side (CPE: DSL-/cable-/pon-modem) by which the ISP gear can query information from the CPE; but these three seem to be using three different approaches, and more importantly, just because the head-end can query these, does not mean that devices in the home network can do so as well...
	Plus, as mentioned above, the reported "sync" capacity might not be the capacity required to configure sqm's traffic shaper.


> I'm guessing if I was into openwrt I could maybe do something, but I prefer just to find something off the shelf with half decent SQM... If "auto configuration" isn't a feature then that answers my question and I can get on choosing the best option.

	There are the work-in-progress *-autorate approaches mentioned in my earlier post...

Kind Regards
	Sebastian


> 
> On Sat, Jun 3, 2023, 16:44 Jonathan Morton <chromatix99@gmail.com> wrote:
> > On 3 Jun, 2023, at 4:56 pm, John D via Bloat <bloat@lists.bufferbloat.net> wrote:
> > 
> > On the website it says the following:
> > 
> > CoDel is a novel “no knobs”, “just works”, “handles variable bandwidth and RTT”, and simple AQM algorithm.
> > 
> >       • It is parameterless — no knobs are required for operators, users, or implementers to adjust.
> >       • It treats good queue and bad queue differently - that is, it keeps the delays low while permitting bursts of traffic.
> >       • It controls delay, while insensitive to round-trip delays, link rates, and traffic loads.
> >       • It adapts to dynamically changing link rates with no negative impact on utilization.
> > 
> > But everywhere I have read about about hardware which implements SQM (including the bufferbloat website) it describes the need to tune based on actual internet connection speed.
> > These seem to conflict especially that "handles variable bandwidth" bit. Have I misunderstood or do the algorithms used in modern hardware just not provide this part typically? My connection performance is quite variable and I'm worried about crippling SQM to the lowest speed seen.
> 
> SQM in practice requires three components:
> 
> 1: Flow isolation, so that different flows don't affect each others' latency and are delivered fairly;
> 
> 2: Active Queue Management (AQM) to signal flows to slow down transmissions when link capacity is exceeded;
> 
> 3: Bandwidth shaping to match the queue to the available capacity.
> 
> CoDel is, in itself, only the AQM component.  It does indeed work pretty well with no additional tuning - but only in combination with the other two components, or when applied directly to the actual bottleneck.  Unfortunately in most consumer internet links, the actual bottleneck is inaccessible for this purpose.  Thus an artificial bottleneck must be introduced, at which SQM is applied.
> 
> The most convenient tool for applying all three SQM components at once is Cake.  This includes implementations of advanced flow isolation, CoDel AQM, and a deficit-mode bandwidth shaper.  All you really need to do is to tell it how much bandwidth you have in each direction, minus a small margin to ensure it becomes the actual bottleneck and can exert the necessary control.
> 
> When your available bandwidth varies over time, that can be inconvenient.  There are methods, however, of observing how available capacity tends to change over time (typically on diurnal and weekly patterns, if the variations are due to congestion in the ISP backhaul or peering) and scheduling adjustments on that basis.  If you have more information on your situation, we might be able to give more detailed advice.
> 
>  - Jonathan Morton
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


      parent reply	other threads:[~2023-06-04 18:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-03 13:56 John D
2023-06-03 15:44 ` Jonathan Morton
2023-06-03 16:54   ` Kenneth Porter
2023-06-04 18:48     ` Sebastian Moeller
2023-06-03 17:17   ` John D
2023-06-03 18:04     ` Aaron Wood
2023-06-04 19:55       ` Sebastian Moeller
2023-06-04 18:56     ` Sebastian Moeller [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=724593C4-0427-45EB-A12B-D1C372CFE780@gmx.de \
    --to=moeller0@gmx.de \
    --cc=bloat@lists.bufferbloat.net \
    --cc=j.w.r.dexter@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox