General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Erik Auerswald <auerswal@unix-ag.uni-kl.de>
To: Christoph Paasch <cpaasch@apple.com>
Cc: bloat@lists.bufferbloat.net,
	draft-cpaasch-ippm-responsiveness@ietf.org, ippm@ietf.org
Subject: Re: [Bloat] Fwd: New Version Notification for draft-cpaasch-ippm-responsiveness-00.txt
Date: Thu, 19 Aug 2021 09:17:34 +0200	[thread overview]
Message-ID: <20210819071734.GA3936@unix-ag.uni-kl.de> (raw)
In-Reply-To: <YR2DRslj1nk4RwOL@MacBook-Pro-2.local>

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

  reply	other threads:[~2021-08-19  7:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-13 21:41 Christoph Paasch
2021-08-15 13:39 ` Erik Auerswald
2021-08-18 22:01   ` Christoph Paasch
2021-08-19  7:17     ` Erik Auerswald [this message]
2021-08-19 15:48       ` Christoph Paasch
2021-08-19 17:50         ` [Bloat] Sidebar re illustrating quality (was: New Version Notification for draft-cpaasch-ippm-responsiveness-00.txt) Dave Collier-Brown
2021-08-19 21:17           ` Kenneth Porter
2021-08-20  1:58             ` Dave Collier-Brown
2021-08-21  1:22               ` Kenneth Porter
2021-08-21 11:01                 ` Sebastian Moeller
2021-08-21 10:23           ` Erik Auerswald
2021-08-21 16:31             ` Dave Collier-Brown
2021-09-21 20:50   ` [Bloat] [ippm] Fwd: New Version Notification for draft-cpaasch-ippm-responsiveness-00.txt Toerless Eckert
2021-10-22 23:19     ` Christoph Paasch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210819071734.GA3936@unix-ag.uni-kl.de \
    --to=auerswal@unix-ag.uni-kl.de \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cpaasch@apple.com \
    --cc=draft-cpaasch-ippm-responsiveness@ietf.org \
    --cc=ippm@ietf.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox