[LibreQoS] summarizing the bitag latency report?

[LibreQoS] summarizing the bitag latency report?

[Dave Taht]

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

Re: [LibreQoS] summarizing the bitag latency report?

[dan]

[-- Attachment #1: Type: text/plain, Size: 2289 bytes --]

I used to run a pizza franchise so I go back to that a lot haha.  Latency
(when talking to an end user) is the time between when you order your pizza
and it shows up at your door.  The streets to your house are the internet.
If the streets are clear and the weather's good and the pizza store is
running smoothly, it'll arrive when expected.  If the roads are terrible,
or traffic is heavy it'll be late.   If there roads are packed or
congested, or if they are in bad shape, or too small, or the pizza place is
just really far away, then the pizza is going to take more time to get
there.  The pizza delivery guy takes more time to get to their first
delivery, and then more time to get to you, then more time to get back.

I also lean on this to describe internet 'speed' as 'capacity' and say it's
a misnomer.  It doesn't matter how much pizza you order, the 'speed' is how
quickly they process your order and get it to you which is heavily
dependent on the latency details.  If you order more pizza, it takes a
bigger bag and then eventually a bigger vehicle but since the pizza guy
doesn't have a semi, he has to take multiple trips if you order too much.
Speed is the capacity of his car.  Mbps is pizza pies per car.

Am I getting into the weeds to much here lol

On Fri, Nov 11, 2022 at 4:16 PM Dave Taht via LibreQoS <
libreqos@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
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

[-- Attachment #2: Type: text/html, Size: 3079 bytes --]

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

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

My lightning round take:
Politically: it's complicated
Practically: this ain't rocket-science, just deploy competent traffic shaping, competent scheduling (preferably FQ) and competent AQM.

Then you are in a fine spot to wait until the political dust settles.


I admit only having browsed the report and that some time ago... but a single paragraph will always be far from the text.

On 12 November 2022 00:16:43 CET, Dave Taht via Bloat <bloat@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@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/bloat

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 2021 bytes --]

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

[Sebastian Moeller]

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@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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

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

[Herbert Wolverson]

[-- Attachment #1: Type: text/plain, Size: 6623 bytes --]

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

(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@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@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@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

[-- Attachment #2: Type: text/html, Size: 8303 bytes --]

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

[Dave Taht]

On Sat, Nov 12, 2022 at 6:38 AM Herbert Wolverson via LibreQoS
<libreqos@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@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@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@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>>
>> _______________________________________________
>> LibreQoS mailing list
>> LibreQoS@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/libreqos
>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@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

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

[Herbert Wolverson]

[-- Attachment #1: Type: text/plain, Size: 8524 bytes --]

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

And that's why I drive a beaten up 2012 VW beetle. :-)


On Sat, Nov 12, 2022 at 9:00 AM Dave Taht <dave.taht@gmail.com> wrote:

> On Sat, Nov 12, 2022 at 6:38 AM Herbert Wolverson via LibreQoS
> <libreqos@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@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@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@lists.bufferbloat.net
> >> > https://lists.bufferbloat.net/listinfo/bloat
> >>
> >> _______________________________________________
> >> LibreQoS mailing list
> >> LibreQoS@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/libreqos
> >
> > _______________________________________________
> > LibreQoS mailing list
> > LibreQoS@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
>

[-- Attachment #2: Type: text/html, Size: 10868 bytes --]

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

[Jonathan Morton]

> On 12 Nov, 2022, at 1:16 am, Dave Taht via Bloat <bloat@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

I can get it down to *three* paragraphs while conveying the essentials:

The quality of an Internet path is measured by three factors:  throughput, latency, and packet loss.  Of these three measures, throughput is typically the least important for application performance, so long as a modest threshold is met - for example the US "broadband" definition of 25Mbps.  Packet loss is interpreted by computers as indicating congestion, which causes them to slow down network transfers unnecessarily; it also causes objectionable glitches in video and audio streams, and should thus be minimised.  Latency is the primary driver of perceived Internet quality for most applications in most circumstances.

Latency can be divided into "inherent" and "induced" components.  Inherent latency is simply the time it takes for a packet to traverse all the links in the path, outward and return.  Induced latency is the additional time spent deciding which of several links to direct the packet to, waiting for a shared medium, and/or stuck in a queue full of other packets going the same way.  Most applications are able to adapt to reasonable levels of inherent latency, but induced latency is much more difficult to manage due to its variability.  There are several ways to reduce induced latency without impairing throughput or packet loss, chiefly AQM and Fair Queuing, which can fruitfully be combined as in SQM.  SQM is widely, but not yet universally, deployed on the Internet, and works very well.

AQM is the practice of observing how big queues get, and signalling congestion in a deliberate way based on those observations.  ECN can be used to perform that signalling without any packet loss.  On traffic that doesn't support ECN, deliberately dropping packets in a controlled way is necessary.  These congestion signals cause applications to reduce their load on the network to match available capacity, and thereby reduce queuing.  Fair Queuing works orthogonally to this by treating each flow of traffic individually, so that one flow inducing heavy delays in its queue doesn't affect another flow which is lighter.  This makes it easy for very different applications to coexist on the same path, which often happens when there are several users in the same household or office.  SQM uses Fair Queuing, and also applies a separate AQM to each flow, so that congestion signals are directed solely to heavy flows.

If you really need it to be only *one* paragraph, the middle one might be the most essential.

> Also QoS, vs QoE. Try to imagine explaining the need to a CFO, or
> congresscritter. Feel free to take more than a paragraph.

QoS is Quality of Service.  QoE is Quality of Experience.  The two are very different concepts.

To illustrate this, consider a railway manager tasked with modernising his line by replacing steam trains with diesel ones.  He's a modern businessman keen to apply modern thinking to this task, so he delegates some underlings to gather data about the expected traffic flows on the line, as well as the types of train that are available for hire.

In the answers that come back, he focuses on two key figures:  the line carries 1000 passengers per day, and each carriage can seat 50 passengers.  Simple arithmetic shows that this demand can be met by running 20 carriages per day, but the manager rounds this up to 24 carriages to allow some margin for error.  After all, with the tremendous efficiency of diesel traction (compared to steam traction), he can afford to be a little generous.

One of the trains on offer is a 2000hp locomotive hauling 12 carriages - a very impressive sight, to be sure.  "Splendid," he thinks, "we can run that one twice a day, and that will meet demand with some margin to spare."  So that's what he does; once in the morning, and once in the evening.  The timetables are very easy to publish, too.

In the first month of operation, all of these trains turn up on time and with the correct number of carriages, and there are no breakdowns or accidents.  The specified capacity is therefore supplied.  This is an excellent "Quality of Service".

Yet the complaints start rolling in almost immediately.  Passengers who turn up wanting to travel at any other time than the two trains serve find themselves with an exceptionally long wait ahead of them.  Local police even report an increase in vagrancy complaints, due to passengers missing the evening train and having to sleep in the waiting rooms overnight.  This represents a very poor "Quality of Experience".

Learning from this misadventure, the manager goes back to his data and notes that one-carriage "railcars" are also available for hire.  For the next month's timetable, instead of the two 12-carriage trains each day, he will run one of these railcars every hour.  These will provide exactly the same seating capacity over the course of the day, but the waiting time will now be limited to a much more palatable duration.  (In Internet terms, he's optimised squarely for latency.)

Still the complaints come in - but now from different sources.  No longer are passengers waiting for hours and sleeping overnight in stations.  Instead, rush-hour commuters who had previously found the 12-carriage trains convenient are finding the railcars too crowded.  Even with over a hundred passengers crammed in like sardines, many more are left on the platforms and arrive at work late - or worse, come home to a cold dinner and an annoyed wife.  Simply put, demand is not evenly distributed through the day, but concentrated on particular times; at other times, the railcars are sufficient for the relatively small number of passengers, or even run almost empty.

So again, even though the "Quality of Service" is provided just as specified, the "Quality of Experience" for the passengers is very poor.  Indeed the overcrowding leads to some railcars being delayed, due to the difficulty of getting everyone in and out of the doors, and the conductors have great difficulty in checking tickets, hence a noticeable reduction in fare revenue.

Things improve markedly when the manager brings in 6-carriage express trains for the morning, lunchtime, and evening commuters, and continues to run the railcars at hourly intervals in between them, except for the small hours when some trains are removed due to minimal demand.  Now there are enough carriages in the rush-hour trains to satisfy commuters, and there are still trains running at other times so that nobody needs to wait particularly long for one.

In fact, demand increases substantially due to the good "Quality of Experience" that this new timetable provides, such that by the end of the first year, many of the railcars are upgraded to 3-carriage trains, and the commuter expresses are lengthened to 8 carriages.  Fare revenue is more than doubled.  The modernisation effort is a success.

The lesson here is that QoS is merely the means by which you may attempt to achieve high QoE.  Meeting QoS does not guarantee QoE.  Only if the QoS is designed around the factors that genuinely influence QoE will you succeed.  Unfortunately, many QoS schemes are inadequate for the needs of actual Internet users; this is because their designers have not kept up with the appropriate QoE factors.

 - Jonathan Morton