Hi Dan,
> On Mar 13, 2023, at 17:12, dan <danden...@gmail.com> 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 <moell...@gmx.de> 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 ;)
>>
>> 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
