On Mon, Mar 13, 2023 at 8:50 AM Sebastian Moeller via Bloat <bloat@lists.bufferbloat.net> wrote: > > Hi Jeremy, > > > On Mar 13, 2023, at 16:08, Jeremy Austin <jer...@aterlo.com> wrote: > > > > > > > > On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink > > <starl...@lists.bufferbloat.net> wrote: > > Hi Dan, > > > > > > > On Jan 9, 2023, at 20:56, dan via Rpm <r...@lists.bufferbloat.net> wrote: > > > > > > You don't need to generate the traffic on a link to measure how > > > much traffic a link can handle. > > > > [SM] OK, I will bite, how do you measure achievable throughput > > without actually generating it? Packet-pair techniques are notoriously > > imprecise and have funny failure modes. > > > > I am also looking forward to the full answer to this question. While one > > can infer when a link is saturated by mapping network topology onto latency > > sampling, it can have on the order of 30% error, given that there are > > multiple causes of increased latency beyond proximal congestion. > > So in the "autorates" a family of automatic tracking/setting methods > for a cake shaper that (in friendly competition to each other) we use active > measurements of RTT/OWD increases and there we try to vary our set of > reflectors and then take a vote over a set of reflectors to decide "is it > cake^W congestion", that helps to weed out a few alternative reasons for > congestion detection (like distal congestion to individual reflectors). But > that dies not answer the tricky question how to estimate capacity without > actually creating a sufficient load (and doubly so on variable rate links). > > > > A question I commonly ask network engineers or academics is "How can I > > accurately distinguish a constraint in suppl from a reduction in demand?" > > Good question. The autorates can not, but then they do not need to as > they basically work by upping the shaper limit in correlation with the > offered load until it detects sufficiently increased delay and reduces the > shaper rates. A reduction n demand will lead to a reduction in load and > bufferbloat... so the shaper is adapted based on the demand, aka "give the > user as much thoughput as can be done within the users configured delay > threshold, but not more"... > > If we had a reliable method to "measure how much traffic a link can handle." > without having to track load and delay that would save us a ton of work ;)
My hope has generally been that a public API to how much bandwidth the ISP can reliabily provide at that moment would arise. There is one for at least one PPOe server, and I thought about trying to define one for dhcp and dhcpv6, but a mere get request to some kind of json that did up/down/link type would be nice. > > Regards > Sebastian > > > > > > -- > > -- > > Jeremy Austin > > Sr. Product Manager > > Preseem | Aterlo Networks > > preseem.com > > > > Book a Call: https://app.hubspot.com/meetings/jeremy548 > > Phone: 1-833-733-7336 x718 > > Email: jer...@preseem.com > > > > Stay Connected with Newsletters & More: https://preseem.com/stay-connected/ > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Come Heckle Mar 6-9 at: https://www.understandinglatency.com/ Dave Täht CEO, TekLibre, LLC _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
