[Bloat] Fwd: New Version Notification for draft-cpaasch-ippm-responsiveness-00.txt

[Christoph Paasch]

Hello Erik,

On 08/19/21 - 09:17, Erik Auerswald wrote:
> 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.

yes we can rephrase this: https://github.com/network-quality/draft-cpaasch-ippm-responsiveness/issues/11

> 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.

I agree. Just measuring RPM is not useful. As one can have excellent RPM but
still have an Internet connection that is barely usable.

However, I still believe that a single score for the user would be great
(that score would not be RPM though). This score should group together a
large list of network-properties (RPM, goodput, idle latency, protocol
conformance,...) and express a value of utility to the user that express how
its user-experience is affected. It would make it much easier for non-technical
users to compare the quality of their Internet without just focusing on a
single throughput-metric.

But that is a different topic than RPM ;-)



Cheers,
Christoph


> 
> Thanks,
> Erik
> -- 
> Thinking doesn't guarantee that we won't make mistakes. But not thinking
> guarantees that we will.
>                         -- Leslie Lamport