idnits 2.17.00 (12 Aug 2021) /tmp/idnits65309/draft-fz-core-coap-pm-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (February 9, 2022) is 94 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-ietf-ippm-explicit-flow-measurements-00 == Outdated reference: A later version (-16) exists of draft-ietf-quic-manageability-14 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE Working Group G. Fioccola 3 Internet-Draft T. Zhou 4 Intended status: Standards Track Huawei 5 Expires: August 13, 2022 M. Cociglio 6 F. Bulgarella 7 M. Nilo 8 Telecom Italia 9 February 9, 2022 11 Constrained Application Protocol (CoAP) Performance Measurement Option 12 draft-fz-core-coap-pm-01 14 Abstract 16 This document specifies a method for the Performance Measurement of 17 the Constrained Application Protocol (CoAP). A new CoAP option is 18 defined in order to enable network telemetry both end-to-end and on- 19 path. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 13, 2022. 44 Copyright Notice 46 Copyright (c) 2022 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Performance Measurement methods for CoAP . . . . . . . . . . 3 63 3. CoAP Performance Measurement Option . . . . . . . . . . . . . 4 64 4. Structure of the PM Option . . . . . . . . . . . . . . . . . 5 65 5. Application Scenarios . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 9.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 74 1. Introduction 76 [RFC7252] define the CoAP Protocol. In CoAP, reliability is provided 77 by marking a message as Confirmable (CON) with ACKs. A message that 78 does not require reliable transmission can be sent as a Non- 79 confirmable message (NON). 81 In case of CoAP reliable mode there are Message IDs and ACKs, that 82 could eventually be used to measure Round-Trip Time (RTT) and losses. 83 But it is resource-consuming for constrained nodes since they have to 84 look at Message IDs and take timestamps. These operations are 85 expensive in terms of resources. In case of CoAP unreliable mode, 86 there is no ACK and, consequently, it is not possible to measure RTT 87 and losses. 89 Thus, there is no easy way to measure the performance metrics in COAP 90 environment to satisfy the low resources of constrained nodes. And 91 it is in any case limited to RTT and end-to-end losses. 93 A mechanism to measure the performance in CoAP can be useful to 94 verify and meet the operational requirements, but it should be a 95 simple mechanism for network diagnostic to be developed on 96 constrained nodes requiring just a minimal amount of collaboration 97 from the endpoints. 99 [I-D.ietf-ippm-explicit-flow-measurements] describes the 100 methodologies for Explicit Flow Measurement (EFM). The EFM 101 techniques employ few marking bits, inside the header of each packet, 102 for loss and delay measurement. These are relevant for encrypted 103 protocols, e.g. QUIC [RFC9000], where there are only few bits 104 available in the non-encrypted header in order to allow passive 105 performance metrics from an on-path observer. These methodologies 106 could potentially be used and extended in CoAP. 108 [I-D.ietf-ippm-explicit-flow-measurements] defines different 109 combinations of bits because the number of bits in QUIC is limited 110 and different experiments have been done. But all these methods 111 together imply complex algorithms that do not apply well to the CoAP 112 environment. 114 This document aims to create an easy way to allow performance 115 measurement for CoAP, by defining a new option, called Performance 116 Measurement (PM) CoAP Option. The CoAP performance metrics (e.g. 117 RTT and losses) can be useful for an operator or an enterprise that 118 is managing a constrained, low-power and lossy network. 120 2. Performance Measurement methods for CoAP 122 CoAP [RFC7252] defines a number of options that can be included in a 123 message. For this reason, a new option for CoAP, carrying 124 Performance Measurement (PM) bits is the approach followed by this 125 document. 127 The PM bits that are included in the Option are: 129 o sQuare bit (Q bit), based on [RFC8321] and further described in 130 [I-D.ietf-ippm-explicit-flow-measurements]; 132 o Spin bit (S bit), described in [I-D.ietf-quic-manageability] and 133 included as optional bit in [RFC9000]; 135 o Loss and Delay event information for further usage. 137 A requirement to enable PM methods in COAP environment is that the 138 methodologies and the algorithm needs to be kept simple. For this 139 reason, the idea is to re-apply only the S bit and Q bit. 141 The sQuare bit algorithm is to create square waves of a known length 142 (e.g. 64 packets). Each side of the connection can set the Q bit and 143 toggle its value every fixed number of packets. The number of 144 packets can be easily recognized and packet loss can be measured. 146 The Spin bit algorithm is to create a square wave signal on the data 147 flow, using a bit, whose length is equal to RTT. The Spin bit causes 148 one bit to 'spin', generating one edge (a transition from 0 to 1 or 149 from 1 to 0) once per end-to-end RTT. The Spin bit is set by both 150 sides to the same value for as long as one round trip lasts and then 151 it toggles the value. 153 The synergy between S bit and Q bit is also possible. As described 154 above, the length of the Q bit square waves is fixed (e.g. a 155 predefined number of packets) in this way each endpoint can detect a 156 packet loss if it receives less packets than expected. In addition, 157 it is possible to potentiate the Q bit signal by incorporating RTT 158 information as well. This implies a little modification to the 159 algorithm of the Q bit that could also be used alone: 161 One packet in a period of the square wave can be selected and set 162 to the opposite value of that period. After one RTT it comes back 163 and another packet is selected and set again to the opposite value 164 of that period. And the process can start again. By measuring 165 the distance between these special packets it is possible to 166 measure the RTT in addition to packet loss. The periods with the 167 special packets have one packet less than expected but this is 168 easy to recognize by both endpoints. 170 So, with one bit, it can be possible to measure loss and delay. This 171 can be used to reinforce the Spin Bit mechanism or to use only one 172 bit (sQuare bit) in the Option. 174 The advantages of using the CoAP PM Option are: 176 1) Simplification because it is not needed to read Message IDs, 177 indeed there is a well-defined sQuare wave, and it is not 178 necessary to store timestamps, since the duration of the Spin Bit 179 period is equal to RTT. 181 2) Enabling easy on-path observer (proxy, gateway) metrics. 183 3. CoAP Performance Measurement Option 185 Figure 1 shows the property of the CoAP Performance Measurement (PM) 186 Option. The formatting of this table is reported in [RFC7252]. The 187 C, U, N, and R columns indicate the properties Critical, Unsafe, 188 NoCacheKey, and Repeatable as defined in [RFC7252]. None of these 189 properties is marked for the PM options. 191 +--------+---+---+---+---+--------+--------+--------+---------+ 192 | Number | C | U | N | R | Name | Format | Length | Default | 193 +========+===+===+===+===+========+========+========+=========+ 194 | TBD | | | | | PM | uint | 1 | 0 | 195 +--------+---+---+---+---+--------+--------+--------+---------+ 197 Figure 1: CoAP PM Option Properties 199 Note that it could be possible to make use of one bit in the option 200 to identify the mode. In this way two patterns can be defined. 202 4. Structure of the PM Option 204 The value of the PM option is a 1 byte unsigned integer. This 205 integer value encodes the following fields: 207 0 208 0 1 2 3 4 5 6 7 209 +-+-+-+-+-+-+-+-+ 210 |M| Pattern | 211 +-+-+-+-+-+-+-+-+ 213 Figure 2: CoAP Performance Measurement Option 215 Where: 217 o M bit can be set to 1 or 0 and it is used to identify whether the 218 Option follows pattern 1 (M bit = 0) or pattern 2 (M bit = 1). 220 o Pattern bits can be of two kinds as reported below. 222 The PM Option can employ two patterns based on the value of the M 223 bit: 225 0 226 0 1 2 3 4 5 6 7 227 +-+-+-+-+-+-+-+-+ 228 |0|Q| Event | 229 +-+-+-+-+-+-+-+-+ 231 Figure 3: CoAP Performance Measurement Option pattern 1 232 0 233 0 1 2 3 4 5 6 7 234 +-+-+-+-+-+-+-+-+ 235 |1|Q|S| Event | 236 +-+-+-+-+-+-+-+-+ 238 Figure 4: CoAP Performance Measurement Option pattern 2 240 The COAP Option could be defined with 2 PM bits (S and Q) or defined 241 with a single PM bit (Q bit). 243 Where: 245 o Q bit is used in both pattern 1 and pattern 2. It is described in 246 [I-D.ietf-ippm-explicit-flow-measurements] and enhanced with the 247 method described in Section 2; 249 o S bit is used in Option 2. It is also embedded in the QUIC 250 Protocol [RFC9000]; 252 o Event bits MAY encode additional Loss and Delay information based 253 on well-defined encoding and they can also be used by on-path 254 observers. If these Event bits are all zero, they MUST be ignored 255 on receipt. 257 As an example the Event bits can be divided into two parts: loss 258 event bits and delay event bits. Based on the average RTT, an end 259 point can define different levels of thresholds and set the delay 260 event bits accordingly. The same applies to loss event bits. In 261 this way an on-path observer becomes aware of the network conditions 262 by simply reading these Event bits. 264 The on-path observer can read the event signaling bits and could be 265 the Proxy or the Gateway which interconnects disjointed CoAP 266 networks. It MAY communicate with Client and Server to set some 267 parameters such as timeout based on the network performance. 269 The CoAP PM Options described in this document can be used in both 270 requests and responses. If a CoAP endpoint does not implement the 271 measurement methodologies, it can simply leave the default value (all 272 bits are zero). In this way the other CoAP endpoints become aware 273 that the measurement cannot be executed in that case. 275 The fixed number of packets to create the Q bit signal is predefined 276 and its value is configured from the beginning for all the CoAP 277 endpoints. 279 5. Application Scenarios 281 The main usage of the CoAP PM Options is to do end-to-end measurement 282 between the client and the server but it can also allow split 283 measurements. The on-path measurement is the additional feature. 284 This information can be used to monitor the network in order to check 285 the operational performance and to employ further network 286 optimization. 288 The intermediaries or on-path observers could be: 290 Network Functions or Probes that must be able to see deep into 291 application. 293 Gateway or Proxies that, as specified in [RFC7252], are CoAP 294 endpoints tasked by CoAP clients to perform requests on their 295 behalf. 297 If the on-path observers are network functions or probes, the CoAP PM 298 Option can be applied end-to-end between client and server. The on- 299 path network probes can read Q bit and S bit and implement the 300 relevant algorithms to measure losses and RTT. Otherwise they can 301 simply read the Event bits and be informed about the performance 302 without implementing any algorithm. The event signaling bits can be 303 sent from the Server (that can do the performance measurement 304 calculation) to the Client, or viceversa. 306 If the on-path observers are CoAP proxies, the CoAP PM Option can 307 only be applied to the different separate connections between client 308 and server instead of end-to-end. Indeed, CoAP proxies hide the 309 identity of the client and could also apply caching. Thus, on the 310 server side, the data would appear mixed in presence of more than one 311 client, and clients would receive mixed signals in presence of cache 312 entries. But in this case, the measurements can be segmented and 313 done between the Proxies or between a Proxy and the Client or between 314 a Proxy and the Server. The Server can distinguish the source client 315 by using additional flow information such as the IP addresses. It 316 could also be possible to bundle different clients if they are mixed. 317 So, it is worth highlighting that an on-path observer can find useful 318 information both on the proxy-server link and on the client-proxy 319 link: 321 On the link from a proxy to the server, traffic from different 322 clients would be mixed. In this case, the proxy can still use the 323 PM Option to set S bit and Q bit for the bundle of clients for a 324 specific server. The measurement can be done but it is an 325 information related to a bundle of clients. An alternative can be 326 to use the Option only for a single client at once in order to 327 avoid to do a grouped measurement. 329 Conversely, on the link from the client to the proxy, 330 communication may happen with different servers, and in this case 331 it is necessary to check the other fields to understand the 332 server. 334 In summary, a typical CoAP scenario can be the following: 336 Devices -- Gateway/Proxy -- Transport Network -- Probe (or Proxy) -- 337 Server/Data Center 339 If the CoAP PM Option is applied between devices and the server 340 (across intermediaries), the Probe can measure the total RTT by using 341 the Spin bit, indeed it allows RTT measurement for all the 342 intermediate points. But, with sQuare Bit and by applying the 343 methodologies in [RFC8321], it is also possible to do hop-by-hop 344 measurements for loss and delay and segment where possible. 346 If there is a CoAP proxy, the measurement can be done between the 347 Proxies or between a Proxy and the Client or between a Proxy and the 348 Server. It can be done through Spin bit or by applying [RFC8321] on 349 the sQuare Bit signal. 351 6. Security Considerations 353 Security considerations related to CoAP proxying are discussed in 354 [RFC7252]. 356 A CoAP endpoint can use the CoAP PM Options to affect the measures of 357 a network into which it is making requests by maliciously modifying 358 the value of the option. Also, the PM bits may reveal performance 359 information outside the administrative domain. To prevent that, a 360 CoAP proxy that is located at the boundary of an administrative 361 domain MAY be instructed to strip the payload or part of it before 362 forwarding the message. 364 It is worth highlighting what happens if devices, transport network 365 and server are operated by different administrative domains. 366 Security concerns need to be taken into account, but OSCORE [RFC8613] 367 can be used and the CoAP PM options can be integrity protected end- 368 to-end by OSCORE. Then the operators can put their measurement 369 probes in one or more places to break down the different RTT and loss 370 contributions where it is relevant (e.g., at the ingress/egress of 371 their respective network segments). OSCORE ensures end-to-end 372 integrity protection and would tell the endpoints if someone 373 tampered, but it doesn't mean that the endpoints are not lying to the 374 observer. However it is possible to assume that for the typical COAP 375 applications it is less likely that the endpoints are attackers while 376 it is more likely that an on-path observer is the attacker. 378 7. IANA Considerations 380 IANA is requested to add the following entry to the "CoAP Option 381 Numbers" sub-registry available at https://www.iana.org/assignments/ 382 core-parameters/core-parameters.xhtml#option-numbers: 384 Number Name Reference 385 --------------------------------------------- 386 TBD PM Option [This draft] 388 Figure 5: CoAP PM Option Numbers 390 8. Acknowledgements 392 The authors would like to thank Christian Amsuess and Thomas Fossati 393 for the precious comments and suggestions. 395 9. References 397 9.1. Normative References 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels", BCP 14, RFC 2119, 401 DOI 10.17487/RFC2119, March 1997, 402 . 404 9.2. Informative References 406 [I-D.ietf-ippm-explicit-flow-measurements] 407 Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I., 408 Bulgarella, F., Hamchaoui, I., Nilo, M., Sisto, R., and D. 409 Tikhonov, "Explicit Flow Measurements Techniques", draft- 410 ietf-ippm-explicit-flow-measurements-00 (work in 411 progress), October 2021. 413 [I-D.ietf-quic-manageability] 414 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 415 Transport Protocol", draft-ietf-quic-manageability-14 416 (work in progress), January 2022. 418 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 419 Application Protocol (CoAP)", RFC 7252, 420 DOI 10.17487/RFC7252, June 2014, 421 . 423 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 424 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 425 "Alternate-Marking Method for Passive and Hybrid 426 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 427 January 2018, . 429 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 430 "Object Security for Constrained RESTful Environments 431 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 432 . 434 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 435 Multiplexed and Secure Transport", RFC 9000, 436 DOI 10.17487/RFC9000, May 2021, 437 . 439 Authors' Addresses 441 Giuseppe Fioccola 442 Huawei 443 Riesstrasse, 25 444 Munich 80992 445 Germany 447 Email: giuseppe.fioccola@huawei.com 449 Tianran Zhou 450 Huawei 451 156 Beiqing Rd. 452 Beijing 100095 453 China 455 Email: zhoutianran@huawei.com 457 Mauro Cociglio 458 Telecom Italia 459 Via Reiss Romoli, 274 460 Torino 10148 461 Italy 463 Email: mauro.cociglio@telecomitalia.it 464 Fabio Bulgarella 465 Telecom Italia 466 Via Reiss Romoli, 274 467 Torino 10148 468 Italy 470 Email: fabio.bulgarella@guest.telecomitalia.it 472 Massimo Nilo 473 Telecom Italia 474 Via Reiss Romoli, 274 475 Torino 10148 476 Italy 478 Email: massimo.nilo@telecomitalia.it