[LibreQoS] [Bloat] summarizing the bitag latency report?

Dave Taht dave.taht at gmail.com
Sat Nov 12 10:00:25 EST 2022


On Sat, Nov 12, 2022 at 6:38 AM Herbert Wolverson via LibreQoS
<libreqos at lists.bufferbloat.net> wrote:
>
> > If I had more time, I would have written a short letter - Blaise Pascal
>
> >>  It's not a big truck. It's a series of tubes. And if you don't understand, those tubes can be filled and if they are filled, when you put your message in, it gets in line and it's going to be delayed by anyone that puts into that tube enormous amounts of material, enormous amounts of material. - Sen Ted R. Stevens
>
> Summarizing is tough. As Sebastian pointed out, you almost need a summary per
> target audience. Those two quotes highlight the problem: to the domain expert,
> it's almost impossible to summarize an issue because you'll be jumped on by
> other domain experts - and, knowing all about the issue, it feels dangerous to
> omit the details. Conversely, if an expert briefs some Senate aides - who in
> turn brief a non-technical senator - you can end up with a widely mocked speech.
> If you tone down the mockery, it's not hard to see how Sen. Stevens came
> to his wording - pipes, capacity, delays, queues; it does start to sound like a
> series of tubes.
>
> One of my coworkers likens it to the water system:
>
> The city has plenty of water, with big pipes and good pressure going to
> everyone's house. Your house's feed to the water main limits how much
> water you can get at one time - that's your download speed. Plumbing
> design, pipe and valve quality all affect the delay between turning your
> faucet on and nice cold water coming out. That's your latency. You need
> to optimize both.
>
> I tend to find that customers like car analogies:
>
> On a perfect racetrack, a Ferrari will reach the end before a Honda Civic.
> The Ferrari has more power, and is designed for faster speeds. On a
> public road network, the Ferrari still outpaces the Civic on fast, open roads -
> but it only takes one traffic jam, one poorly designed intersection or
> stoplight - for both vehicles to be seriously delayed. Ferrari's have a
> very high speed (your download speed), and multi-lane highways have
> great capacity (high speed networks) - but a single congested traffic
> ramp (a buffer between connections) can ruin the overall travel experience
> by adding long delays (latency) while cars merge onto different roads.
> Quality of Experience optimizes the buffers between roads, providing
> a smoother experience overall.

Also ferrari's are uncomfortable as hell in traffic. You can't see
over the windshield, the seating position requires a massage therapist
at the end of the ride, and you're paranoid as hell someone will hit
you, and if the motor gives out it's a 2k repair bill
and weeks of downtime before you get it back.

Then, there's the gas mileage, or lack thereof.

Another analogy we've used is the dragster design for many internet
benchmarks. You can only go really, really fast, in one direction,
without the ability to steer, and tons of smoke and noise.

A third car anology is the classic jet engine strapped to the back of
a vw beetle.

You need good steering, brakes, suspension, in order to build a balanced ride.


>
> (Both could be shortened, but analogy is frequently the way to reach
> non-technical users)
>
>
>
> On Sat, Nov 12, 2022 at 7:15 AM Sebastian Moeller via LibreQoS <libreqos at lists.bufferbloat.net> wrote:
>>
>> Hi Dave,
>>
>>
>> so I think you have three audiences that should learn about this:
>> a) end-users (my hot-take was tailored for end-users)
>> b) politicians
>> c) industry people (C-suite members of ISPs*)
>>
>>
>> I think you need three different one paragraph summaries tailored to each groups focus.
>>
>>
>> a) end users
>> I would stress the "you can improve your link today with little work" to make it fit for video conferencing "under working conditions".
>> I would not wade into the swamp that is "gaming" any deeper than necessary (so have a sentence along the lines of "these described methods will obviously also help other
>> latency-sensitive applications like gaming"). Why avoid gaming? Gamers are quite opinionated and take promises often literally, hence are easy to disappoint so better under-promise, but over-deliver.
>>
>> b) politicians
>> Here I would emphasize that while fiber-to-everyone is the ultimate goal getting latency under control will result in a noticeable "better" (because subjectively more responsive) internet experience for those that will have to wait longer for fiber. I simply assume that fiber-everywhere is the goal across the aisle in the US, at least over here all major parties agree about the ultimate goal and just disagree how to get there, with the party in opposition magically always seeing more urgency ;).
>> So push this as a relative low-effort/low-cost method to noticeably improve the internet experience for the electorate...
>>
>> c) industry people
>> This has two groups, those that run large internal networks and ISPs. I think for the first group the arguments for a) and b) could be re-used (b) reframed as low-cost ways to get more mileage out of the existing network infrastructure with a few targeted replacements/upgrades/configuration changes).
>> For the second group I am a bit at a loss, as the arguments a) and b) MIGHT not be all that attractive for someone selling internet-access priced by "top-speed", making lower speeds more enjoyable/usable seems a bit counter productive... One pitch could be a  marketable advantage over the competition, but that requires actual competition.
>> Not sure how to give the enlightened ones arguments to convince their peers.
>>
>> Regards
>>         Sebastian
>>
>>
>>
>> *) some are enlightened already
>>
>>
>> P.S.: QoS, vs QoE
>> Cause and effect, means and end... What the users will evaluate are their experiences; traditional QoS can be a means to improve that experience, with a hitherto often neglected aspect being latency-under-load which above a bare minimum access rate seems to correlate stronger with user experience than top-speeds.
>>
>> To convince CFO, or congresscritters I would think the best would be a simple mobile demonstration platform... together with argument b) above
>>
>>
>> > On Nov 12, 2022, at 00:16, Dave Taht via Bloat <bloat at lists.bufferbloat.net> wrote:
>> >
>> > If you were to try to summarize this *in a paragraph*, what would you say?
>> >
>> > https://www.bitag.org/documents/BITAG_latency_explained.pdf
>> >
>> > (yes, I helped write this, but squeezing it down to less than 3 pages
>> > is beyond my capabilities, much less a paragraph, and by the time we
>> > hit the recommendations section, things had got too political to make
>> > sane recommendations)
>> >
>> > Also QoS, vs QoE. Try to imagine explaining the need to a CFO, or
>> > congresscritter. Feel free to take more than a paragraph.
>> >
>> >
>> > --
>> > This song goes out to all the folk that thought Stadia would work:
>> > https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
>> > Dave Täht CEO, TekLibre, LLC
>> > _______________________________________________
>> > Bloat mailing list
>> > Bloat at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>>
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos



-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC


More information about the LibreQoS mailing list