From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from masada.superduper.net (masada.superduper.net [85.119.82.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 2D6EF3B2A4 for ; Thu, 25 Feb 2021 15:52:16 -0500 (EST) Received: from 52-119-118-48.public.monkeybrains.net ([52.119.118.48] helo=[192.168.131.74]) by masada.superduper.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1lFNcH-0000Bn-Fg; Thu, 25 Feb 2021 20:52:12 +0000 From: Simon Barber To: Sina Khanifar CC: Mikael Abrahamsson , , bloat Date: Thu, 25 Feb 2021 12:52:08 -0800 Message-ID: <177daf690c0.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> In-Reply-To: References: <177d80af608.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <177d9698ff0.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <177d9776300.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <2CE9BEA3-58B5-44CB-98C0-C1B54FA5D348@superduper.net> User-Agent: AquaMail/1.28.1-1760 (build: 102800003) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------177daf6923932f727a93e71603" X-Spam-Score: -2.9 (--) Subject: Re: [Bloat] Updated Bufferbloat Test X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2021 20:52:16 -0000 This is a multi-part message in MIME format. ------------177daf6923932f727a93e71603 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Yes, if you want to know how well real time communication is going to work, something close to peak or 95%ile of total latency is the relevant measure. Showing less data and keeping it simple is ideal, so users don't get confused. Simon On February 25, 2021 12:11:02 PM Sina Khanifar wrote: > Thanks for the kind words, Simon! > >> Since you are measuring buffer bloat - how much latency *can* be caused by >> the excessive buffering, expressing the jitter number in terms of 95%ile >> would be appropriate - as that’s closely related to how large the excessive >> buffer is. The average jitter is more related to how the competing TCP >> streams have some gaps due to congestion control and these gaps can >> temporarily lower the buffer occupancy and result in a lower average jitter >> number. > > I'm thinking that we might even remove jitter altogether from the UI, > and instead just show 95%ile latency. 95%ile latency and 95%ile jitter > should be equivalent, but 95% latency is really the more meaningful > measure for real-time communications, it feels like? > > On Thu, Feb 25, 2021 at 11:57 AM Simon Barber wrote: >> >> Hi Sina, >> >> That sounds great, and I understand the desire to separate the fixed >> component of latency and the buffer bloat / variable part. Messaging that >> in a way that accurately conveys the end user impact and the impact due to >> unmitigated buffers while being easy to understand is tricky. >> >> Since you are measuring buffer bloat - how much latency *can* be caused by >> the excessive buffering, expressing the jitter number in terms of 95%ile >> would be appropriate - as that’s closely related to how large the excessive >> buffer is. The average jitter is more related to how the competing TCP >> streams have some gaps due to congestion control and these gaps can >> temporarily lower the buffer occupancy and result in a lower average jitter >> number. >> >> Really appreciate this work, and the interface and ‘latency first’ nature >> of this test. It’s a great contribution, and will hopefully help drive ISPs >> to reducing their bloat, helping everyone. >> >> Simon >> >> >> > On Feb 25, 2021, at 11:47 AM, Sina Khanifar wrote: >> > >> >> So perhaps this can feed into the rating system, total latency < 50mS is >> an A, < 150mS is a B, 600mS is a C or something like that. >> > >> > The "grade" we give is purely a measure of bufferbloat. If you start >> > with a latency of 500 ms on your connection, it wouldn't be fair for >> > us to give you an F grade even if there is no increase in latency due >> > to bufferbloat. >> > >> > This is why we added the "Real-World Impact" table below the grade - >> > in many cases people may start with a connection that is already >> > problematic for video conferencing, VoIP, and gaming. >> > >> > I think we're going to change the conditions on that table to have >> > high 95%ile latency trigger the degraded performance shield warnings. >> > In the future it might be neat for us to move to grades on the table >> > as well. >> > >> > >> > On Thu, Feb 25, 2021 at 5:53 AM Simon Barber wrote: >> >> >> >> So perhaps this can feed into the rating system, total latency < 50mS is >> an A, < 150mS is a B, 600mS is a C or something like that. >> >> >> >> Simon >> >> >> >> On February 25, 2021 5:49:26 AM Mikael Abrahamsson wrote: >> >> >> >>> On Thu, 25 Feb 2021, Simon Barber wrote: >> >>> >> >>>> The ITU say voice should be <150mS, however in the real world people are >> >>>> a lot more tolerant. A GSM -> GSM phone call is ~350mS, and very few >> >>>> people complain about that. That said the quality of the conversation is >> >>>> affected, and staying under 150mS is better for a fast free flowing >> >>>> conversation. Most people won't have a problem at 600mS and will have a >> >>>> problem at 1000mS. That is for a 2 party voice call. A large group >> >>>> presentation over video can tolerate more, but may have issues with >> >>>> talking over when switching from presenter to questioner for example. >> >>> >> >>> >> >>> I worked at a phone company 10+ years ago. We had some equipment that >> >>> internally was ATM based and each "hop" added 7ms. This in combination >> >>> with IP based telephony at the end points that added 40ms one-way per >> >>> end-point (PDV buffer) caused people to complain when RTT started creeping >> >>> up to 300-400ms. This was for PSTN calls. >> >>> >> >>> Yes, people might have more tolerance with mobile phone calls because they >> >>> have lower expectations when out and about, but my experience is that >> >>> people will definitely notice 300-400ms RTT but they might not get upset >> >>> enough to open a support ticket until 600ms or more. >> >>> >> >>> -- >> >>> Mikael Abrahamsson email: swmike@swm.pp.se >> >> >> >> >> ------------177daf6923932f727a93e71603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, if you want to know how well real time communication= is going to work, something close to peak or 95%ile of total latency is th= e relevant measure.

Show= ing less data and keeping it simple is ideal, so users don't get confused.<= /div>

Simon

On February 25, 2021 12:11:02 PM Sina Khanifar <sina@w= aveform.com> wrote:

Thanks for the kind words, Simon!

Since you are measuring buffer bloat - how much latency *= can* be caused by the excessive buffering, expressing the jitter number in = terms of 95%ile would be appropriate - as that=E2=80=99s closely related to= how large the excessive buffer is. The average jitter is more related to h= ow the competing TCP streams have some gaps due to congestion control and t= hese gaps can temporarily lower the buffer occupancy and result in a lower = average jitter number.

I'm thinking that we might even remove jitter altogether = from the UI,
and instead just show 95%ile latency. 95%ile latency and = 95%ile jitter
should be equivalent, but 95% latency is really the more = meaningful
measure for real-time communications, it feels like?

On Thu, Feb 25, 2021 at 11:57 AM Simon Barber <simon@s= uperduper.net> wrote:

Hi Sina,

That sounds great, and I understand the desire to separat= e the fixed component of latency and the buffer bloat / variable part. Mess= aging that in a way that accurately conveys the end user impact and the imp= act due to unmitigated buffers while being easy to understand is tricky.

Since you are measuring buffer bloat - how much latency *= can* be caused by the excessive buffering, expressing the jitter number in = terms of 95%ile would be appropriate - as that=E2=80=99s closely related to= how large the excessive buffer is. The average jitter is more related to h= ow the competing TCP streams have some gaps due to congestion control and t= hese gaps can temporarily lower the buffer occupancy and result in a lower = average jitter number.

Really appreciate this work, and the interface and =E2=80= =98latency first=E2=80=99 nature of this test. It=E2=80=99s a great contrib= ution, and will hopefully help drive ISPs to reducing their bloat, helping = everyone.

Simon


On Feb 25, 2021, at 11:47 AM, Sina Khanifar <sina@wave= form.com> wrote:

So perhaps this can feed into the rating system, total la= tency < 50mS is an A, < 150mS is a B, 600mS is a C or something like = that.

The "grade" we give is purely a measure of bufferbloat. I= f you start
with a latency of 500 ms on your connection, it wouldn't = be fair for
us to give you an F grade even if there is no increase in= latency due
to bufferbloat.

This is why we added the "Real-World Impact" table below = the grade -
in many cases people may start with a connection that is = already
problematic for video conferencing, VoIP, and gaming.

I think we're going to change the conditions on that tabl= e to have
high 95%ile latency trigger the degraded performance shie= ld warnings.
In the future it might be neat for us to move to grades o= n the table
as well.


On Thu, Feb 25, 2021 at 5:53 AM Simon Barber <simon@su= perduper.net> wrote:

So perhaps this can feed into the rating system, total la= tency < 50mS is an A, < 150mS is a B, 600mS is a C or something like = that.

Simon

On February 25, 2021 5:49:26 AM Mikael Abrahamsson <sw= mike@swm.pp.se> wrote:

On Thu, 25 Feb 2021, Simon Barber wrote:

The ITU say voice should be <150mS, however in the rea= l world people are
a lot more tolerant. A GSM -> GSM phone call is ~350mS= , and very few
people complain about that. That said the quality of the = conversation is
affected, and staying under 150mS is better for a fast fr= ee flowing
conversation. Most people won't have a problem at 600mS a= nd will have a
problem at 1000mS. That is for a 2 party voice call. A la= rge group
presentation over video can tolerate more, but may have i= ssues with
talking over when switching from presenter to questioner = for example.


I worked at a phone company 10+ years ago. We had some eq= uipment that
internally was ATM based and each "hop" added 7ms. This i= n combination
with IP based telephony at the end points that added 40ms= one-way per
end-point (PDV buffer) caused people to complain when RTT= started creeping
up to 300-400ms. This was for PSTN calls.

Yes, people might have more tolerance with mobile phone c= alls because they
have lower expectations when out and about, but my experi= ence is that
people will definitely notice 300-400ms RTT but they migh= t not get upset
enough to open a support ticket until 600ms or more.

--
Mikael Abrahamsson    email: swmike@swm.pp.se




------------177daf6923932f727a93e71603--