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

[Sebastian Moeller via Bloat]

Hi Dan,


> On Mar 13, 2023, at 22:27, dan  wrote:
> 
> I’m sticking to my guns on this, but am prepared to let this particular 
> argument rest.  The threads is approaching unreadable.

[SM] Sorry I have a tendency of simultaneously pushing multiple 
discussion threads instead of focussing on the most important...

> 
> Let me throw something else out there.  It would be very nice to have some 
> standard packet type that was designed to be mangled by a traffic shaper.  So 
> you could initiate a speed test specifically to stress-test the link and then 
> exchange a packet that the shaper would update both ways with all the stats 
> you might want.  Ie, speed test is getting 80Mbps but there’s an additional 
> 20Mbps on-link so it should report to the user that 100M aggregate with the 
> details broken out usably. 

[SM] Yeah, that does not really work, the traffic shaper does not know 
that elusive capacity either... on some link technologies like ethernet 
something reportable might exist, but on variable rate links not so much. 
However it would be nice if traffic shapers cpuld be tickled to reveal their 
own primary configuration. As I answered to Dave in a different post we are 
talking about 4 numbers per shaper instance here:
gross shaper rate, per-packet-overhead, mpu (minimum packet unit), link-layer 
specific accpunting (e.g. 48/53 encapsulation for ATM/AAL5)
The first two are clearly shaper specific and I expect all competent shapers to 
use these; mpu is more a protocol issue (e.g. all link layers sending partial 
ethernet frames with frame check sequence inherit ethernets minimal packet size 
of 64 byte plus overhead.
For my own shaper I know these already, but my ISPs shapers are pretty 
opaque to me, so being able to query these would be great. (BTW, for speedtests 
in dispues with my ISP, I disable my traffic shaper obviously that capacity 
loss is not in their responsibility).


>  Could also report to that speed test client and server things like latency 
> over the last x minutes along

[SM] A normal shaper does not know this... and even cake/fq_codel that 
measure sojourn time per packet and have a decent idea about a packets 
flow-identity (not perfect as there is a limited number of hash buckets). It 
does not report anything useful in regards to "average" sojourn time for the 
packets in the measurement flows... (it would need to know when to start and 
when to stop at the very least). Honestly this looks more like a post-hoc job 
to be performed on packet captures than an on-line thing expected from a 
traffic/shaper/AQM.

> with throughput so again, could be charted out to show the ‘good put’ and 
> similar numbers.

[SM] Sorry to sound contrarien, but goodput is IMHO a number quite 
relevant to end-users, so that speed tests report an estimate of that number is 
A-OK with me, but I also understand that speedtest can not report the veridical 
gross bottleneck capacity in all cases anyway, due to lack of important 
information.

>  Basically, provide the end user with decently accurate data that includes 
> what the speed test app wasn’t able to see itself. 

[SM] Red herring IMHO, speedtests have clear issues and problems, the 
fact that they do not measure 100% of packets traversing a link is not one of 
them IMHO, they mostly are close enough to the theoretical numbers that 
differences can simply be ignored... as I said my ISP provisions a gross DSL 
sync of 116.7 Mbps but contractually only asserts a maximum of 100 Mbps goodput 
(over IPv6), the math for this works well and actually my ISP tends to 
over-fulfil the contractual rate in that I get ~105 Mbps of the 100 my contract 
promises... 
Sure personally I am more interested in the actuall gross rate my ISP 
sets its traffic shapers for my link too, but generally hitting the contract 
numbers is not rocket science if one is careful which rate to promise... ;)


>  It could also insert useful data around how many packets arrived that the 
> speed test app(s) could use to determine if there are issues on wan or lan.  

[SM] I think speedtests should report: number of parallel flows, total 
number of packets, total number of bytes transferred, number of retransmits, 
and finally MTU and more importantly for TCP MSS (or average packet size, but 
that is much harder to get at with TCP). AND latency under load ;)

> 
> I say mangle here because many traffic shapers are transparent so the speed 
> test app itself doesn’t really have a way to ask the shaper directly. 

[SM] I am pretty sue that is not going to come... as this smells like a 
gross layering violation, unless one comes up with some IP extension header to 
add that contains that information. Having intermediary nodes write into 
payload area of packets, is frowned upon in the IETF IIRC...

> 
> My point in all of this is that if you’re giving the end user information, it 
> should be right.  No 

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

[dan via Bloat]

 I’m sticking to my guns on this, but am prepared to let this particular
argument rest.  The threads is approaching unreadable.

Let me throw something else out there.  It would be very nice to have some
standard packet type that was designed to be mangled by a traffic shaper.
So you could initiate a speed test specifically to stress-test the link and
then exchange a packet that the shaper would update both ways with all the
stats you might want.  Ie, speed test is getting 80Mbps but there’s an
additional 20Mbps on-link so it should report to the user that 100M
aggregate with the details broken out usably.  Could also report to that
speed test client and server things like latency over the last x minutes
along with throughput so again, could be charted out to show the ‘good put’
and similar numbers.  Basically, provide the end user with decently
accurate data that includes what the speed test app wasn’t able to see
itself.  It could also insert useful data around how many packets arrived
that the speed test app(s) could use to determine if there are issues on
wan or lan.

I say mangle here because many traffic shapers are transparent so the speed
test app itself doesn’t really have a way to ask the shaper directly.

My point in all of this is that if you’re giving the end user information,
it should be right.  No information is better than false information.  End
users will call their ISP or worse get on social media and trash them
because they bought a $29 netgear at Walmart that is terrible.

After all the entire point if all of this is end-user experience.  The only
benefit to ISPs is that happy users are good for business.  A lot of the
data that can be collected at various points along the path are better for
ISPs to use to update their networks to improve user experience, but aren’t
so useful to the 99% of users that just want low ‘lag’ on their games and
no buffering.




On Mar 13, 2023 at 3:00:23 PM, Sebastian Moeller  wrote:

> Hi Jeremy,
>
> On Mar 13, 2023, at 20:52, Jeremy Austin  wrote:
>
>
>
>
> On Mon, Mar 13, 2023 at 12:34 PM dan  wrote:
>
>
> See, you're coming around.  Cake is autorating (or very close, 'on
>
> device') at the wan port.  not the speed test device or software.  And
>
> the accurate data is collected by cake, not the speed test tool.  That
>
> tool is reporting false information because it must, it doesn't know
>
> the other consumers on the network.  It's 'truest' when the network is
>
> quiet but the more talkers the more the tool lies.
>
>
> cake, the kernel, and the wan port all have real info, the speed test
>
> tool does not.
>
>
> I'm running a bit behind on commenting on the thread (apologies, more
> later) but I point you back at my statement about NTIA (and, to a certain
> extent, the FCC):
>
>
> Consumers use speed tests to qualify their connection.
>
>
> [SM] And rightly so... this put a nice stop to the perverse practice of
> selling contracts stating (up to) 100 Mbps for links that never could reach
> that capacity ever, now an ISP is careful in what they promise... Speedtest
> (especially using the official speedtest app that tries to make users pay
> attention to a number of important points, e.g. not over WiFi, but over an
> ethernet port that has a capacity above the contracted speed) seem to be
> good enough for that purpose. Really over here that is the law and ISP
> still are doing fine and we are taking low single digit thousands of
> complaints in a market with ~40 million households.
>
>
> Whether AQM is applied or not, a speed test does not reflect in all
> circumstances the capacity of the pipe. One might argue that it seldom
> reflects it.
>
>
> [SM] But one would be wrong, at least the official speedtests over here
> are pretty reliable, but they seem to be competenyly managed. E.g. users
> need to put in the contracted speed (drop down boxes to the select ISP and
> contract name) and the test infrastructure will only start the test if it
> managed to reserver sufficient capacity of the test servers to reliably
> saturate the contracted rate. This is a bit of engineering and not
> witchcraft, really. ;)
>
> Unfortunately, those who have "real info", to use Dan's term, are
> currently nearly powerless to use it. I am, if possible, on both the ISP
> and consumer side here.
>
>
> [SM] If you are talking about speedtests being systemicly wrong in getting
> usabe capacity estimates I disagree, if your point is that a sole focus on
> this measure is missing the way more important point od keeping latency
> under load limited, I fully agree. That point currently is lost on the
> national regulator over here as well.
>
> And yes, Preseem does have an iron in this fire, or at least a dog in this
> fight.
>
>
> [SM] Go team!
>
> Ironically, the FCC testing for CAF/RDOF actually *does* take interface
> load into account, only tests during peak busy hours, and /then/ does a
> speed test. But NTIA largely ignores that for BEAD.
>
>
> [SM] I admit that I 

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

[Sebastian Moeller via Bloat]

Hi Jeremy,

> On Mar 13, 2023, at 20:52, Jeremy Austin  wrote:
> 
> 
> 
> On Mon, Mar 13, 2023 at 12:34 PM dan  wrote:
> 
> See, you're coming around.  Cake is autorating (or very close, 'on
> device') at the wan port.  not the speed test device or software.  And
> the accurate data is collected by cake, not the speed test tool.  That
> tool is reporting false information because it must, it doesn't know
> the other consumers on the network.  It's 'truest' when the network is
> quiet but the more talkers the more the tool lies.
> 
> cake, the kernel, and the wan port all have real info, the speed test
> tool does not.
> 
> I'm running a bit behind on commenting on the thread (apologies, more later) 
> but I point you back at my statement about NTIA (and, to a certain extent, 
> the FCC): 
> 
> Consumers use speed tests to qualify their connection.

[SM] And rightly so... this put a nice stop to the perverse practice of 
selling contracts stating (up to) 100 Mbps for links that never could reach 
that capacity ever, now an ISP is careful in what they promise... Speedtest 
(especially using the official speedtest app that tries to make users pay 
attention to a number of important points, e.g. not over WiFi, but over an 
ethernet port that has a capacity above the contracted speed) seem to be good 
enough for that purpose. Really over here that is the law and ISP still are 
doing fine and we are taking low single digit thousands of complaints in a 
market with ~40 million households.

> 
> Whether AQM is applied or not, a speed test does not reflect in all 
> circumstances the capacity of the pipe. One might argue that it seldom 
> reflects it.

[SM] But one would be wrong, at least the official speedtests over here 
are pretty reliable, but they seem to be competenyly managed. E.g. users need 
to put in the contracted speed (drop down boxes to the select ISP and contract 
name) and the test infrastructure will only start the test if it managed to 
reserver sufficient capacity of the test servers to reliably saturate the 
contracted rate. This is a bit of engineering and not witchcraft, really. ;)

> Unfortunately, those who have "real info", to use Dan's term, are currently 
> nearly powerless to use it. I am, if possible, on both the ISP and consumer 
> side here.

[SM] If you are talking about speedtests being systemicly wrong in 
getting usabe capacity estimates I disagree, if your point is that a sole focus 
on this measure is missing the way more important point od keeping latency 
under load limited, I fully agree. That point currently is lost on the national 
regulator over here as well.

> And yes, Preseem does have an iron in this fire, or at least a dog in this 
> fight.

[SM] Go team!

> Ironically, the FCC testing for CAF/RDOF actually *does* take interface load 
> into account, only tests during peak busy hours, and /then/ does a speed 
> test. But NTIA largely ignores that for BEAD.

[SM] I admit that I have not looked deeply into these different test 
methods, and will shut up about this topic until I did to avoid wasting your 
time.

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

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

[Sebastian Moeller via Bloat]

Hi Dan,


> On Mar 13, 2023, at 20:33, dan  wrote:
> 
>> 
>>I respectfully disagree, if say, my modem had a 4 GB queue I could 
>> theoretically burst ~4GB worth of data at line rate into that buffer without 
>> learning anything about the the modem-link capacity.
> 
> so this is where we're getting into staw man arguments.  Find me a
> single device or shaper with a 4GB buffer and we'll talk.

[SM] Sure, the moment you tell me how to measure true capacity without 
load ;) but my point stays intial burtst from my router to the modem will be 
absorbed by the modems queues and will not be indicative of the ink capacity.


>> 
>> 
>>> turn off the
>>> shaper and run anything.  run your speed test.  don't look at the
>>> speed test results, just use it to generate some traffic.  you'll find
>>> your peak and where you hit the buffers on the DSL modem by measuring
>>> on the interface and measuring latency.
>> 
>>Peak of what? Exactly? The peak sending rate of my router is well 
>> known, its 1 Gbps gross ethernet rate...
> 
> I don't know how I can say it any clearer.  there is a port, any
> speed.  data flows across that port.  The peak data flowing is the
> measure.  simultaneously measuring latency will give the 'best' rate.
> so called 'goodput' which is a stupid name and I hate it but there it
> is.

[SM] Sorry the peak gross ate on my gigabit interface to the modem in 
spite of my shaper is always going to be 1 Gbps what changes is the duty 
cycle... so without averaging this method of yours looks only partially useful.


> 
>> 
>> 
>>> That speed test isn't giving
>>> you this data and more than Disney+, other than you get to pick when
>>> it runs.
>> 
>>Hrm, no we sre back at actually saturating the link,
> 
> which we're doing all the time.  it's the entire premise of QoE.
> Links get saturated, manage them.

[SM] Mmmh, my goal (and your promise) was to be able to estimate the 
saturation capacity before/without actually hitting it. Which s the whole 
reason why cake-autorate exists, if we knew that we would track (a low passed 
version) of that value with our shaper and be done with...


> 
>> 
> 
>> 
>>[SM] not really, given enough capacity, typical streaming protocols 
>> will actually not hit the ceiling, at least the one's I look at every now 
>> and then tend to stay well below actual capacity of the link.
> 
> Not sure where you're getting this info, I'm looking right at
> customers on everything from 25Mbps to 800Mbps plans.

[SM] I guess I need to take a packet capture, I have a hunch that I 
might see ECN in action and a lack of drops is not indicative of slow-start not 
ending, Ho-hom something for my todo list


>  And again, I'm
> not saying you can saturate the link intentionally, I'm saying that
> the tool doing the saturation isn't actually giving you accurate
> results.  You have to look at the interface and the latency for the
> results.  The speed test is a traffic generator, not a measuring tool.
> It's fundamentally cannot do the measuring, it's doesn't have the
> ability to see other flows on the interface.

[SM] Ah, now I get your point, but I also ignore that point immediately 
as that is a) not the capacity resolution I typically need, b) in cake autorate 
we actually extract interface counters exactly  because we want to see all 
traffic. But comparing cake-autorate traces with speedtest curves (e.g. flent) 
looks pretty well correlated, so for my use cases the typical speedtests gve 
actionable and useful (albeit not perfect) capacity estimates, the longer 
running the better. This is a strike against all of these 10-20 seconds tests, 
but e.g. fast.com can be configured easily to measure each direction for a full 
minute, which side steps our buffer filling versus filling the link capacity 
discussion nicely, as my modem's buffers are not nearly large enough to absorg 
a noticeable portion of this 60 second load.


> 
>> 
>> 
>>[SM] But my problem is that on variable rate links I want to measure 
>> the instantaneous capacity such that I can do adaptive admission control and 
>> avpid over filling my modem's DSL buffers (I wish they would do something 
>> like BQL, but alas they don't).
> 
> Literally measure the interface on a schedule or constantly and you're
> getting this measurement every time you use the link.  and if you
> measure the latency you're constantly finding the spot right below the
> buffers.

[SM] Well except I can not measure the relevant interface veridically, 
the DSL SoC internal buffering for GINP retransmissions is not exposed to the 
OS but handled inside the "modem".


> 
> 
>> 
>>[SM] With competent AQM (like cake on ingress and egress configured 
>> for per-internal-IP isolation) I do not even notice whether a speedtes runs 
>> or not, and from the reported capacity I can estimate the concurrent load 
>> from other endhosts in my network.
> 
> 

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

[rjmcmahon via Bloat]

[SM] It is doe because:
a) TCP needs some capacity estimate
b) preferably quickly
c) in a way gentler than what was used before the congestion collapse.


Right, but we're moving away from capacity shortages to a focus on 
better latencies. The speed of distributed compute (or speed of 
causality) is now mostly latency constrained.


Also, it's impossible per Jaffe & others for a TCP link to figure out 
the on-demand capacity so trying to get one via a "broken control loop" 
seems futile. I believe control theory states control loops need to be 
an order greater than what they're trying to control. I don't think an 
app or transport layer can do more than make educated guesses at for its 
control loop. Using a rating might help with that but for sure it's not 
accurate in space-time samples. (Note: many APs are rated 60+ Watts. 
What's the actual? Has to be sampled and that's only a sample. This 
leads to poor PoE designs - but I digress.)


Let's assume the transport layer should be designed to optimize the 
speed of causality. This also seems impossible because the e2e jitter is 
worse with respect to end host discovery so there seems no way to adapt 
from end host only.


If it's true that the end can only guess, maybe the solution domain 
comes from incorporating network measurements via telemetry with the ECN 
or equivalent? And an app can signal to the network elements to capture 
the e2e telemetry. I think this all has to happen within a few RTTs if 
the transport or host app is going to adjust.


Bob

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Sebastian Moeller via Bloat]

Hi Bob,


> On Mar 13, 2023, at 20:32, rjmcmahon  wrote:
> 
> On 2023-03-13 11:51, Sebastian Moeller wrote:
>> Hi Bob,
>>> On Mar 13, 2023, at 19:42, rjmcmahon  wrote:
[SM] not really, given enough capacity, typical streaming protocols
 will actually not hit the ceiling, at least the one's I look at every
 now and then tend to stay well below actual capacity of the link.
>>> I think DASH type protocol will hit link peaks. An example with iperf 2's 
>>> burst option a controlled WiFi test rig, server side first.
>>  [SM] I think that depends, each segment has only a finite length and
>> if this can delivered before slow start ends that burst might never
>> hit the capacity?
>> Regards
> 
> I believe most CDNs are setting the initial CWND so TCP can bypass slow start.

[SM] My take is not necessarily to bypass slow start, but to kick it 
off with a higher starting point... which is the conservative way to expedite 
slow-start. Real man actually increase the multiplication factor instead, but 
there are few real men around (luckily)... s I see both the desire to finish 
many smaller transfers within the initial window (so the first RTT after the 
handshake IIUC).

> Slow start seems an engineering flaw from the perspective of low latency.

[SM] Yes, exponential search, doubling every RTT is pretty aggressive.


> It's done for "fairness" whatever that means.

[SM] It is doe because:
a) TCP needs some capacity estimate
b) preferably quickly
c) in a way gentler than what was used before the congestion collapse.
we are calling it slow-start not because it is slow in absolute terms 
(it is pretty aggressive already)
but IIUC because before slow start people where even more aggressive 
(immediately sending at line rate?)

I think we need immediate queue build-up feedback so each flow can look at its 
own growth projection and the queue space shrinkage projection and then 
determine where these two will meet. Essentially we need  a gently way of 
ending slow-start instead of the old chestnut, dump twice as much data in 
flight into the network before we notice... it is this part that is at odds 
with low latency. L4s, true to form with its essential bit-banging of queue 
filling status over all flows in the LL queue is essentially givvin too little 
information too late. 


If I had a better proposal for a slow-start altenative I would make it, but for 
me slow-start is similar to what Churchill is supposed to have said about 
democracy "democracy is the worst form of government – except for all the 
others that have been tried."...


> 
> Bob

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Jeremy Austin via Bloat]

On Mon, Mar 13, 2023 at 12:34 PM dan  wrote:

>
> See, you're coming around.  Cake is autorating (or very close, 'on
> device') at the wan port.  not the speed test device or software.  And
> the accurate data is collected by cake, not the speed test tool.  That
> tool is reporting false information because it must, it doesn't know
> the other consumers on the network.  It's 'truest' when the network is
> quiet but the more talkers the more the tool lies.
>
> cake, the kernel, and the wan port all have real info, the speed test
> tool does not.
>

I'm running a bit behind on commenting on the thread (apologies, more
later) but I point you back at my statement about NTIA (and, to a certain
extent, the FCC):

Consumers use speed tests to qualify their connection.

Whether AQM is applied or not, a speed test does not reflect in all
circumstances the capacity of the pipe. One might argue that it seldom
reflects it.

Unfortunately, those who have "real info", to use Dan's term, are currently
nearly powerless to use it. I am, if possible, on both the ISP and consumer
side here.

And yes, Preseem does have an iron in this fire, or at least a dog in this
fight.

Ironically, the FCC testing for CAF/RDOF actually *does* take interface
load into account, only tests during peak busy hours, and /then/ does a
speed test. But NTIA largely ignores that for BEAD.

-- 
--
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

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

[dan via Bloat]

>
> I respectfully disagree, if say, my modem had a 4 GB queue I could 
> theoretically burst ~4GB worth of data at line rate into that buffer without 
> learning anything about the the modem-link capacity.

so this is where we're getting into staw man arguments.  Find me a
single device or shaper with a 4GB buffer and we'll talk.
>
>
> >  turn off the
> > shaper and run anything.  run your speed test.  don't look at the
> > speed test results, just use it to generate some traffic.  you'll find
> > your peak and where you hit the buffers on the DSL modem by measuring
> > on the interface and measuring latency.
>
> Peak of what? Exactly? The peak sending rate of my router is well 
> known, its 1 Gbps gross ethernet rate...

I don't know how I can say it any clearer.  there is a port, any
speed.  data flows across that port.  The peak data flowing is the
measure.  simultaneously measuring latency will give the 'best' rate.
so called 'goodput' which is a stupid name and I hate it but there it
is.

>
>
> > That speed test isn't giving
> > you this data and more than Disney+, other than you get to pick when
> > it runs.
>
> Hrm, no we sre back at actually saturating the link,

which we're doing all the time.  it's the entire premise of QoE.
Links get saturated, manage them.

>

>
> [SM] not really, given enough capacity, typical streaming protocols 
> will actually not hit the ceiling, at least the one's I look at every now and 
> then tend to stay well below actual capacity of the link.

Not sure where you're getting this info, I'm looking right at
customers on everything from 25Mbps to 800Mbps plans.  And again, I'm
not saying you can saturate the link intentionally, I'm saying that
the tool doing the saturation isn't actually giving you accurate
results.  You have to look at the interface and the latency for the
results.  The speed test is a traffic generator, not a measuring tool.
It's fundamentally cannot do the measuring, it's doesn't have the
ability to see other flows on the interface.

>
>
> [SM] But my problem is that on variable rate links I want to measure 
> the instantaneous capacity such that I can do adaptive admission control and 
> avpid over filling my modem's DSL buffers (I wish they would do something 
> like BQL, but alas they don't).

Literally measure the interface on a schedule or constantly and you're
getting this measurement every time you use the link.  and if you
measure the latency you're constantly finding the spot right below the
buffers.


>
> [SM] With competent AQM (like cake on ingress and egress configured 
> for per-internal-IP isolation) I do not even notice whether a speedtes runs 
> or not, and from the reported capacity I can estimate the concurrent load 
> from other endhosts in my network.

exactly.  EXACTLY.  You might just be coming around.  That speed test
was held back by the shaper for your benefit NOT the speed test's.
It's results are necessarily false.  YOU can estimate the capacity by
adding up the speedtest results and your other uses.  Measuring the
outside interface gives you exactly that.  the speed test does not.
it's just a traffic generator for when you aren't generating it on
your own.


>
>
> >  Speed test cannot return actual capacity
>
> [SM] Conventional capcaity tests give a decent enough estimate of 
> current capacity to be useful, I could not care less that they are potential 
> not perfect, sorry. The question still is how to estimate capacity without 
> loading the link...

you have to load the link to know this.  Again, the speed test is a
traffic generator, it's not a measuring tool.  You have to measure at
the wan interface to know this, you can never get it from the speed
test.  And no, the speed test isn't a decent enough estimate.  The
more important the data is to you the more likely the test is bad and
going to lie.  Internet feeling slow? run a speed test and put more
pressure on the service and the speed test has less available to
return results on, all the other services getting their slice of the
pie.

>
>
> > Guess what the only way to get an actual measure of the capacity is?
> > my way.  measure what's passing the interface and measure what happens
> > to a reliable latency test during that time.
>
> [SM] This is, respectfully, what we do in cake-autorate, but that 
> requires an actual load and only accidentally detects the capacity, if a high 
> enough load is sustained long enough to evoke a latency increase. But I knew 
> that already, what you initially wrote sounded to me like you had a method to 
> detect instantaneous capacity without needing to generate load. (BTW, in 
> cake-autorate we do not generate an artificial load (only artificial/active 
> latency probes) but use the organic user generated traffic as load 
> generator*).
>
> *) If all endhosts are idle we do not care much about the capacity, only if 
> there is traffic, however the quicker we 

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

[rjmcmahon via Bloat]

On 2023-03-13 11:51, Sebastian Moeller wrote:

Hi Bob,



On Mar 13, 2023, at 19:42, rjmcmahon  wrote:


[SM] not really, given enough capacity, typical streaming protocols
will actually not hit the ceiling, at least the one's I look at every
now and then tend to stay well below actual capacity of the link.
I think DASH type protocol will hit link peaks. An example with iperf 
2's burst option a controlled WiFi test rig, server side first.


[SM] I think that depends, each segment has only a finite length and
if this can delivered before slow start ends that burst might never
hit the capacity?

Regards


I believe most CDNs are setting the initial CWND so TCP can bypass slow 
start. Slow start seems an engineering flaw from the perspective of low 
latency. It's done for "fairness" whatever that means.


Bob
___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Sebastian Moeller via Bloat]

Hi Bob,


> On Mar 13, 2023, at 19:42, rjmcmahon  wrote:
> 
>>  [SM] not really, given enough capacity, typical streaming protocols
>> will actually not hit the ceiling, at least the one's I look at every
>> now and then tend to stay well below actual capacity of the link.
> I think DASH type protocol will hit link peaks. An example with iperf 2's 
> burst option a controlled WiFi test rig, server side first.

[SM] I think that depends, each segment has only a finite length and if 
this can delivered before slow start ends that burst might never hit the 
capacity?

Regards
Sebastian


> 
> 
> [root@ctrl1fc35 ~]# iperf -s -i 1 -e --histograms
> 
> Server listening on TCP port 5001 with pid 23764
> Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
> Enabled receive histograms bin-width=0.100 ms, bins=1 (clients should use 
> --trip-times)
> TCP window size:  128 KByte (default)
> 
> [  1] local 192.168.1.15%enp2s0 port 5001 connected with 192.168.1.234 port 
> 34894 (burst-period=1.00s) (trip-times) (sock=4) (peer 2.1.9-rc2) 
> (icwnd/mss/irtt=14/1448/5170) on 2023-03-13 11:37:24.500 (PDT)
> [ ID] Burst (start-end)  Transfer Bandwidth   XferTime  (DC%) 
> Reads=Dist  NetPwr
> [  1] 0.00-0.13 sec  10.0 MBytes   633 Mbits/sec  132.541 ms (13%)
> 209=29:31:31:88:11:2:1:16  597
> [  1] 1.00-1.11 sec  10.0 MBytes   755 Mbits/sec  111.109 ms (11%)
> 205=34:30:22:83:11:2:6:17  849
> [  1] 2.00-2.12 sec  10.0 MBytes   716 Mbits/sec  117.196 ms (12%)
> 208=33:39:20:81:13:1:5:16  763
> [  1] 3.00-3.11 sec  10.0 MBytes   745 Mbits/sec  112.564 ms (11%)
> 203=27:36:30:76:6:3:6:19  828
> [  1] 4.00-4.11 sec  10.0 MBytes   787 Mbits/sec  106.621 ms (11%)
> 193=29:26:19:80:10:4:6:19  922
> [  1] 5.00-5.11 sec  10.0 MBytes   769 Mbits/sec  109.148 ms (11%)
> 208=36:25:32:86:6:1:5:17  880
> [  1] 6.00-6.11 sec  10.0 MBytes   760 Mbits/sec  110.403 ms (11%)
> 206=42:30:22:73:8:3:5:23  860
> [  1] 7.00-7.11 sec  10.0 MBytes   775 Mbits/sec  108.261 ms (11%)
> 171=20:21:21:58:12:1:11:27  895
> [  1] 8.00-8.11 sec  10.0 MBytes   746 Mbits/sec  112.405 ms (11%)
> 203=36:31:28:70:9:3:2:24  830
> [  1] 9.00-9.11 sec  10.0 MBytes   748 Mbits/sec  112.133 ms (11%)
> 228=41:56:27:73:7:2:3:19  834
> [  1] 0.00-10.00 sec   100 MBytes  83.9 Mbits/sec  
> 113.238/106.621/132.541/7.367 ms  2034=327:325:252:768:93:22:50:197
> [  1] 0.00-10.00 sec F8(f)-PDF: 
> bin(w=100us):cnt(10)=1067:1,1083:1,1092:1,1105:1,1112:1,1122:1,1125:1,1126:1,1172:1,1326:1
>  (5.00/95.00/99.7%=1067/1326/1326,Outliers=0,obl/obu=0/0) (132.541 
> ms/1678732644.500333)
> 
> 
> [root@fedora ~]# iperf -c 192.168.1.15 -i 1 -t 10 --burst-size 10M 
> --burst-period 1 --trip-times
> 
> Client connecting to 192.168.1.15, TCP port 5001 with pid 132332 (1 flows)
> Write buffer size: 131072 Byte
> Bursting: 10.0 MByte every 1.00 second(s)
> TOS set to 0x0 (Nagle on)
> TCP window size: 16.0 KByte (default)
> Event based writes (pending queue watermark at 16384 bytes)
> 
> [  1] local 192.168.1.234%eth1 port 34894 connected with 192.168.1.15 port 
> 5001 (prefetch=16384) (trip-times) (sock=3) (icwnd/mss/irtt=14/1448/5489) 
> (ct=5.58 ms) on 2023-03-13 11:37:24.494 (PDT)
> [ ID] IntervalTransferBandwidth   Write/Err  Rtry 
> Cwnd/RTT(var)NetPwr
> [  1] 0.00-1.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5517K/18027(1151) us  582
> [  1] 1.00-2.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5584K/13003(2383) us  806
> [  1] 2.00-3.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5613K/16462(962) us  637
> [  1] 3.00-4.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5635K/19523(671) us  537
> [  1] 4.00-5.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5594K/10013(1685) us  1047
> [  1] 5.00-6.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5479K/14008(654) us  749
> [  1] 6.00-7.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5613K/17752(283) us  591
> [  1] 7.00-8.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5599K/17743(436) us  591
> [  1] 8.00-9.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 5577K/11214(2538) us  935
> [  1] 9.00-10.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
> 4178K/7251(993) us  1446
> [  1] 0.00-10.01 sec   100 MBytes  83.8 Mbits/sec  800/0 0 
> 4178K/7725(1694) us  1356
> [root@fedora ~]#
> 
> Note: Client side output is being updated to support outputs based upon the 
> bursts. This allows one to see that a DASH type protocol can drive the bw 
> bottleneck queue.
> 
> Bob
> 

___
Bloat mailing list
Bloat@lists.bufferbloat.net

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

[rjmcmahon via Bloat]

[SM] not really, given enough capacity, typical streaming protocols
will actually not hit the ceiling, at least the one's I look at every
now and then tend to stay well below actual capacity of the link.

I think DASH type protocol will hit link peaks. An example with iperf 
2's burst option a controlled WiFi test rig, server side first.



[root@ctrl1fc35 ~]# iperf -s -i 1 -e --histograms

Server listening on TCP port 5001 with pid 23764
Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
Enabled receive histograms bin-width=0.100 ms, bins=1 (clients 
should use --trip-times)

TCP window size:  128 KByte (default)

[  1] local 192.168.1.15%enp2s0 port 5001 connected with 192.168.1.234 
port 34894 (burst-period=1.00s) (trip-times) (sock=4) (peer 2.1.9-rc2) 
(icwnd/mss/irtt=14/1448/5170) on 2023-03-13 11:37:24.500 (PDT)
[ ID] Burst (start-end)  Transfer Bandwidth   XferTime  (DC%)
 Reads=Dist  NetPwr
[  1] 0.00-0.13 sec  10.0 MBytes   633 Mbits/sec  132.541 ms (13%)
209=29:31:31:88:11:2:1:16  597
[  1] 1.00-1.11 sec  10.0 MBytes   755 Mbits/sec  111.109 ms (11%)
205=34:30:22:83:11:2:6:17  849
[  1] 2.00-2.12 sec  10.0 MBytes   716 Mbits/sec  117.196 ms (12%)
208=33:39:20:81:13:1:5:16  763
[  1] 3.00-3.11 sec  10.0 MBytes   745 Mbits/sec  112.564 ms (11%)
203=27:36:30:76:6:3:6:19  828
[  1] 4.00-4.11 sec  10.0 MBytes   787 Mbits/sec  106.621 ms (11%)
193=29:26:19:80:10:4:6:19  922
[  1] 5.00-5.11 sec  10.0 MBytes   769 Mbits/sec  109.148 ms (11%)
208=36:25:32:86:6:1:5:17  880
[  1] 6.00-6.11 sec  10.0 MBytes   760 Mbits/sec  110.403 ms (11%)
206=42:30:22:73:8:3:5:23  860
[  1] 7.00-7.11 sec  10.0 MBytes   775 Mbits/sec  108.261 ms (11%)
171=20:21:21:58:12:1:11:27  895
[  1] 8.00-8.11 sec  10.0 MBytes   746 Mbits/sec  112.405 ms (11%)
203=36:31:28:70:9:3:2:24  830
[  1] 9.00-9.11 sec  10.0 MBytes   748 Mbits/sec  112.133 ms (11%)
228=41:56:27:73:7:2:3:19  834
[  1] 0.00-10.00 sec   100 MBytes  83.9 Mbits/sec  
113.238/106.621/132.541/7.367 ms  2034=327:325:252:768:93:22:50:197
[  1] 0.00-10.00 sec F8(f)-PDF: 
bin(w=100us):cnt(10)=1067:1,1083:1,1092:1,1105:1,1112:1,1122:1,1125:1,1126:1,1172:1,1326:1 
(5.00/95.00/99.7%=1067/1326/1326,Outliers=0,obl/obu=0/0) (132.541 
ms/1678732644.500333)



[root@fedora ~]# iperf -c 192.168.1.15 -i 1 -t 10 --burst-size 10M 
--burst-period 1 --trip-times


Client connecting to 192.168.1.15, TCP port 5001 with pid 132332 (1 
flows)

Write buffer size: 131072 Byte
Bursting: 10.0 MByte every 1.00 second(s)
TOS set to 0x0 (Nagle on)
TCP window size: 16.0 KByte (default)
Event based writes (pending queue watermark at 16384 bytes)

[  1] local 192.168.1.234%eth1 port 34894 connected with 192.168.1.15 
port 5001 (prefetch=16384) (trip-times) (sock=3) 
(icwnd/mss/irtt=14/1448/5489) (ct=5.58 ms) on 2023-03-13 11:37:24.494 
(PDT)
[ ID] IntervalTransferBandwidth   Write/Err  Rtry 
Cwnd/RTT(var)NetPwr
[  1] 0.00-1.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5517K/18027(1151) us  582
[  1] 1.00-2.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5584K/13003(2383) us  806
[  1] 2.00-3.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5613K/16462(962) us  637
[  1] 3.00-4.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5635K/19523(671) us  537
[  1] 4.00-5.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5594K/10013(1685) us  1047
[  1] 5.00-6.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5479K/14008(654) us  749
[  1] 6.00-7.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5613K/17752(283) us  591
[  1] 7.00-8.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5599K/17743(436) us  591
[  1] 8.00-9.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
5577K/11214(2538) us  935
[  1] 9.00-10.00 sec  10.0 MBytes  83.9 Mbits/sec  80/0 0 
4178K/7251(993) us  1446
[  1] 0.00-10.01 sec   100 MBytes  83.8 Mbits/sec  800/0 0 
4178K/7725(1694) us  1356

[root@fedora ~]#

Note: Client side output is being updated to support outputs based upon 
the bursts. This allows one to see that a DASH type protocol can drive 
the bw bottleneck queue.


Bob

___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Sebastian Moeller via Bloat]

Hi Jeremy,


> On Mar 13, 2023, at 18:37, Jeremy Austin  wrote:
> 
> 
> 
> On Mon, Mar 13, 2023 at 10:26 AM dan  wrote:
> 
> 
> If you troubleshoot your ISP based on speed tests you will be chasing
> your tail.  Meanwhile, that internet facing interface can see the true
> numbers the entire time.  The consumer is pulling their full capacity
> on almost all links routinely even if briefly and can be nudged into
> pushing more a dozen ways (including a speed test).  The only thing
> lacking is a latency measurement of some sort.  Preseem and Libreqos's
> TCP measurements on the head end are awesome, but that's not available
> on the subscriber's side but if it were, there's the full testing
> suite.  how much peak data, what happened to latency.  If you could
> get data from the ISP's head end to diff you'd have internet vs isp
> latencies.'speed test' is a stress test or a burn in test in
> effect.
> 
> I cannot upvote this enough. I call speed tests — and in fact any packet 
> injection doing more than a bare minimum probe — destructive testing, and 
> said as much to NTIA recently.

[SM] Why? With competent traffic shaping, scheduling and AQM even a 
capacity test running at full throttle (like e.g a three minute bidirectional 
flent RRUL test) is not destructive to network responsiveness. I am not saying 
that the network behaves as if there was no load, but the old, "stop your 
downloads I have a VoIP call/vide conference coming scenario" really only need 
to happen at networks with way too little capacity assigned. 


> The *big problem* (emphasis mine) is that the recent BEAD NOFO, pumping tens 
> of billions of dollars into broadband, has *speedtests* as the "proof" that 
> an ISP is delivering.

[SM] I respectfully disagree, as long as ISP market and price on 
capacity it is not unreasonable to actually have end-users actually measure 
capacity. I do agree the way we d this currently is sub-optimal though. And it 
is a but unfair to ISPs as other business fields are not held to such 
standards. However, my solution would be to hold other businesses equally to 
account for their promises, not letting ISPs off the hook ;) (but easy for me 
to say, I do not operate/work for an ISP and likely misunderstand all the 
subtleties involved).


> It's one thing to solve this problem at the ISP and consumer level. It's 
> another to solve it at the political level. In this case, I think it's 
> incumbent on ISPs to atone for former sins — now that we know that speed 
> tests are not just bad but actively misleading, we need to provide real tools 
> and education.

[SM] +1; however as long as ISP essentially sell  capacity, capacity 
tests will stay relevant. 

> 
> Going back to my previous comment, and no disrespect meant to the CAKE 
> autorate detection: "How do we distinguish between constrained supply and 
> reduced demand *without injecting packets or layer violations*?"

[SM] Oh, I share this question especially with my cake-autprate junior 
partner hat on... in theory one could not only use the organic load, but also 
the organic TCP timestamp increases as shown by pping to estimate times when 
the load exceeds/meets capacity (I think preseem have an iron in the fire there 
as well), but that is also not without its challenged. E.g. my router sits 
behind a bridged modem, but accesses the modem over the same link as the 
internet and routinely collects data from the modem, will pping now give the 
delay to the modem as its minimal estimate? If it does it is pretty much 
useless as that RTT is going to essentially stay flat as it is not affected by 
the bottleneck queue to/from the internet... (that is why the autorates opted 
for active probes as that allows to select spatially separate reflectors).

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

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

[Sebastian Moeller via Bloat]

Hi Dan,


> On Mar 13, 2023, at 18:26, dan  wrote:
> 
> On Mon, Mar 13, 2023 at 10:36 AM Sebastian Moeller  wrote:
>> 
>> Hi Dan,
>> 
>> 
>>> On Mar 13, 2023, at 17:12, dan  wrote:
>>> ...
>>> 
>>> High water mark on their router.
>> 
>>[SM] Nope, my router is connected to my (bridged) modem via gigabit 
>> ethernet, with out a traffic shaper there is never going to be any 
>> noticeable water mark on the router side... sure the modem will built up a 
>> queue, but alas it does not expose the length of that DSL queue to me... A 
>> high water mark on my traffic shaped router informs me about my shaper 
>> setting (which I already know, after al I set it) but little about the 
>> capacity over the bottleneck link. And we are still talking about the easy 
>> egress direction, in the download direction Jeremy's question aplied is the 
>> achieved thoughput I measure limited by the link's capacity of are there 
>> simply not enoiugh packet available/sent to fill the pipe.
>> 
> 
> And yet it can still see the flow of data on it's ports.  The queue is
> irelevant to the measurement of data across a port.

I respectfully disagree, if say, my modem had a 4 GB queue I could 
theoretically burst ~4GB worth of data at line rate into that buffer without 
learning anything about the the modem-link capacity.


>  turn off the
> shaper and run anything.  run your speed test.  don't look at the
> speed test results, just use it to generate some traffic.  you'll find
> your peak and where you hit the buffers on the DSL modem by measuring
> on the interface and measuring latency.  

Peak of what? Exactly? The peak sending rate of my router is well 
known, its 1 Gbps gross ethernet rate...


> That speed test isn't giving
> you this data and more than Disney+, other than you get to pick when
> it runs.

Hrm, no we sre back at actually saturating the link, 


> 
>>> Highwater mark on our CPE, on our
>>> shaper, etc.  Modern services are very happy to burst traffic.
>> 
>>[SM] Yes, this is also one of the readons, why too-little-buffering 
>> is problematic, I like the Nichols/Jacobsen analogy of buffers as shiock 
>> (burst) absorbers.
>> 
>>> Nearly
>>> every customer we have will hit the top of their service place each
>>> day, even if only briefly and even if their average usage is quite
>>> low.  Customers on 600Mbps mmwave services have a usage charge that is
>>> flat lines and ~600Mbps blips.
>> 
>>[SM] Fully agree. most links are essentially idle most of the time, 
>> but that does not answer what instantaneous capacity is actually available, 
>> no?
> 
> yes, because most services burst.  That Roku Ultra or Apple TV is
> going to running a 'speed test' every time it goes to fill it's
> buffer.

[SM] not really, given enough capacity, typical streaming protocols 
will actually not hit the ceiling, at least the one's I look at every now and 
then tend to stay well below actual capacity of the link.

>  Windows and Apple updates are asking for everything.  Again,
> I'm measuring even the lowly grandma's house as consuming the entire
> connection for a few seconds before it sits idle for a minute.  That
> instantaneous capacity is getting used up so long as there is a
> device/connection on the network capable of using it up.

[SM] But my problem is that on variable rate links I want to measure 
the instantaneous capacity such that I can do adaptive admission control and 
avpid over filling my modem's DSL buffers (I wish they would do something like 
BQL, but alas they don't).


> 
>> 
>>> 
>>> "  [SM] No ISP I know of publishes which periods are low, mid, high
>>> congestion so end-users will need to make some assumptions here (e.g.
>>> by looking at per day load graphs of big traffic exchanges like DE-CIX
>>> here https://www.de-cix.net/en/locations/frankfurt/statistics )"
>>> 
>>> You read this wrong.  Consumer routers run their daily speeds tests in
>>> the middle of the night.
>> 
>>[SM] So on my turris omnia I run a speedtest roughly every 2 hours 
>> exactly so I get coverage through low and high demand epochs. The only 
>> consumer router I know that does repeated tests is the IQrouter, which as 
>> far as I know schedules them regularly so it can adjust the traffic shaper 
>> to still deliver acceptale responsiveness even during peak hour.
> 
> Consider this.   Customer under load, using their plan to the maximum,
> speed test fires up adding more constraint.  Speed test is a stress
> test, not a capacity test.

[SM] With competent AQM (like cake on ingress and egress configured for 
per-internal-IP isolation) I do not even notice whether a speedtes runs or not, 
and from the reported capacity I can estimate the concurrent load from other 
endhosts in my network.


>  Speed test cannot return actual capacity
> because it's being used by other services AND the rest of the internet
> is in the way of accuracy as well, unless of course 

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

[Jeremy Austin via Bloat]

On Mon, Mar 13, 2023 at 10:26 AM dan  wrote:


If you troubleshoot your ISP based on speed tests you will be chasing
your tail.  Meanwhile, that internet facing interface can see the true
numbers the entire time.  The consumer is pulling their full capacity
on almost all links routinely even if briefly and can be nudged into
pushing more a dozen ways (including a speed test).  The only thing
lacking is a latency measurement of some sort.  Preseem and Libreqos's
TCP measurements on the head end are awesome, but that's not available
on the subscriber's side but if it were, there's the full testing
suite.  how much peak data, what happened to latency.  If you could
get data from the ISP's head end to diff you'd have internet vs isp
latencies.'speed test' is a stress test or a burn in test in
effect.


I cannot upvote this enough. I call speed tests — and in fact any packet
injection doing more than a bare minimum probe — destructive testing, and
said as much to NTIA recently.

The *big problem* (emphasis mine) is that the recent BEAD NOFO, pumping
tens of billions of dollars into broadband, has *speedtests* as the "proof"
that an ISP is delivering.

It's one thing to solve this problem at the ISP and consumer level. It's
another to solve it at the political level. In this case, I think it's
incumbent on ISPs to atone for former sins — now that we know that speed
tests are not just bad but actively misleading, we need to provide real
tools and education.

Going back to my previous comment, and no disrespect meant to the CAKE
autorate detection: "How do we distinguish between constrained supply and
reduced demand *without injecting packets or layer violations*?"

-- 
--
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

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

[dan via Bloat]

On Mon, Mar 13, 2023 at 10:36 AM Sebastian Moeller  wrote:
>
> Hi Dan,
>
>
> > On Mar 13, 2023, at 17:12, dan  wrote:
> >...
> >
> > High water mark on their router.
>
> [SM] Nope, my router is connected to my (bridged) modem via gigabit 
> ethernet, with out a traffic shaper there is never going to be any noticeable 
> water mark on the router side... sure the modem will built up a queue, but 
> alas it does not expose the length of that DSL queue to me... A high water 
> mark on my traffic shaped router informs me about my shaper setting (which I 
> already know, after al I set it) but little about the capacity over the 
> bottleneck link. And we are still talking about the easy egress direction, in 
> the download direction Jeremy's question aplied is the achieved thoughput I 
> measure limited by the link's capacity of are there simply not enoiugh packet 
> available/sent to fill the pipe.
>

And yet it can still see the flow of data on it's ports.  The queue is
irelevant to the measurement of data across a port.  turn off the
shaper and run anything.  run your speed test.  don't look at the
speed test results, just use it to generate some traffic.  you'll find
your peak and where you hit the buffers on the DSL modem by measuring
on the interface and measuring latency.  That speed test isn't giving
you this data and more than Disney+, other than you get to pick when
it runs.

> > Highwater mark on our CPE, on our
> > shaper, etc.  Modern services are very happy to burst traffic.
>
> [SM] Yes, this is also one of the readons, why too-little-buffering 
> is problematic, I like the Nichols/Jacobsen analogy of buffers as shiock 
> (burst) absorbers.
>
> >  Nearly
> > every customer we have will hit the top of their service place each
> > day, even if only briefly and even if their average usage is quite
> > low.  Customers on 600Mbps mmwave services have a usage charge that is
> > flat lines and ~600Mbps blips.
>
> [SM] Fully agree. most links are essentially idle most of the time, 
> but that does not answer what instantaneous capacity is actually available, 
> no?

yes, because most services burst.  That Roku Ultra or Apple TV is
going to running a 'speed test' every time it goes to fill it's
buffer.  Windows and Apple updates are asking for everything.  Again,
I'm measuring even the lowly grandma's house as consuming the entire
connection for a few seconds before it sits idle for a minute.  That
instantaneous capacity is getting used up so long as there is a
device/connection on the network capable of using it up.

>
> >
> > "  [SM] No ISP I know of publishes which periods are low, mid, high
> > congestion so end-users will need to make some assumptions here (e.g.
> > by looking at per day load graphs of big traffic exchanges like DE-CIX
> > here https://www.de-cix.net/en/locations/frankfurt/statistics )"
> >
> > You read this wrong.  Consumer routers run their daily speeds tests in
> > the middle of the night.
>
> [SM] So on my turris omnia I run a speedtest roughly every 2 hours 
> exactly so I get coverage through low and high demand epochs. The only 
> consumer router I know that does repeated tests is the IQrouter, which as far 
> as I know schedules them regularly so it can adjust the traffic shaper to 
> still deliver acceptale responsiveness even during peak hour.

Consider this.   Customer under load, using their plan to the maximum,
speed test fires up adding more constraint.  Speed test is a stress
test, not a capacity test.  Speed test cannot return actual capacity
because it's being used by other services AND the rest of the internet
is in the way of accuracy as well, unless of course you prioritize the
speed test and then you cause an effective outage or you're running a
speed test on-net which isn't an 'internet' test, it's a network test.
Guess what the only way to get an actual measure of the capacity is?
my way.  measure what's passing the interface and measure what happens
to a reliable latency test during that time.

>
>
> >  Eero at 3am for example.  Netgear 230-430am.
>
> [SM] That sounds"specisl" not a useless daa point per se, but of 
> limited utility during normal usage times.

In practical terms, useless.  Like measuring how freeway congestion
affects commutes at 3am.

>
> > THAT is a bad measurement of the experience the consumer will have.
>
> [SM] Sure, but it still gives a usable reference for "what is the 
> best my ISP actually delivers" if if the odds are stacked in his direction.

ehh.. what the ISP could deliver if all other considerations are
removed.  I mean, it'd be a synthetic test in any other scenario and
the only reason it's not is because it's on real hardware.  I don't
have a single subscriber on network that can't get 2-3x their plan
speed at 3am if I opened up their shaper.  Very narrow use case here
from a consumer point of view.   Eero runs speed tests at 3am every
single day on a few hundred subs on my 

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

[Sebastian Moeller via Bloat]

Hi Dan,


> On Mar 13, 2023, at 17:12, dan  wrote:
> 
> " [SM] For a home link that means you need to measure on the router,
> as end-hosts will only ever see the fraction of traffic they
> sink/source themselves..."
> &
> [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.
> 
> High water mark on their router.  

[SM] Nope, my router is connected to my (bridged) modem via gigabit 
ethernet, with out a traffic shaper there is never going to be any noticeable 
water mark on the router side... sure the modem will built up a queue, but alas 
it does not expose the length of that DSL queue to me... A high water mark on 
my traffic shaped router informs me about my shaper setting (which I already 
know, after al I set it) but little about the capacity over the bottleneck 
link. And we are still talking about the easy egress direction, in the download 
direction Jeremy's question aplied is the achieved thoughput I measure limited 
by the link's capacity of are there simply not enoiugh packet available/sent to 
fill the pipe.

> Highwater mark on our CPE, on our
> shaper, etc.  Modern services are very happy to burst traffic.

[SM] Yes, this is also one of the readons, why too-little-buffering is 
problematic, I like the Nichols/Jacobsen analogy of buffers as shiock (burst) 
absorbers.

>  Nearly
> every customer we have will hit the top of their service place each
> day, even if only briefly and even if their average usage is quite
> low.  Customers on 600Mbps mmwave services have a usage charge that is
> flat lines and ~600Mbps blips.

[SM] Fully agree. most links are essentially idle most of the time, but 
that does not answer what instantaneous capacity is actually available, no?

> 
> "  [SM] No ISP I know of publishes which periods are low, mid, high
> congestion so end-users will need to make some assumptions here (e.g.
> by looking at per day load graphs of big traffic exchanges like DE-CIX
> here https://www.de-cix.net/en/locations/frankfurt/statistics )"
> 
> You read this wrong.  Consumer routers run their daily speeds tests in
> the middle of the night.

[SM] So on my turris omnia I run a speedtest roughly every 2 hours 
exactly so I get coverage through low and high demand epochs. The only consumer 
router I know that does repeated tests is the IQrouter, which as far as I know 
schedules them regularly so it can adjust the traffic shaper to still deliver 
acceptale responsiveness even during peak hour.


>  Eero at 3am for example.  Netgear 230-430am.

[SM] That sounds"specisl" not a useless daa point per se, but of 
limited utility during normal usage times.

> THAT is a bad measurement of the experience the consumer will have.

[SM] Sure, but it still gives a usable reference for "what is the best 
my ISP actually delivers" if if the odds are stacked in his direction.

> It's essentially useless data for the consumer unless they are
> scheduling their downloads at 3am.  Only a speed test during use hours
> is useful and that's also basically destructive unless a shaper makes
> sure it isn't.
> 
> re per segment latency tests " [SM] Well is it really useless? If I
> know the to be expected latency-under-load increase I can eye-ball
> e.h. how far away a server I can still interact with in a "snappy"
> way."
> 
> Yes it's completely useless to the customer.  only their service
> latency matters.

[SM] There is no single "service latency" it really depends on he 
specific network paths to the remote end and back. Unless you are talking about 
the latency over the access link only tere we have a single number but one of 
limited utility.


>  My (ISP) latency from hop 2 to 3 on the network has
> zero value to them.  only the aggregate.  per segment latency testing
> is ONLY valuable to the service providers for us to troubleshoot,
> repair, and upgrade.  Even if a consumer does a traceroute and get's
> that 'one way' testing, it's irrelevant as they can't do anything
> about latency at hop 8 etc, and often they actually don't know which
> hops are which because they'll hidden in a tunnel/MPLS/etc.

[SM] Yes, end-users can do little, but not nothing, e.g. one can often 
work-around shitty peering by using a VPN to route one's packets into an AS 
that is both well connected with one's ISP as well as with one's remote ASs. 
And I accept your point of one-way testing, getting a remote site at the ight 
location to do e.g. reverse tracerputes mtrs is tricky (sometimes RIPE ATLAS 
can help) to impossible (like my ISP that does not offer even simple 
lookingglas servers at all)).


> 
> 
> 
> On Mon, Mar 13, 2023 at 9:50 AM Sebastian Moeller  wrote:
>> 
>> Hi Jeremy,
>> 
>>> On Mar 13, 2023, at 16:08, Jeremy Austin  wrote:
>>> 
>>> 
>>> 
>>> On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink 
>>>  wrote:
>>> 

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

[Sebastian Moeller via Bloat]

Hi Dave,

> On Mar 13, 2023, at 17:06, Dave Taht  wrote:
> 
> On Mon, Mar 13, 2023 at 8:50 AM Sebastian Moeller via Bloat
>  wrote:
>> 
>> Hi Jeremy,
>> 
>>> On Mar 13, 2023, at 16:08, Jeremy Austin  wrote:
>>> 
>>> 
>>> 
>>> On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink 
>>>  wrote:
>>> Hi Dan,
>>> 
>>> 
 On Jan 9, 2023, at 20:56, dan via Rpm  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: 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

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

[dan via Bloat]

" [SM] For a home link that means you need to measure on the router,
as end-hosts will only ever see the fraction of traffic they
sink/source themselves..."
&
 [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.

High water mark on their router.   Highwater mark on our CPE, on our
shaper, etc.  Modern services are very happy to burst traffic.  Nearly
every customer we have will hit the top of their service place each
day, even if only briefly and even if their average usage is quite
low.  Customers on 600Mbps mmwave services have a usage charge that is
flat lines and ~600Mbps blips.

"  [SM] No ISP I know of publishes which periods are low, mid, high
congestion so end-users will need to make some assumptions here (e.g.
by looking at per day load graphs of big traffic exchanges like DE-CIX
here https://www.de-cix.net/en/locations/frankfurt/statistics )"

You read this wrong.  Consumer routers run their daily speeds tests in
the middle of the night.  Eero at 3am for example.  Netgear 230-430am.
THAT is a bad measurement of the experience the consumer will have.
It's essentially useless data for the consumer unless they are
scheduling their downloads at 3am.  Only a speed test during use hours
is useful and that's also basically destructive unless a shaper makes
sure it isn't.

re per segment latency tests " [SM] Well is it really useless? If I
know the to be expected latency-under-load increase I can eye-ball
e.h. how far away a server I can still interact with in a "snappy"
way."

Yes it's completely useless to the customer.  only their service
latency matters.  My (ISP) latency from hop 2 to 3 on the network has
zero value to them.  only the aggregate.  per segment latency testing
is ONLY valuable to the service providers for us to troubleshoot,
repair, and upgrade.  Even if a consumer does a traceroute and get's
that 'one way' testing, it's irrelevant as they can't do anything
about latency at hop 8 etc, and often they actually don't know which
hops are which because they'll hidden in a tunnel/MPLS/etc.



On Mon, Mar 13, 2023 at 9:50 AM Sebastian Moeller  wrote:
>
> Hi Jeremy,
>
> > On Mar 13, 2023, at 16:08, Jeremy Austin  wrote:
> >
> >
> >
> > On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink 
> >  wrote:
> > Hi Dan,
> >
> >
> > > On Jan 9, 2023, at 20:56, dan via Rpm  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 ;)
>
> 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

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

[Dave Taht via Bloat]

On Mon, Mar 13, 2023 at 8:50 AM Sebastian Moeller via Bloat
 wrote:
>
> Hi Jeremy,
>
> > On Mar 13, 2023, at 16:08, Jeremy Austin  wrote:
> >
> >
> >
> > On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink 
> >  wrote:
> > Hi Dan,
> >
> >
> > > On Jan 9, 2023, at 20:56, dan via Rpm  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

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

[Sebastian Moeller via Bloat]

Hi Jeremy,

> On Mar 13, 2023, at 16:08, Jeremy Austin  wrote:
> 
> 
> 
> On Mon, Mar 13, 2023 at 3:02 AM Sebastian Moeller via Starlink 
>  wrote:
> Hi Dan,
> 
> 
> > On Jan 9, 2023, at 20:56, dan via Rpm  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 ;)

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

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

[Jeremy Austin via Bloat]

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  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.

A question I commonly ask network engineers or academics is "How can I
accurately distinguish a constraint in supply from a reduction in demand?"

-- 
--
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