[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02                                                      
CORE Working Group                                           G. Fioccola
Internet-Draft                                                   T. Zhou
Intended status: Standards Track                                  Huawei
Expires: August 13, 2022                                     M. Cociglio
                                                           F. Bulgarella
                                                                 M. Nilo
                                                          Telecom Italia
                                                        February 9, 2022

 Constrained Application Protocol (CoAP) Performance Measurement Option


   This document specifies a method for the Performance Measurement of
   the Constrained Application Protocol (CoAP).  A new CoAP option is
   defined in order to enable network telemetry both end-to-end and on-

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 13, 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Fioccola, et al.         Expires August 13, 2022                [Page 1]

Internet-Draft                   COAP PM                   February 2022

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Performance Measurement methods for CoAP  . . . . . . . . . .   3
   3.  CoAP Performance Measurement Option . . . . . . . . . . . . .   4
   4.  Structure of the PM Option  . . . . . . . . . . . . . . . . .   5
   5.  Application Scenarios . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [RFC7252] define the CoAP Protocol.  In CoAP, reliability is provided
   by marking a message as Confirmable (CON) with ACKs.  A message that
   does not require reliable transmission can be sent as a Non-
   confirmable message (NON).

   In case of CoAP reliable mode there are Message IDs and ACKs, that
   could eventually be used to measure Round-Trip Time (RTT) and losses.
   But it is resource-consuming for constrained nodes since they have to
   look at Message IDs and take timestamps.  These operations are
   expensive in terms of resources.  In case of CoAP unreliable mode,
   there is no ACK and, consequently, it is not possible to measure RTT
   and losses.

   Thus, there is no easy way to measure the performance metrics in COAP
   environment to satisfy the low resources of constrained nodes.  And
   it is in any case limited to RTT and end-to-end losses.

   A mechanism to measure the performance in CoAP can be useful to
   verify and meet the operational requirements, but it should be a
   simple mechanism for network diagnostic to be developed on

Fioccola, et al.         Expires August 13, 2022                [Page 2]

Internet-Draft                   COAP PM                   February 2022

   constrained nodes requiring just a minimal amount of collaboration
   from the endpoints.

   [I-D.ietf-ippm-explicit-flow-measurements] describes the
   methodologies for Explicit Flow Measurement (EFM).  The EFM
   techniques employ few marking bits, inside the header of each packet,
   for loss and delay measurement.  These are relevant for encrypted
   protocols, e.g.  QUIC [RFC9000], where there are only few bits
   available in the non-encrypted header in order to allow passive
   performance metrics from an on-path observer.  These methodologies
   could potentially be used and extended in CoAP.

   [I-D.ietf-ippm-explicit-flow-measurements] defines different
   combinations of bits because the number of bits in QUIC is limited
   and different experiments have been done.  But all these methods
   together imply complex algorithms that do not apply well to the CoAP

   This document aims to create an easy way to allow performance
   measurement for CoAP, by defining a new option, called Performance
   Measurement (PM) CoAP Option.  The CoAP performance metrics (e.g.
   RTT and losses) can be useful for an operator or an enterprise that
   is managing a constrained, low-power and lossy network.

2.  Performance Measurement methods for CoAP

   CoAP [RFC7252] defines a number of options that can be included in a
   message.  For this reason, a new option for CoAP, carrying
   Performance Measurement (PM) bits is the approach followed by this

   The PM bits that are included in the Option are:

   o  sQuare bit (Q bit), based on [RFC8321] and further described in

   o  Spin bit (S bit), described in [I-D.ietf-quic-manageability] and
      included as optional bit in [RFC9000];

   o  Loss and Delay event information for further usage.

   A requirement to enable PM methods in COAP environment is that the
   methodologies and the algorithm needs to be kept simple.  For this
   reason, the idea is to re-apply only the S bit and Q bit.

   The sQuare bit algorithm is to create square waves of a known length
   (e.g. 64 packets).  Each side of the connection can set the Q bit and

Fioccola, et al.         Expires August 13, 2022                [Page 3]

Internet-Draft                   COAP PM                   February 2022

   toggle its value every fixed number of packets.  The number of
   packets can be easily recognized and packet loss can be measured.

   The Spin bit algorithm is to create a square wave signal on the data
   flow, using a bit, whose length is equal to RTT.  The Spin bit causes
   one bit to 'spin', generating one edge (a transition from 0 to 1 or
   from 1 to 0) once per end-to-end RTT.  The Spin bit is set by both
   sides to the same value for as long as one round trip lasts and then
   it toggles the value.

   The synergy between S bit and Q bit is also possible.  As described
   above, the length of the Q bit square waves is fixed (e.g. a
   predefined number of packets) in this way each endpoint can detect a
   packet loss if it receives less packets than expected.  In addition,
   it is possible to potentiate the Q bit signal by incorporating RTT
   information as well.  This implies a little modification to the
   algorithm of the Q bit that could also be used alone:

      One packet in a period of the square wave can be selected and set
      to the opposite value of that period.  After one RTT it comes back
      and another packet is selected and set again to the opposite value
      of that period.  And the process can start again.  By measuring
      the distance between these special packets it is possible to
      measure the RTT in addition to packet loss.  The periods with the
      special packets have one packet less than expected but this is
      easy to recognize by both endpoints.

   So, with one bit, it can be possible to measure loss and delay.  This
   can be used to reinforce the Spin Bit mechanism or to use only one
   bit (sQuare bit) in the Option.

   The advantages of using the CoAP PM Option are:

      1) Simplification because it is not needed to read Message IDs,
      indeed there is a well-defined sQuare wave, and it is not
      necessary to store timestamps, since the duration of the Spin Bit
      period is equal to RTT.

      2) Enabling easy on-path observer (proxy, gateway) metrics.

3.  CoAP Performance Measurement Option

   Figure 1 shows the property of the CoAP Performance Measurement (PM)
   Option.  The formatting of this table is reported in [RFC7252].  The
   C, U, N, and R columns indicate the properties Critical, Unsafe,
   NoCacheKey, and Repeatable as defined in [RFC7252].  None of these
   properties is marked for the PM options.

Fioccola, et al.         Expires August 13, 2022                [Page 4]

Internet-Draft                   COAP PM                   February 2022

       | Number | C | U | N | R | Name   | Format | Length | Default |
       | TBD    |   |   |   |   |   PM   | uint   | 1      | 0       |

                    Figure 1: CoAP PM Option Properties

   Note that it could be possible to make use of one bit in the option
   to identify the mode.  In this way two patterns can be defined.

4.  Structure of the PM Option

   The value of the PM option is a 1 byte unsigned integer.  This
   integer value encodes the following fields:

                           0 1 2 3 4 5 6 7
                          |M|   Pattern   |

               Figure 2: CoAP Performance Measurement Option


   o  M bit can be set to 1 or 0 and it is used to identify whether the
      Option follows pattern 1 (M bit = 0) or pattern 2 (M bit = 1).

   o  Pattern bits can be of two kinds as reported below.

   The PM Option can employ two patterns based on the value of the M

                           0 1 2 3 4 5 6 7
                          |0|Q|   Event   |

          Figure 3: CoAP Performance Measurement Option pattern 1

Fioccola, et al.         Expires August 13, 2022                [Page 5]

Internet-Draft                   COAP PM                   February 2022

                           0 1 2 3 4 5 6 7
                          |1|Q|S|  Event  |

          Figure 4: CoAP Performance Measurement Option pattern 2

   The COAP Option could be defined with 2 PM bits (S and Q) or defined
   with a single PM bit (Q bit).


   o  Q bit is used in both pattern 1 and pattern 2.  It is described in
      [I-D.ietf-ippm-explicit-flow-measurements] and enhanced with the
      method described in Section 2;

   o  S bit is used in Option 2.  It is also embedded in the QUIC
      Protocol [RFC9000];

   o  Event bits MAY encode additional Loss and Delay information based
      on well-defined encoding and they can also be used by on-path
      observers.  If these Event bits are all zero, they MUST be ignored
      on receipt.

   As an example the Event bits can be divided into two parts: loss
   event bits and delay event bits.  Based on the average RTT, an end
   point can define different levels of thresholds and set the delay
   event bits accordingly.  The same applies to loss event bits.  In
   this way an on-path observer becomes aware of the network conditions
   by simply reading these Event bits.

   The on-path observer can read the event signaling bits and could be
   the Proxy or the Gateway which interconnects disjointed CoAP
   networks.  It MAY communicate with Client and Server to set some
   parameters such as timeout based on the network performance.

   The CoAP PM Options described in this document can be used in both
   requests and responses.  If a CoAP endpoint does not implement the
   measurement methodologies, it can simply leave the default value (all
   bits are zero).  In this way the other CoAP endpoints become aware
   that the measurement cannot be executed in that case.

   The fixed number of packets to create the Q bit signal is predefined
   and its value is configured from the beginning for all the CoAP

Fioccola, et al.         Expires August 13, 2022                [Page 6]

Internet-Draft                   COAP PM                   February 2022

5.  Application Scenarios

   The main usage of the CoAP PM Options is to do end-to-end measurement
   between the client and the server but it can also allow split
   measurements.  The on-path measurement is the additional feature.
   This information can be used to monitor the network in order to check
   the operational performance and to employ further network

   The intermediaries or on-path observers could be:

      Network Functions or Probes that must be able to see deep into

      Gateway or Proxies that, as specified in [RFC7252], are CoAP
      endpoints tasked by CoAP clients to perform requests on their

   If the on-path observers are network functions or probes, the CoAP PM
   Option can be applied end-to-end between client and server.  The on-
   path network probes can read Q bit and S bit and implement the
   relevant algorithms to measure losses and RTT.  Otherwise they can
   simply read the Event bits and be informed about the performance
   without implementing any algorithm.  The event signaling bits can be
   sent from the Server (that can do the performance measurement
   calculation) to the Client, or viceversa.

   If the on-path observers are CoAP proxies, the CoAP PM Option can
   only be applied to the different separate connections between client
   and server instead of end-to-end.  Indeed, CoAP proxies hide the
   identity of the client and could also apply caching.  Thus, on the
   server side, the data would appear mixed in presence of more than one
   client, and clients would receive mixed signals in presence of cache
   entries.  But in this case, the measurements can be segmented and
   done between the Proxies or between a Proxy and the Client or between
   a Proxy and the Server.  The Server can distinguish the source client
   by using additional flow information such as the IP addresses.  It
   could also be possible to bundle different clients if they are mixed.
   So, it is worth highlighting that an on-path observer can find useful
   information both on the proxy-server link and on the client-proxy

      On the link from a proxy to the server, traffic from different
      clients would be mixed.  In this case, the proxy can still use the
      PM Option to set S bit and Q bit for the bundle of clients for a
      specific server.  The measurement can be done but it is an
      information related to a bundle of clients.  An alternative can be

Fioccola, et al.         Expires August 13, 2022                [Page 7]

Internet-Draft                   COAP PM                   February 2022

      to use the Option only for a single client at once in order to
      avoid to do a grouped measurement.

      Conversely, on the link from the client to the proxy,
      communication may happen with different servers, and in this case
      it is necessary to check the other fields to understand the

   In summary, a typical CoAP scenario can be the following:

   Devices -- Gateway/Proxy -- Transport Network -- Probe (or Proxy) --
   Server/Data Center

   If the CoAP PM Option is applied between devices and the server
   (across intermediaries), the Probe can measure the total RTT by using
   the Spin bit, indeed it allows RTT measurement for all the
   intermediate points.  But, with sQuare Bit and by applying the
   methodologies in [RFC8321], it is also possible to do hop-by-hop
   measurements for loss and delay and segment where possible.

   If there is a CoAP proxy, the measurement can be done between the
   Proxies or between a Proxy and the Client or between a Proxy and the
   Server.  It can be done through Spin bit or by applying [RFC8321] on
   the sQuare Bit signal.

6.  Security Considerations

   Security considerations related to CoAP proxying are discussed in

   A CoAP endpoint can use the CoAP PM Options to affect the measures of
   a network into which it is making requests by maliciously modifying
   the value of the option.  Also, the PM bits may reveal performance
   information outside the administrative domain.  To prevent that, a
   CoAP proxy that is located at the boundary of an administrative
   domain MAY be instructed to strip the payload or part of it before
   forwarding the message.

   It is worth highlighting what happens if devices, transport network
   and server are operated by different administrative domains.
   Security concerns need to be taken into account, but OSCORE [RFC8613]
   can be used and the CoAP PM options can be integrity protected end-
   to-end by OSCORE.  Then the operators can put their measurement
   probes in one or more places to break down the different RTT and loss
   contributions where it is relevant (e.g., at the ingress/egress of
   their respective network segments).  OSCORE ensures end-to-end
   integrity protection and would tell the endpoints if someone
   tampered, but it doesn't mean that the endpoints are not lying to the

Fioccola, et al.         Expires August 13, 2022                [Page 8]

Internet-Draft                   COAP PM                   February 2022

   observer.  However it is possible to assume that for the typical COAP
   applications it is less likely that the endpoints are attackers while
   it is more likely that an on-path observer is the attacker.

7.  IANA Considerations

   IANA is requested to add the following entry to the "CoAP Option
   Numbers" sub-registry available at https://www.iana.org/assignments/

             Number          Name              Reference
             TBD           PM Option          [This draft]

                     Figure 5: CoAP PM Option Numbers

8.  Acknowledgements

   The authors would like to thank Christian Amsuess and Thomas Fossati
   for the precious comments and suggestions.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

9.2.  Informative References

              Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I.,
              Bulgarella, F., Hamchaoui, I., Nilo, M., Sisto, R., and D.
              Tikhonov, "Explicit Flow Measurements Techniques", draft-
              ietf-ippm-explicit-flow-measurements-00 (work in
              progress), October 2021.

              Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
              Transport Protocol", draft-ietf-quic-manageability-14
              (work in progress), January 2022.

Fioccola, et al.         Expires August 13, 2022                [Page 9]

Internet-Draft                   COAP PM                   February 2022

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [RFC8321]  Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli,
              L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi,
              "Alternate-Marking Method for Passive and Hybrid
              Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321,
              January 2018, <https://www.rfc-editor.org/info/rfc8321>.

   [RFC8613]  Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
              "Object Security for Constrained RESTful Environments
              (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,

Authors' Addresses

   Giuseppe Fioccola
   Riesstrasse, 25
   Munich  80992

   Email: giuseppe.fioccola@huawei.com

   Tianran Zhou
   156 Beiqing Rd.
   Beijing  100095

   Email: zhoutianran@huawei.com

   Mauro Cociglio
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148

   Email: mauro.cociglio@telecomitalia.it

Fioccola, et al.         Expires August 13, 2022               [Page 10]

Internet-Draft                   COAP PM                   February 2022

   Fabio Bulgarella
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148

   Email: fabio.bulgarella@guest.telecomitalia.it

   Massimo Nilo
   Telecom Italia
   Via Reiss Romoli, 274
   Torino  10148

   Email: massimo.nilo@telecomitalia.it

Fioccola, et al.         Expires August 13, 2022               [Page 11]