From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (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 BA7C53B29E for ; Thu, 19 Aug 2021 03:17:47 -0400 (EDT) Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 17J7HYuf153682 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 09:17:34 +0200 Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 17J7HYJQ004991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 19 Aug 2021 09:17:34 +0200 Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 17J7HYwq004990; Thu, 19 Aug 2021 09:17:34 +0200 Date: Thu, 19 Aug 2021 09:17:34 +0200 From: Erik Auerswald To: Christoph Paasch Cc: bloat@lists.bufferbloat.net, draft-cpaasch-ippm-responsiveness@ietf.org, ippm@ietf.org Message-ID: <20210819071734.GA3936@unix-ag.uni-kl.de> References: <20210815133922.GA18118@unix-ag.uni-kl.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Author: Erik Auerswald User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, hits=-1, tests=ALL_TRUSTED=-1 X-Spam-Score: (-1) X-Spam-Flag: NO Subject: Re: [Bloat] Fwd: New Version Notification for draft-cpaasch-ippm-responsiveness-00.txt 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, 19 Aug 2021 07:17:47 -0000 Hello Christoph, On Wed, Aug 18, 2021 at 03:01:42PM -0700, Christoph Paasch wrote: > On 08/15/21 - 15:39, Erik Auerswald wrote: > > [...] > > I do not think RPM can replace all other metrics. This is, in a way, > > mentioned in the introduction, where it is suggested to add RPM to > > existing measurement platforms. As such I just want to point this out > > more explicitely, but do not intend to diminish the RPM idea by this. > > In short, I'd say it's complicated. > > Yes, I fully agree that RPM is not the only metric. It is one among > many. If there is a sentiment in our document that sounds like "RPM > is the only that matters", please let me know where so we can reword > the text. Regarding just this, in section 3 (Goals), item 3 (User-friendliness), the I-D states that '[u]sers commonly look for a single "score" of their performance.' This can lead to the impression that RPM is intended to provide this single score. I do think that RPM seems more generally useful than either idle latency or maximum bandwidth, but for a more technically minded audience, all three provide useful information to get an impression of the usefulness of a network for different applications. Thanks, Erik -- Thinking doesn't guarantee that we won't make mistakes. But not thinking guarantees that we will. -- Leslie Lamport