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 <chromati...@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
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
