[Bloat] summarizing the bitag latency report?

[Bloat] 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: [Bloat] [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: [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: [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: [Bloat] summarizing the bitag latency report?

[Dave Collier-Brown]

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

The paper talks about mechanism, not effect. We need to refactor before we can summarize

I've pitched it to my colleagues by saying what problem it causes us, rather than how it does it.

Latency pisses Joyce off.

When we fetch a page, parts of it appear first, then others, then banner ads, and then some of the images, all while we're trying to read it in order. My wife hates that.  Oh, and we have jitter and dropouts in video meetings, too.

We've bought tons of bandwidth, but "end-user experience" isn't improving.  That's because we've been trying to improve our performance by improving something that's easy to buy, but only helps a little bit.

Then I described what we did about it, and recommended the BITAG paper for an understanding, and a new router for a local solution.


Once I'd done that refactoring, I could sit down and say that the summation is

  1.  working latency makes its victims angry at the internet
  2.  we've been doing something to fix it that only helps a little bit

and the reader immediately responds with the solution: "well, don't do that!".

You have to build from there to the full problem, the politics and the economics. Then you can look at the solutions, and narrow them down until you can conclude with "do this instead"

--dave



On 11/11/22 18:16, Dave Taht via Bloat 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.




--
David Collier-Brown,         | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
dave.collier-brown@indexexchange.com<mailto:dave.collier-brown@indexexchange.com> |              -- Mark Twain


CONFIDENTIALITY NOTICE AND DISCLAIMER : This telecommunication, including any and all attachments, contains confidential information intended only for the person(s) to whom it is addressed. Any dissemination, distribution, copying or disclosure is strictly prohibited and is not a waiver of confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and delete the message from your inbox and deleted items folders. This telecommunication does not constitute an express or implied agreement to conduct transactions by electronic means, nor does it constitute a contract offer, a contract amendment or an acceptance of a contract offer. Contract terms contained in this telecommunication are subject to legal review and the completion of formal documentation and are not binding until same is confirmed in writing and has been signed by an authorized signatory.

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

Re: [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