Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness

Dave Taht <dave.taht@gmail.com> Thu, 23 December 2021 15:40 UTC

Return-Path: <dave.taht@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DDD3A174A for <ippm@ietfa.amsl.com>; Thu, 23 Dec 2021 07:40:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yL0mnDLjpcAJ for <ippm@ietfa.amsl.com>; Thu, 23 Dec 2021 07:40:48 -0800 (PST)
Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA15F3A1747 for <ippm@ietf.org>; Thu, 23 Dec 2021 07:40:48 -0800 (PST)
Received: by mail-io1-xd32.google.com with SMTP id q5so7590178ioj.7 for <ippm@ietf.org>; Thu, 23 Dec 2021 07:40:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=fDpJyWDStOErk5t2fdipmRUEdb5yWtnlmqBnKkP0Cec=; b=CU+O0dJMaV7c4NtjKy5qaCBpcabKKduHuZPSx38vlKOO5JF9KervyzbueEFaw/GVnK tQhxQO1vUkbPDU1B+qegZRL0lIUIddred/ewuWYSP3fPYiVglfU6oWQtD7UL3Aa6+6ns O1HxhBqU45YS7eLxH341xvVjU7dq5b0rQ1G88bf1whuwreyPYXXnkINXVUpkbEbbwAES VT7Q+bFVWypkC5m+7YnuhGijclBzZbTBKfp5KFXavKUQhdeZ2vy6qUvXyYTK+eEogRv7 CZO8wI0+hCmDggommfrKXnPYQpM4QXK6f7w4Eb5izLGeRp/z1vb5DhytQwzPpHifOEal yYkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=fDpJyWDStOErk5t2fdipmRUEdb5yWtnlmqBnKkP0Cec=; b=rU5T+z5JcI7ENeQS8j+2QPw+rQat/MxtlbbeM3CgatZVZXsddvjvXVYBY/wb2OyFFj nyXNf5Ik2S5edDDRKPSBWKewdA40j3rJu3hl7YCxHSEGv39q4uGsRvMLvg0sanDP6JLq DghTZJDDJhGwsxKBtkSyK9F5r/h7HIVzcl+uap42fFsIlPxeLqy5fIA7aTgZJWxSm27C Q7kjRdpHCBFYwioYzXtvotUgU5uHJ/CJwfro+5XFwlXZ5gpQOYObLuqPMI2PJyIjQUhK 2XFEPX4lYRAJNJEpK1DPDmbvtGlGmxl9K2Iw739LfTPwXeAFc8mD0PNhTSxlaAugSvS+ CcyA==
X-Gm-Message-State: AOAM5334LT9B65ttm0zLibA4xca/6S4A4E81KyJTLkvnAMs1dtW8lplb tGLVKFxqN6IzMpIZqM0E64TLVxJ6u9jCsVfQvxg=
X-Google-Smtp-Source: ABdhPJzPMQ/tu7ukldlYsb+JN320Nmvc9N7vHwQlZbgqiCB1dlCMLwW7VuzIyZX+BJw8dcXP66c84oDPxBookuNzORw=
X-Received: by 2002:a05:6638:3292:: with SMTP id f18mr1633492jav.115.1640274046716; Thu, 23 Dec 2021 07:40:46 -0800 (PST)
MIME-Version: 1.0
References: <AM0PR07MB4131542BCD0A6DE3F82F1E19E26D9@AM0PR07MB4131.eurprd07.prod.outlook.com> <CA+RyBmU_j9-vR+BnjvhKCDuaWYPZ_Ym96yUJPX0LhGihfsp1ng@mail.gmail.com>
In-Reply-To: <CA+RyBmU_j9-vR+BnjvhKCDuaWYPZ_Ym96yUJPX0LhGihfsp1ng@mail.gmail.com>
From: Dave Taht <dave.taht@gmail.com>
Date: Thu, 23 Dec 2021 07:40:34 -0800
Message-ID: <CAA93jw5_H+E9TmRAmqKy4q3AZoy7tUCSC+=9FxWvj-8ko9FSBw@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
Cc: Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/kAteoENMdeg2tQTP1FYxu7kH-mY>
Subject: Re: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Dec 2021 15:40:53 -0000

I support adoption. My concerns are that I do not know if a single
metric is achievable, and also the methods created SHOULD try to find
the bottleneck link. I'd like open source software created along the
way (the apple effort which I applaud has released the server side) to
explore the issues.

On Wed, Dec 22, 2021 at 11:44 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Dear Marcus, Authors, et al,
> apologies for the belated response.
> I've read the draft and have some comments to share with you:
>
> as I understand it, the proposed new responsiveness metric is viewed as the single indicator of a bufferbloat condition in a network. As I recall, the discussion at Measuring Network Quality for End-Users workshop and on the mailing list indicated, that there’s no consensus on what behaviors, symptoms can reliably signal the bufferbloat. It seems that it would be reasonable to first define what is being measured, characterized by the responsiveness metric. Having a document that discusses and defines the bufferbloat would be great.
> It seems like in the foundation of the methodology described in the draft lies the assumption that without adding new flows the available bandwidth is constant, does not change. While that is mostly the case, there are technologies that behave differently and may change bandwidth because of the outside conditions. Some of these behaviors of links with variable discrete bandwidth are discussed in, for example, RFC 8330 and RFC 8625.
> Then, I find the motivation not to use time units to express the responsiveness metric not convincing:
>
>    "Latency" is a poor measure of responsiveness, since it can be hard
>    for the general public to understand.  The units are unfamiliar
>    ("what is a millisecond?") and counterintuitive ("100 msec - that
>    sounds good - it's only a tenth of a second!").
>
>
> I would appreciate these topics being discussed and addressed in the draft before it is adopted by the WG.
>
> Regards,
> Greg
>
> On Mon, Dec 6, 2021 at 7:53 AM Marcus Ihlar <marcus.ihlar=40ericsson.com@dmarc.ietf.org> wrote:
>>
>> Hi IPPM,
>>
>>
>>
>> This email starts an adoption call for draft-cpaasch-ippm-responsiveness, "Responsiveness under Working Conditions”. This document specifies the “RPM Test” for measuring user experience when the network is fully loaded. The intended status of the document is Experimental.
>>
>>
>>
>> https://datatracker.ietf.org/doc/draft-cpaasch-ippm-responsiveness/
>>
>> https://datatracker.ietf.org/doc/html/draft-cpaasch-ippm-responsiveness-01
>>
>>
>>
>> This adoption call will last until Monday, December 20. Please review the document, and reply to this email thread to indicate if you think IPPM should adopt this document.
>>
>>
>>
>> BR,
>>
>> Marcus
>>
>>
>>
>> _______________________________________________
>> ippm mailing list
>> ippm@ietf.org
>> https://www.ietf.org/mailman/listinfo/ippm
>
> _______________________________________________
> ippm mailing list
> ippm@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm



-- 
I tried to build a better future, a few times:
https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org

Dave Täht CEO, TekLibre, LLC