From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 86DD93B2A4 for ; Thu, 25 Feb 2021 15:11:02 -0500 (EST) Received: by mail-ej1-x633.google.com with SMTP id n20so10959792ejb.5 for ; Thu, 25 Feb 2021 12:11:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=waveform.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=uloR0jqtjRW3Xg33pQbV2G+psXiNKvHP9YbQA8bIZfg=; b=zb6DlrfVELv9g68++TAFc078QK7RSQUQt18fR81Gp4QlnzaATWB9gXnA7si76lJTeA 1KI8FjhLvqyOD4OxCfHwP2WG9X4rUx56mNpDvruEpxEmNLjEOFjrIcKDaLZOy9mrnhrY 2eiAg2JQsrt0i84hm7WwsVYyjeISm797ttQvr+lTtPL0i04Ke3C4lmsjWWMrvkidl3Qq XrkB8+9C5cM3SqES4RNOlKTTEblVoKUZD2co8SC12qTeqTMuzYhD9CD/6BL+V8ks2fJ3 1YOdqKtrLT6+emMd9TvnZuCjzZjjepVpG9zr7NC24MLIG7/Cd1pPxnAqRa8vCQV0PfAA Uiiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=uloR0jqtjRW3Xg33pQbV2G+psXiNKvHP9YbQA8bIZfg=; b=kXL9Bm1zJ9kmcNsQQrbUYKjZohgpo3pIwoRGcaArH8ORd3c88X2cvDHEcooD8qnNDr 1LQM+dHwC+tgj7/ucSF1ifUZtHhH5yIBP0ZfHgOB/cH6KNxP7E60H8kZT45qhVOf8glw iwL5wKub13yyIdW5/pZsEd5x5wjs2/9G40mkcF8AFe4KSZDxDtk8av9Bf6BcfdS9ZvSH U3q65ckLoIVHaIaVBC3B5Ei3+vxnfxH2dmKPLqC7P6InAXf8MzDEnic1PO1XGBfvQeBR eidz/Lfm7QrBHIN3uejQNV3H9gssr+K0+g5XvBVZa2j4fIQ9dfnjehL/58zvtNqptqbc 79Mw== X-Gm-Message-State: AOAM531OrIVABlXTLC0VQe03hrdJNb2g5ZnD7HoskqmsfgZbf1mfruA+ OMedgIPO+Bj+kwYCReQV0N0O9E0JPSqpftxcnBpgKFS1JkWz9WU3WMEYPkY5z1zxm0SgQFMIi9h S4FKx2G12D6nHFOUUq4qCdFcRXfFt+mNh92U9MqTCMrmt1y36TaJx9tTFGnaqTbrLF1Ne3k8yue n/vBRl3Nw= X-Google-Smtp-Source: ABdhPJzBs053EARz4gtuskAzrU5trCfOvrtBYJvkIR8omPSxhmgro+Jh9DBindV9VcF5yJCqoetxHA== X-Received: by 2002:a17:907:101c:: with SMTP id ox28mr4461209ejb.334.1614283861348; Thu, 25 Feb 2021 12:11:01 -0800 (PST) Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com. [209.85.208.45]) by smtp.gmail.com with ESMTPSA id cr20sm3310236ejc.57.2021.02.25.12.11.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 25 Feb 2021 12:11:01 -0800 (PST) Received: by mail-ed1-f45.google.com with SMTP id h10so8446228edl.6 for ; Thu, 25 Feb 2021 12:11:01 -0800 (PST) X-Received: by 2002:aa7:cc8b:: with SMTP id p11mr4879657edt.284.1614283860833; Thu, 25 Feb 2021 12:11:00 -0800 (PST) MIME-Version: 1.0 References: <177d80af608.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <177d9698ff0.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <177d9776300.27a9.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <2CE9BEA3-58B5-44CB-98C0-C1B54FA5D348@superduper.net> In-Reply-To: <2CE9BEA3-58B5-44CB-98C0-C1B54FA5D348@superduper.net> From: Sina Khanifar Date: Thu, 25 Feb 2021 12:10:49 -0800 X-Gmail-Original-Message-ID: Message-ID: To: simon@superduper.net Cc: Mikael Abrahamsson , sam@waveform.com, bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:11:02 -0000 Thanks for the kind words, Simon! > Since you are measuring buffer bloat - how much latency *can* be caused b= y 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 e= xcessive 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 te= mporarily lower the buffer occupancy and result in a lower average jitter n= umber. 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 comp= onent 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 unmit= igated buffers while being easy to understand is tricky. > > Since you are measuring buffer bloat - how much latency *can* be caused b= y 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 e= xcessive 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 te= mporarily lower the buffer occupancy and result in a lower average jitter n= umber. > > 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: > > > >> 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 wro= te: > >> > >> 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 conversatio= n 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 hav= e 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 combinatio= n > >>> 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 cre= eping > >>> 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 up= set > >>> enough to open a support ticket until 600ms or more. > >>> > >>> -- > >>> Mikael Abrahamsson email: swmike@swm.pp.se > >> > >> >