CORE Working Group G. Fioccola
Internet-Draft T. Zhou
Intended status: Standards Track Huawei
Expires: April 25, 2022 M. Cociglio
F. Bulgarella
M. Nilo
Telecom Italia
October 22, 2021
Constrained Application Protocol (CoAP) Performance Measurement Option
draft-fz-core-coap-pm-00
Abstract
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. The presence of the
on-path observer is also considered.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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 April 25, 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fioccola, et al. Expires April 25, 2022 [Page 1]
Internet-Draft COAP PM October 2021
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. On-path Observers . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
[I-D.mdt-ippm-explicit-flow-measurements] reported a summary on the
methodologies for Explicit Flow Measurement (EFM). These EFM
techniques could potentially be used in CoAP. These methodologies
employ few marking bits, inside the header of each packet, for loss
Fioccola, et al. Expires April 25, 2022 [Page 2]
Internet-Draft COAP PM October 2021
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.
[I-D.mdt-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
environment.
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.
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
document.
The PM bits that are included in the Option are:
o sQuare bit (Q bit), based on [RFC8321] and further described in
[I-D.mdt-ippm-explicit-flow-measurements];
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
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.
Fioccola, et al. Expires April 25, 2022 [Page 3]
Internet-Draft COAP PM October 2021
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 it 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.
+--------+---+---+---+---+--------+--------+--------+---------+
| 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.
Fioccola, et al. Expires April 25, 2022 [Page 4]
Internet-Draft COAP PM October 2021
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
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M| Pattern |
+-+-+-+-+-+-+-+-+
Figure 2: CoAP Performance Measurement Option
Where:
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
bit:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0|Q| Event |
+-+-+-+-+-+-+-+-+
Figure 3: CoAP Performance Measurement Option pattern 1
0
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).
Where:
o Q bit is used in both pattern 1 and pattern 2. It is described in
[I-D.mdt-ippm-explicit-flow-measurements] and enhanced with the
method described in Section 2;
Fioccola, et al. Expires April 25, 2022 [Page 5]
Internet-Draft COAP PM October 2021
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.
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
endpoints.
5. On-path Observers
An on-path observer SHOULD be able to see deep into application and
it can be a COAP Proxy or Gateway. The on-path observers can read Q
bit and S bit and apply the relevant algorithms to measure Losses and
RTT. Otherwise they can simply read the event bits and be informed
about the performance without applying any algorithm. The event
signaling bits can be sent from the Server (that can do the
performance measurement calculation) to the Client, or viceversa.
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.
6. Security Considerations
Security considerations related to CoAP proxying are discussed in
[RFC7252].
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
Fioccola, et al. Expires April 25, 2022 [Page 6]
Internet-Draft COAP PM October 2021
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.
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/
core-parameters/core-parameters.xhtml#option-numbers:
Number Name Reference
---------------------------------------------
TBD PM Option [This draft]
Figure 5: CoAP PM Option Numbers
8. Acknowledgements
TBD
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,
<https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References
[I-D.ietf-quic-manageability]
Kuehlewind, M. and B. Trammell, "Manageability of the QUIC
Transport Protocol", draft-ietf-quic-manageability-13
(work in progress), September 2021.
[I-D.mdt-ippm-explicit-flow-measurements]
Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I.,
Bulgarella, F., Hamchaoui, I., Nilo, M., Sisto, R., and D.
Tikhonov, "Explicit Flow Measurements Techniques", draft-
mdt-ippm-explicit-flow-measurements-02 (work in progress),
July 2021.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
Fioccola, et al. Expires April 25, 2022 [Page 7]
Internet-Draft COAP PM October 2021
[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>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
Authors' Addresses
Giuseppe Fioccola
Huawei
Riesstrasse, 25
Munich 80992
Germany
Email: giuseppe.fioccola@huawei.com
Tianran Zhou
Huawei
156 Beiqing Rd.
Beijing 100095
China
Email: zhoutianran@huawei.com
Mauro Cociglio
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: mauro.cociglio@telecomitalia.it
Fabio Bulgarella
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: fabio.bulgarella@guest.telecomitalia.it
Fioccola, et al. Expires April 25, 2022 [Page 8]
Internet-Draft COAP PM October 2021
Massimo Nilo
Telecom Italia
Via Reiss Romoli, 274
Torino 10148
Italy
Email: massimo.nilo@telecomitalia.it
Fioccola, et al. Expires April 25, 2022 [Page 9]