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

[Giuseppe Fioccola <[e-mail]>]

Hi Christian,
Thank you for your comments.
Please find my answers inline as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Christian Amsüss <[e-mail]> 
Sent: Sunday, November 7, 2021 5:46 PM
To: Giuseppe Fioccola <[e-mail]>
Cc: [e-mail]; Mauro Cociglio <[e-mail]>; Tianran Zhou <[e-mail]>; Massimo Nilo <[e-mail]>; Fabio Bulgarella <[e-mail]>
Subject: Re: [core] FW: New Version Notification for draft-fz-core-coap-pm-00.txt

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?

[GF]: The derived values (RTT, losses) can be useful for an operator or an enterprise that is managing a constrained, low-power and lossy network. As IoT and M2M keep growing, a mechanism to measure the performance can become useful to meet the operational requirements. Also, it should be a simple mechanism to be developed on constrained nodes. 

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.

[GF]: The intermediaries or on-path observers could also be network gateway or probes, that can see deep into application and read the measurements. This information can be used to monitor the network in order to check the operational performance and to employ further network optimization. The measurements can be end-to-end between Client and Server or can be split. If CoAP Proxies are used, the measurements can be done between the Proxies or between the Proxy and the Client. The Server can distinguish the source client, for example by using additional flow information such as the IP addresses. It could also possible to bundle different clients if they are mixed. I think we have to clarify the different scenarios in the next version of the draft.

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