[Starlink] [Bloat] [Rpm] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA

[Sebastian Moeller]

Hi Dave,

> On Mar 13, 2023, at 17:06, Dave Taht <dave.taht at gmail.com> wrote:
> 
> On Mon, Mar 13, 2023 at 8:50 AM Sebastian Moeller via Bloat
> <bloat at lists.bufferbloat.net> wrote:
>> 
>> Hi Jeremy,
>> 
>>> On Mar 13, 2023, at 16:08, Jeremy Austin <jeremy at aterlo.com> wrote:
>>> 
>>> 
>>> 
>>> On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink <starlink at lists.bufferbloat.net> wrote:
>>> Hi Dan,
>>> 
>>> 
>>>> On Jan 9, 2023, at 20:56, dan via Rpm <rpm at 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.

	[SM] The incumbent telco over here (and one of its competitors) indeed encode the rate the traffic shaper for an individual link is set via the PPPoE AuthACK message field (both ISPs use a slightly different format with one giving net rate and the other gross rates, but that can be dealt with). However this is not adjusted during load periods. So this still describes the most likely bottleneck link well (albeit only once per PPPoE session, so either every 24 hours or in the limit every 180 days with the incumbent) but does little for transient congestion of up- or downstream elements (in their defense the incumbent mostly removed its old aggregation network between DSLAMs and PPPOE termination points so there is little on that side than can get congested).
If this was a pony ranch, I would ask for:
downstream gross shaper rate
downstream per packet overhead
downstream MTU
downstream mpu

upstream gross shaper rate
upstream per packet overhead
upstream MTU
upstream mpu

the last three likely are identical for both directions, so we are essentially talking about 5 numbers, of which only two can be expected to fluctuate under load.

Now, a competent ISP would ask why do my users want to know that and the simply implement sufficiently competent AQM/traffic shaping at the download side ;) in addition to these 5 numbers.

Regards
Sebastian


> 
> 
>> 
>> 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: jeremy at preseem.com
>>> 
>>> Stay Connected with Newsletters & More: https://preseem.com/stay-connected/
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat at 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