From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f178.google.com (mail-pg1-f178.google.com [209.85.215.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D37F03B2A4 for ; Thu, 25 Feb 2021 14:56:58 -0500 (EST) Received: by mail-pg1-f178.google.com with SMTP id t11so4519435pgu.8 for ; Thu, 25 Feb 2021 11:56:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8V29F6/7XnYKq/tN2Aa+YlKRKaC+kk4ljMSDXRIqI3s=; b=m+43ndDO1+tRO7df1dRlyhe7UPuAQMyTH4jq1E44rtQj2lErdED3Eu6OVurUn4ZjUT BhbAP3BXO0lV2BgvshDpS/ZVgvJfL754CtIb8jAZoyZn6GC5gNoHNXGSL8JD3GJ+byH6 N/6bDZFYecSdeNurL8D2edRKXoyDZ96ulaV6o3oSKXsXTyPNHYGZmjLQKnCj/bjjbtZy qqsl34NsZRGDsN8mk9EG2JTkj1bfn37MU2M1X9+uk6vCkiZbHeiAXLf2XYC32Q8CoJ6S kg342iDJ+gNE1AGFeKNLTaE6z4KRLEGUe7tX7YuEJOshJXFN8PhOA+ouFxQq+eSX2eXB mdag== X-Gm-Message-State: AOAM531O1GFby0gKve5pMgT7MSdLtmncyqP40l5FGFBO8Oti4uwt94R5 8U7PgOdURjqXpIrJ+WVeTr0= X-Google-Smtp-Source: ABdhPJx57NEbemJXES/S5Z0dzA0fGZR92Zf/ADOJMgQyNvm+o2Abqk3iASYZAd6QxicDloS2vs5f0g== X-Received: by 2002:a05:6a00:1345:b029:1e3:d231:49cd with SMTP id k5-20020a056a001345b02901e3d23149cdmr4767295pfu.3.1614283017788; Thu, 25 Feb 2021 11:56:57 -0800 (PST) Received: from [192.168.130.24] (52-119-118-48.PUBLIC.monkeybrains.net. [52.119.118.48]) by smtp.gmail.com with ESMTPSA id v7sm7325973pfv.93.2021.02.25.11.56.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Feb 2021 11:56:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Simon Barber In-Reply-To: Date: Thu, 25 Feb 2021 11:56:55 -0800 Cc: Mikael Abrahamsson , sam@waveform.com, bloat Content-Transfer-Encoding: quoted-printable Message-Id: <2CE9BEA3-58B5-44CB-98C0-C1B54FA5D348@superduper.net> References: <177d80af608.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <177d9698ff0.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <177d9776300.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> To: Sina Khanifar X-Mailer: Apple Mail (2.3608.120.23.2.4) 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 19:56:59 -0000 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=E2=80=99s 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 =E2=80=98latency = first=E2=80=99 nature of this test. It=E2=80=99s 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: >=20 >> 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > On Thu, Feb 25, 2021 at 5:53 AM Simon Barber = wrote: >>=20 >> 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. >>=20 >> Simon >>=20 >> On February 25, 2021 5:49:26 AM Mikael Abrahamsson = wrote: >>=20 >>> On Thu, 25 Feb 2021, Simon Barber wrote: >>>=20 >>>> 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. >>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> -- >>> Mikael Abrahamsson email: swmike@swm.pp.se >>=20 >>=20