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

Christoph Paasch <cpaasch@apple.com> Thu, 06 January 2022 21:47 UTC

Return-Path: <cpaasch@apple.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 0E9AB3A1708 for <ippm@ietfa.amsl.com>; Thu, 6 Jan 2022 13:47:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.673
X-Spam-Level:
X-Spam-Status: No, score=-2.673 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.576, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=apple.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 JCoc93auiSYh for <ippm@ietfa.amsl.com>; Thu, 6 Jan 2022 13:47:36 -0800 (PST)
Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 932A73A1706 for <ippm@ietf.org>; Thu, 6 Jan 2022 13:47:36 -0800 (PST)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 206LkH4c018661; Thu, 6 Jan 2022 13:47:31 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=xiqhGKnQxqm3UrC1OSncLDEZ5f6e3RE6ET7+8HLhqOg=; b=PsHKBsC1OSvVkple08RbYVPfalhdFh4bLBzYpsSgHAzUBi1bch5pqWEnu8u7RcFnFGb2 x+4yFwg2OhiWTMWUUGC29odsUXCyf1yaL6YSJQyBJrKmOO9J6/4KJIQd8mvibFPCrDNd e7dSi/q6CXze3YcQ86/asRwm0cg9D03ALX7y7IQUhRbfm6hu2QdoOMUglmNLaDSbY9Lu toBDM4ihoBtM3GTbydnpuF7hxRN3oMda7dunyK9XJwvKQQFuvei93v6GvoOuqhPr6uid pCiKRftcbsRjJnWTV46TTJjmbNlg9aQONSgQ26/2PXb6ny3ejuOCn1uZSDYPl6rria/o 1w==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 3de4y3tkak-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 06 Jan 2022 13:47:31 -0800
Received: from rn-mailsvcp-mmp-lapp03.rno.apple.com (rn-mailsvcp-mmp-lapp03.rno.apple.com [17.179.253.16]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPS id <0R5B00RII5V6VT30@rn-mailsvcp-mta-lapp04.rno.apple.com>; Thu, 06 Jan 2022 13:47:30 -0800 (PST)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp03.rno.apple.com by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) id <0R5B00U005T4E500@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 06 Jan 2022 13:47:30 -0800 (PST)
X-Va-A:
X-Va-T-CD: dce2a0c403c3317da9d5e121f70305f4
X-Va-E-CD: de054fff2f5096dfe99f93b89e853049
X-Va-R-CD: 7d741991045d6b2f869f53b80b980cf0
X-Va-CD: 0
X-Va-ID: e0be11d6-832d-41ed-b1a9-50c381f73077
X-V-A:
X-V-T-CD: dce2a0c403c3317da9d5e121f70305f4
X-V-E-CD: de054fff2f5096dfe99f93b89e853049
X-V-R-CD: 7d741991045d6b2f869f53b80b980cf0
X-V-CD: 0
X-V-ID: d07ba130-30c3-4f3b-bf5e-85f8ee7c82ec
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-06_09:2022-01-05, 2022-01-06 signatures=0
Received: from smtpclient.apple ([17.192.155.238]) by rn-mailsvcp-mmp-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.12.20210903 64bit (built Sep 3 2021)) with ESMTPSA id <0R5B00V165V6H900@rn-mailsvcp-mmp-lapp03.rno.apple.com>; Thu, 06 Jan 2022 13:47:30 -0800 (PST)
Content-type: text/plain; charset="us-ascii"
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\))
From: Christoph Paasch <cpaasch@apple.com>
In-reply-to: <FR2P281MB0611FF5F937AD74CA3CF8EC79C7E9@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM>
Date: Thu, 06 Jan 2022 13:47:29 -0800
Cc: marcus.ihlar@ericsson.com, ippm@ietf.org
Content-transfer-encoding: quoted-printable
Message-id: <7874DB5E-8408-413A-8DBA-F78A1D6284B7@apple.com>
References: <AM0PR07MB4131542BCD0A6DE3F82F1E19E26D9@AM0PR07MB4131.eurprd07.prod.outlook.com> <DDBB7884-8A13-4139-8C3C-40087E767760@apple.com> <BY5PR01MB5940231FF6D39CCA24A7BD228A7B9@BY5PR01MB5940.prod.exchangelabs.com> <FR2P281MB0611FF5F937AD74CA3CF8EC79C7E9@FR2P281MB0611.DEUP281.PROD.OUTLOOK.COM>
To: Ruediger.Geib@telekom.de
X-Mailer: Apple Mail (2.3693.40.0.1.81)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2022-01-06_09:2022-01-05, 2022-01-06 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/hhqOy8Yboh4Et-juzUyLktzojSk>
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, 06 Jan 2022 21:47:41 -0000

Hello Ruediger,

thanks for your feedback! Please see inline:

> On Dec 22, 2021, at 11:16 PM, Ruediger.Geib@telekom.de wrote:
> 
> Hi Marcus,
> 
> Noting that some more work needs to be added, I support adoption.
> 
> Some comments:
> - I'd appreciate if the draft was covering expectable operational scenarios, namely
>  * There may be no bottleneck buffer - the test/metric needs to detect that and act appropriate.

I'm not sure what you mean ? Every flow is limited by some bottleneck that sits somewhere. Sometimes, it's the last mile, sometimes it's the Wi-Fi connectivity, sometimes flows become CPU-limited. But there always is a bottleneck somewhere that is limiting things at which point a buffer is building up (even though that "buffer" may be just 1 packet large)

>  * One might be interested in the metric while the test adds an insignificant load only. While receiver tries to consume service X, what's the metric seen from Y? 
>     (may help to clarify, whether the access causes trouble or another network section).

That would indeed be interesting for trouble-shooting and debugging. I believe this is out-of-scope though.

> - Measuring the maximum RPM as seen from the test server is part of the test or it isn't? That's not clear to me by now.
>  I'm favouring to make measuring the maximum RPM part of the test, this may help to scale results.

The methodology defines to only measure from the client as we are interested in responsiveness as a metric that is (as close as possible) representative of an end-user experience.

When you say "maximum RPM", do you mean that on an "idle" network?

> - The test set-up should prevent application as DoS attack tool.

The json-fetch at the beginning of the test allows server-side CDN deployments to "rate-limit" clients by simply delaying the response to the json-fetch.

What else do you have in mind regarding a DoS attack tool?


Thanks,
Christoph


> Regards,
> 
> Ruediger
> 
> 
> From: Marcus Ihlar <marcus.ihlar@ericsson.com >
> Subject: [ippm] Adoption call for draft-cpaasch-ippm-responsiveness
> Date: December 6, 2021 at 7:52:58 AM PST
> To: "ippm@ietf.org<mailto:ippm@ietf.org>" <ippm@ietf.org<mailto:ippm@ietf.org>>
> List-Id: IETF IP Performance Metrics Working Group 
> 
> 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<mailto:ippm@ietf.org>
> 
> _______________________________________________
> 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