Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt

Christian Amsüss <christian@amsuess.com> Sun, 07 November 2021 16:46 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC91B3A095C for <core@ietfa.amsl.com>; Sun, 7 Nov 2021 08:46:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 bVACyi1P47GI for <core@ietfa.amsl.com>; Sun, 7 Nov 2021 08:46:41 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28793A0965 for <core@ietf.org>; Sun, 7 Nov 2021 08:46:39 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 8AF9C4042B; Sun, 7 Nov 2021 17:46:28 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3D1C3154; Sun, 7 Nov 2021 17:46:27 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4f69:be08:bb2:9f43]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EEA56CD; Sun, 7 Nov 2021 17:46:21 +0100 (CET)
Received: (nullmailer pid 2715637 invoked by uid 1000); Sun, 07 Nov 2021 16:46:21 -0000
Date: Sun, 07 Nov 2021 17:46:21 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Cc: "core@ietf.org" <core@ietf.org>, Mauro Cociglio <mauro.cociglio@telecomitalia.it>, Tianran Zhou <zhoutianran@huawei.com>, Massimo Nilo <massimo.nilo@telecomitalia.it>, Fabio Bulgarella <fabio.bulgarella@guest.telecomitalia.it>
Message-ID: <YYgC3Y4YopABpkJX@hephaistos.amsuess.com>
References: <163491881526.20431.3603752246262277164@ietfa.amsl.com> <f3f016757c5a47298ac4147ff00e6e8e@huawei.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="7LNuJO4rR1HDjSOy"
Content-Disposition: inline
In-Reply-To: <f3f016757c5a47298ac4147ff00e6e8e@huawei.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/BmQ5eZm14hWDbT6iWZNQIdO1fBE>
Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Nov 2021 16:46:47 -0000

Hello Giuseppe,

On Fri, Oct 22, 2021 at 04:17:02PM +0000, Giuseppe Fioccola wrote:
> We have just uploaded a new draft on CoAP Performance Measurement
> Option, which we hope to discuss at IETF 112.  This document aims to
> specify a method for the Performance Measurement of CoAP.

skimming through your slides and the document I'm left wondering what
the obtained details would be used for. Estimates for RTT and losses are
produced, for example, also in the FASOR draft[1] -- but these get
applied to retransmission parameters, which are per-hop (ie. up to the
next proxy), where good estimates are direly needed.

What would the derived values be used for?

What are the intermediaries this is intended to work with? CoAP proxies
hide the identity of the client, and moreover often apply caching (which
will at any rate need a bit of consideration if this is to be applied
through proxies). Thus, on the server side the data in the bits would
likely appear completely mixed in presence of more than one client, and
clients would receive mixed signals in presence of cache entries.

So, for both aspects, it'd be helpful if you could sketch out the
envisioned use cases.

Best regards
Christian

[1]: https://datatracker.ietf.org/doc/html/draft-ietf-core-fasor-01

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom