idnits 2.17.00 (12 Aug 2021) /tmp/idnits59293/draft-fz-core-coap-pm-00.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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2021) is 211 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 (-16) exists of draft-ietf-quic-manageability-13 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: April 25, 2022 M. Cociglio 6 F. Bulgarella 7 M. Nilo 8 Telecom Italia 9 October 22, 2021 11 Constrained Application Protocol (CoAP) Performance Measurement Option 12 draft-fz-core-coap-pm-00 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. The presence of the 19 on-path observer is also considered. 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 April 25, 2022. 44 Copyright Notice 46 Copyright (c) 2021 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. On-path Observers . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 9.2. Informative References . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 [I-D.mdt-ippm-explicit-flow-measurements] reported a summary on the 94 methodologies for Explicit Flow Measurement (EFM). These EFM 95 techniques could potentially be used in CoAP. These methodologies 96 employ few marking bits, inside the header of each packet, for loss 97 and delay measurement. These are relevant for encrypted protocols, 98 e.g. QUIC [RFC9000], where there are only few bits available in the 99 non-encrypted header in order to allow passive performance metrics 100 from an on-path observer. 102 [I-D.mdt-ippm-explicit-flow-measurements] defines different 103 combinations of bits because the number of bits in QUIC is limited 104 and different experiments have been done. But all these methods 105 together imply complex algorithms that do not apply well to the CoAP 106 environment. 108 This document aims to create an easy way to allow performance 109 measurement for CoAP, by defining a new option, called Performance 110 Measurement (PM) CoAP Option. 112 2. Performance Measurement methods for CoAP 114 CoAP [RFC7252] defines a number of options that can be included in a 115 message. For this reason, a new option for CoAP, carrying 116 Performance Measurement (PM) bits is the approach followed by this 117 document. 119 The PM bits that are included in the Option are: 121 o sQuare bit (Q bit), based on [RFC8321] and further described in 122 [I-D.mdt-ippm-explicit-flow-measurements]; 124 o Spin bit (S bit), described in [I-D.ietf-quic-manageability] and 125 included as optional bit in [RFC9000]; 127 o Loss and Delay event information for further usage. 129 A requirement to enable PM methods in COAP environment is that the 130 methodologies and the algorithm needs to be kept simple. For this 131 reason, the idea is to re-apply only the S bit and Q bit. 133 The sQuare bit algorithm is to create square waves of a known length 134 (e.g. 64 packets). Each side of the connection can set the Q bit and 135 toggle its value every fixed number of packets. The number of 136 packets can be easily recognized and packet loss can be measured. 138 The Spin bit algorithm is to create a square wave signal on the data 139 flow, using a bit, whose length is equal to RTT. The Spin bit causes 140 one bit to 'spin', generating one edge (a transition from 0 to 1 or 141 from 1 to 0) once per end-to-end RTT. The Spin bit is set by both 142 sides to the same value for as long as one round trip lasts and then 143 it toggles the value. 145 The synergy between S bit and Q bit is also possible. As described 146 above, the length of the Q bit square waves is fixed (e.g. a 147 predefined number of packets) in this way each endpoint can detect a 148 packet loss if it receives less packets than expected. In addition, 149 it is possible to potentiate the Q bit signal by incorporating RTT 150 information as well. This implies a little modification to the 151 algorithm of the Q bit that could also be used alone: 153 One packet in a period of the square wave can be selected and set 154 to the opposite value of that period. After one RTT it comes back 155 and another packet is selected and set again to the opposite value 156 of that period. And the process can start again. By measuring 157 the distance between these special packets it is possible to 158 measure the RTT in addition to packet loss. The periods with the 159 special packets have one packet less than expected but it is easy 160 to recognize by both endpoints. 162 So, with one bit, it can be possible to measure loss and delay. This 163 can be used to reinforce the Spin Bit mechanism or to use only one 164 bit (sQuare bit) in the Option. 166 The advantages of using the CoAP PM Option are: 168 1) Simplification because it is not needed to read Message IDs, 169 indeed there is a well-defined sQuare wave, and it is not 170 necessary to store timestamps, since the duration of the Spin Bit 171 period is equal to RTT. 173 2) Enabling easy on-path observer (proxy, gateway) metrics. 175 3. CoAP Performance Measurement Option 177 Figure 1 shows the property of the CoAP Performance Measurement (PM) 178 Option. The formatting of this table is reported in [RFC7252]. The 179 C, U, N, and R columns indicate the properties Critical, Unsafe, 180 NoCacheKey, and Repeatable as defined in [RFC7252]. None of these 181 properties is marked for the PM options. 183 +--------+---+---+---+---+--------+--------+--------+---------+ 184 | Number | C | U | N | R | Name | Format | Length | Default | 185 +========+===+===+===+===+========+========+========+=========+ 186 | TBD | | | | | PM | uint | 1 | 0 | 187 +--------+---+---+---+---+--------+--------+--------+---------+ 189 Figure 1: CoAP PM Option Properties 191 Note that it could be possible to make use of one bit in the option 192 to identify the mode. In this way two patterns can be defined. 194 4. Structure of the PM Option 196 The value of the PM option is a 1 byte unsigned integer. This 197 integer value encodes the following fields: 199 0 200 0 1 2 3 4 5 6 7 201 +-+-+-+-+-+-+-+-+ 202 |M| Pattern | 203 +-+-+-+-+-+-+-+-+ 205 Figure 2: CoAP Performance Measurement Option 207 Where: 209 o M bit can be set to 1 or 0 and it is used to identify whether the 210 Option follows pattern 1 (M bit = 0) or pattern 2 (M bit = 1). 212 o Pattern bits can be of two kinds as reported below. 214 The PM Option can employ two patterns based on the value of the M 215 bit: 217 0 218 0 1 2 3 4 5 6 7 219 +-+-+-+-+-+-+-+-+ 220 |0|Q| Event | 221 +-+-+-+-+-+-+-+-+ 223 Figure 3: CoAP Performance Measurement Option pattern 1 225 0 226 0 1 2 3 4 5 6 7 227 +-+-+-+-+-+-+-+-+ 228 |1|Q|S| Event | 229 +-+-+-+-+-+-+-+-+ 231 Figure 4: CoAP Performance Measurement Option pattern 2 233 The COAP Option could be defined with 2 PM bits (S and Q) or defined 234 with a single PM bit (Q bit). 236 Where: 238 o Q bit is used in both pattern 1 and pattern 2. It is described in 239 [I-D.mdt-ippm-explicit-flow-measurements] and enhanced with the 240 method described in Section 2; 242 o S bit is used in Option 2. It is also embedded in the QUIC 243 Protocol [RFC9000]; 245 o Event bits MAY encode additional Loss and Delay information based 246 on well-defined encoding and they can also be used by on-path 247 observers. 249 The CoAP PM Options described in this document can be used in both 250 requests and responses. If a CoAP endpoint does not implement the 251 measurement methodologies, it can simply leave the default value (all 252 bits are zero). In this way the other CoAP endpoints become aware 253 that the measurement cannot be executed in that case. 255 The fixed number of packets to create the Q bit signal is predefined 256 and its value is configured from the beginning for all the CoAP 257 endpoints. 259 5. On-path Observers 261 An on-path observer SHOULD be able to see deep into application and 262 it can be a COAP Proxy or Gateway. The on-path observers can read Q 263 bit and S bit and apply the relevant algorithms to measure Losses and 264 RTT. Otherwise they can simply read the event bits and be informed 265 about the performance without applying any algorithm. The event 266 signaling bits can be sent from the Server (that can do the 267 performance measurement calculation) to the Client, or viceversa. 269 As an example the Event bits can be divided into two parts: loss 270 event bits and delay event bits. Based on the average RTT, an end 271 point can define different levels of thresholds and set the delay 272 event bits accordingly. The same applies to loss event bits. In 273 this way an on-path observer becomes aware of the network conditions 274 by simply reading these Event bits. 276 The on-path observer can read the event signaling bits and could be 277 the Proxy or the Gateway which interconnects disjointed CoAP 278 networks. It MAY communicate with Client and Server to set some 279 parameters such as timeout based on the network performance. 281 6. Security Considerations 283 Security considerations related to CoAP proxying are discussed in 284 [RFC7252]. 286 A CoAP endpoint can use the CoAP PM Options to affect the measures of 287 a network into which it is making requests by maliciously modifying 288 the value of the option. Also, the PM bits may reveal performance 289 information outside the administrative domain. To prevent that, a 290 CoAP proxy that is located at the boundary of an administrative 291 domain MAY be instructed to strip the payload or part of it before 292 forwarding the message. 294 7. IANA Considerations 296 IANA is requested to add the following entry to the "CoAP Option 297 Numbers" sub-registry available at https://www.iana.org/assignments/ 298 core-parameters/core-parameters.xhtml#option-numbers: 300 Number Name Reference 301 --------------------------------------------- 302 TBD PM Option [This draft] 304 Figure 5: CoAP PM Option Numbers 306 8. Acknowledgements 308 TBD 310 9. References 312 9.1. Normative References 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, 316 DOI 10.17487/RFC2119, March 1997, 317 . 319 9.2. Informative References 321 [I-D.ietf-quic-manageability] 322 Kuehlewind, M. and B. Trammell, "Manageability of the QUIC 323 Transport Protocol", draft-ietf-quic-manageability-13 324 (work in progress), September 2021. 326 [I-D.mdt-ippm-explicit-flow-measurements] 327 Cociglio, M., Ferrieux, A., Fioccola, G., Lubashev, I., 328 Bulgarella, F., Hamchaoui, I., Nilo, M., Sisto, R., and D. 329 Tikhonov, "Explicit Flow Measurements Techniques", draft- 330 mdt-ippm-explicit-flow-measurements-02 (work in progress), 331 July 2021. 333 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 334 Application Protocol (CoAP)", RFC 7252, 335 DOI 10.17487/RFC7252, June 2014, 336 . 338 [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, 339 L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, 340 "Alternate-Marking Method for Passive and Hybrid 341 Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, 342 January 2018, . 344 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 345 Multiplexed and Secure Transport", RFC 9000, 346 DOI 10.17487/RFC9000, May 2021, 347 . 349 Authors' Addresses 351 Giuseppe Fioccola 352 Huawei 353 Riesstrasse, 25 354 Munich 80992 355 Germany 357 Email: giuseppe.fioccola@huawei.com 359 Tianran Zhou 360 Huawei 361 156 Beiqing Rd. 362 Beijing 100095 363 China 365 Email: zhoutianran@huawei.com 367 Mauro Cociglio 368 Telecom Italia 369 Via Reiss Romoli, 274 370 Torino 10148 371 Italy 373 Email: mauro.cociglio@telecomitalia.it 375 Fabio Bulgarella 376 Telecom Italia 377 Via Reiss Romoli, 274 378 Torino 10148 379 Italy 381 Email: fabio.bulgarella@guest.telecomitalia.it 382 Massimo Nilo 383 Telecom Italia 384 Via Reiss Romoli, 274 385 Torino 10148 386 Italy 388 Email: massimo.nilo@telecomitalia.it