idnits 2.17.00 (12 Aug 2021) /tmp/idnits49379/draft-irtf-icnrg-ccnx-timetlv-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(393): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 5 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8609], [IEEE.754.2019], [RFC5497]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (27 April 2022) is 17 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 300 -- Looks like a reference, but probably isn't: '255' on line 300 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG C. Gündoğan 3 Internet-Draft TC. Schmidt 4 Intended status: Experimental HAW Hamburg 5 Expires: 29 October 2022 D. Oran 6 Network Systems Research and Design 7 M. Waehlisch 8 link-lab & FU Berlin 9 27 April 2022 11 Alternative Delta Time Encoding for CCNx Using Compact Floating-Point 12 Arithmetic 13 draft-irtf-icnrg-ccnx-timetlv-00 15 Abstract 17 CCNx utilizes delta time for a number of functions. When using CCNx 18 in environments with constrained nodes or bandwidth constrained 19 networks, it is valuable to have a compressed representation of delta 20 time. In order to do so, either accuracy or dynamic range has to be 21 sacrificed. Since the current uses of delta time do not require both 22 simultaneously, one can consider a logarithmic encoding such as that 23 specified in [RFC5497] and [IEEE.754.2019]. This document updates 24 _CCNx messages in TLV Format_ [RFC8609] to specify this alternative 25 encoding. 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 29 October 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 (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Revised BSD License text as 55 described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Revised BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Usage of Time Values in CCNx . . . . . . . . . . . . . . . . 3 63 3.1. Relative Time in CCNx . . . . . . . . . . . . . . . . . . 3 64 3.2. Absolute Time in CCNx . . . . . . . . . . . . . . . . . . 3 65 4. A Compact Time Representation with Logarithmic Range . . . . 4 66 5. Protocol Integration of the Compact Time Representation . . . 6 67 5.1. Interest Lifetime . . . . . . . . . . . . . . . . . . . . 7 68 5.2. Recommended Cache Time . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 8.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10 75 Appendix B. Efficient Time Value Approximation . . . . . . . . . 11 76 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 CCNx utilizes time values for a number of functions. Some of these 82 are expressed as absolute time, others as delta time. CCNx is well 83 suited for Internet of Things (IoT) applications [RFC7927]. When 84 using CCNx in environments with constrained nodes or bandwidth 85 constrained networks, it is valuable to have a compact representation 86 of time values. For example [RFC9139] and [ICNLOWPAN] specify a 87 compression scheme useful over IEEE 802.15.4 networks. However, any 88 compact time representation has to sacrifice accuracy or dynamic 89 range. For some time uses this is relatively straightforward to 90 achieve, for other uses, it is not. This document discusses the 91 various cases, and proposes a compact encoding that is easily 92 accommodated for delta times. 94 2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 This document uses the terminology of [RFC8569] and [RFC8609] for 101 CCNx entities. 103 The following terms are used in the document and defined as follows: 105 byte: synonym for octet 107 time value: a time offset measured in seconds 109 time code: an 8-bit encoded time value 111 3. Usage of Time Values in CCNx 113 3.1. Relative Time in CCNx 115 CCNx, as currently specified in [RFC8569], utilizes delta time for 116 only the lifetime of an Interest message (see sections 2.1, 2.2, 117 2.4.2, 10.3 of [RFC8569]). It is a hop-by-hop header value, and is 118 currently encoded via the T_INTLIFE TLV as a 64-bit integer 119 ([RFC8609] section 3.4.1). While formally an optional TLV, in all 120 but some corner cases every Interest message is expected to carry the 121 Interest Lifetime TLV, and hence having compact encoding is 122 particularly valuable for keeping Interest messages short. 124 Since the current uses of delta time do not require both accuracy and 125 dynamic range simultaneously, one can consider a logarithmic encoding 126 such as that specified in [IEEE.754.2019] and outlined in Section 4. 127 This document updates _CCNx messages in TLV Format_ [RFC8609] to 128 permit this alternative encoding for selected time values. See 129 Section 6 for the specific actions needed to register this 130 alternative compact representation of Interest Lifetime. 132 3.2. Absolute Time in CCNx 134 CCNx, as currently specified in [RFC8569], utilizes absolute time for 135 various important functions. Each of these absolute time usages 136 poses a different challenge for a compact representation. These are 137 discussed in the following subsections. 139 3.2.1. Signature Time and Expiry Time 141 _Signature Time_ is the time the signature of a content object was 142 generated (sections 8.2-8.4 [RFC8569]). _Expiry Time_ indicates the 143 expiry time of a content object (section 4 [RFC8569]). Both values 144 are content message TLVs and represent absolute timestamps in 145 milliseconds since the UTC epoch (i.e., an NTP timestamp). They are 146 currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit 147 unsigned integers (see section 3.6.4.1.4.5 and 3.6.2.2.2 [RFC8609]). 149 Both time values could be in the past, or in the future, potentially 150 by a large delta. They are also included in the security envelope of 151 the message. Therefore, it seems there is no practical way to define 152 an alternative compact encoding that preserves its semantics and 153 security properties; hence we don't consider it further as a 154 candidate. 156 3.2.2. Recommended Cache Time 158 _Recommended Cache Time_ (RCT) for a content object (see section 4 159 [RFC8569]) is a hop-by-hop header stating the expiration time for a 160 cached content object in milliseconds since the UTC epoch (i.e., an 161 NTP timestamp). It is currently encoded via the T_CACHETIME TLV as a 162 64-bit unsigned integer (see section 3.4.2 [RFC8609]). 164 A recommended cache time could be far in the future, but cannot be in 165 the past and is likely to be a reasonably short offset from the 166 current time. Therefore, this document allows the recommended cache 167 time to be interpreted as a relative time value rather than an 168 absolute time, since the semantics associated with an absolute time 169 value do not seem to be critical to the utility of this value. This 170 document therefore updates the recommended cache time with the 171 following rule set: 173 * Use absolute time as per [RFC8609] 175 * Use relative time, if the compact time representation is used (see 176 Section 4 and Section 5) 178 4. A Compact Time Representation with Logarithmic Range 180 This document uses the compact time representation of ICNLoWPAN (see 181 section 7 of [RFC9139]) that is inspired by [RFC5497] and 182 [IEEE.754.2019]. Its logarithmic encoding supports a representation 183 ranging from milliseconds to years. Figure 1 depicts the logarithmic 184 nature of this time representation. 186 || | | | | | | | | | | 187 +-----------------------------------------------------------------+ 188 milliseconds years 190 Figure 1: A logarithmic range representation allows for higher 191 precision in the smaller time ranges and still supports large 192 time deltas. 194 Time codes encode exponent and mantissa values in a single byte, but 195 in contrast to the representation in [IEEE.754.2019], time codes only 196 encode positive numbers and hence do not include an extra sign bit. 197 Figure 2 shows the configuration of a time code: an exponent width of 198 5 bits, and a mantissa width of 3 bits. 200 <--- one byte wide ---> 201 +----+----+----+----+----+----+----+----+ 202 | exponent (b) | mantissa (a) | 203 +----+----+----+----+----+----+----+----+ 204 0 1 2 3 4 5 6 7 206 Figure 2: A time code with exponent and mantissa to encode a 207 logarithmic range time representation. 209 The base unit for time values are seconds. A time value is 210 calculated using the following formula (adopted from [RFC5497] and 211 [RFC9139]), where (a) represents the mantissa, (b) the exponent, and 212 (C) a constant factor set to C := 1/32. 214 Subnormal (b == 0): (0 + a/8) * 2 * C 216 Normalized (b > 0): (1 + a/8) * 2^b * C 218 The subnormal form provides a gradual underflow between zero and the 219 smallest normalized number. Eight time values exist in the subnormal 220 range [0s,~0.054688s] with a step size of ~0.007812s between each 221 time value. This configuration also encodes the following convenient 222 numbers in seconds: [1, 2, 4, 8, 16, 32, 64, ...]. Appendix A 223 further includes test vectors to illustrate the logarithmic range. 225 An example algorithm to encode a time value into the corresponding 226 exponent and mantissa is given as pseudo code in Figure 3. Not all 227 time values can be represented by a time code. For these instances, 228 the closest time code is chosen that is smaller than the value to 229 encode. 231 input: float v // time value 232 output: int a, b // mantissa, exponent of time code 234 (a, b) encode (v): 236 if (v == 0) 237 return (0, 0) 239 if (v < 2 * C) // subnormal 240 a = floor (v * 4 / C) // round down 241 return (a, 0) 242 else // normalized 243 if (v > (1 + 7/8) * 2^31 * C) // check bounds 244 return (7, 31) // return maximum 245 else 246 b = floor (log2(v / C)) // round down 247 a = floor ((v / (2^b * C) - 1) * 8) // round down 248 return (a, b) 250 Figure 3: Algorithm in pseudo code. 252 As an example: No specific time code for 0.063 exists, but this 253 algorithm maps to the closest valid time code that is smaller, i.e., 254 exponent 1 and mantissa 0 (the same as for time value 0.0625). 256 5. Protocol Integration of the Compact Time Representation 258 A straightforward way to accommodate the compact time approach is to 259 use a 1-byte length field to indicate this alternative encoding while 260 retaining the existing TLV registry entries. This approach has 261 backward compatibility problems, but may still be considered for the 262 following reasons: 264 * Both CCNx RFCs are experimental and not Standards Track, hence 265 expectations for forward and backward compatibility are not as 266 stringent. "Flag day" upgrades of deployed CCNx networks, while 267 inconvenient, are still feasible. 269 * The major use case for these compressed encodings are smaller- 270 scale IoT and/or sensor networks where the population of 271 consumers, producers, and forwarders is reasonably small. 273 * Since the current TLVs have hop-by-hop semantics, they are not 274 covered by any signed hash and hence may be freely re-encoded by 275 any forwarder. That means a forwarder supporting the new encoding 276 can translate freely between the two encodings. 278 * The alternative of assigning new TLV registry values does not 279 substantially mitigate the interoperability problems anyway. 281 The following lists alternative approaches of integrating the compact 282 time representation for time offsets in CCNx messages. A further 283 analysis, discussion, and decision on the best suited approach will 284 be added as the document progresses. 286 1. Relative time TLVs (e.g., T_INTLIFETIME) include nested TLVs to 287 hint at the used encoding. This approach allows for versatility 288 in defining new time encodings, but adds a TLV overhead that 289 negates the benefits of the compact time representation. 291 2. A new TLV type for the compact time representation is defined 292 (T_INTLIFETIME_COMPACT). The packet header grammar from 293 [RFC8609] is updated to allow for T_INTLIFETIME_COMPACT at the 294 same level of the currently defined T_INTLIFETIME. 296 5.1. Interest Lifetime 298 The Interest Lifetime definition in [RFC8609] allows for a variable- 299 length lifetime representation, where a length of 1 encodes the 300 linear range [0,255] in milliseconds. This document changes the 301 definition to always encode 1-byte Interest lifetime values in the 302 compact time value representation (Figure 4). 304 1 2 3 305 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 306 +---------------+---------------+---------------+---------------+ 307 | T_INTLIFE | Length = 1 | 308 +---------------+---------------+---------------+---------------+ 309 | COMPACT_TIME | 310 +---------------+ 311 1 2 3 312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 313 +---------------+---------------+---------------+---------------+ 314 | T_INTLIFE | Length > 1 | 315 +---------------+---------------+---------------+---------------+ 316 / / 317 / Lifetime (Length octets) / 318 / / 319 +---------------+---------------+---------------+---------------+ 321 Figure 4: Changes to the definition of the Interest Lifetime TLV. 323 A note on legacy forwarders: A forwarder that does not support this 324 compact time representation will interpret the time value as an 325 Interest lifetime between 0 and 255 milliseconds. This may lead to a 326 degradation of network performance, since Pending Interest 327 Table (PIT) entries timeout quicker than expected. 329 5.2. Recommended Cache Time 331 The Recommended Cache Time definition in [RFC8609] specifies an 332 absolute time representation that is of a length fixed to 8 bytes. 333 This document changes the definition to always encode 1-byte 334 Recommended Cache Time values in the compact relative time value 335 representation (Figure 5). 337 1 2 3 338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 339 +---------------+---------------+---------------+---------------+ 340 | T_CACHETIME | Length = 1 | 341 +---------------+---------------+---------------+---------------+ 342 | COMPACT_TIME | 343 +---------------+ 344 1 2 3 345 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 346 +---------------+---------------+---------------+---------------+ 347 | T_CACHETIME | Length = 8 | 348 +---------------+---------------+---------------+---------------+ 349 / / 350 / Recommended Cache Time / 351 / / 352 +---------------+---------------+---------------+---------------+ 354 Figure 5: Changes to the definition of the Recommended Cache Time 355 TLV. 357 The packet processing is adapted to calculate an absolute time from 358 the relative time code based on the absolute reception time. On 359 transmission, a new relative time code is calculated based on the 360 current system time. 362 A note on legacy forwarders: A forwarder that does not support this 363 compact time representation is expected to consider a Recommended 364 Cache Time with length 1 as a structural or syntactical error and 365 discard the packet. Otherwise, a forwarder interprets the compact 366 1-byte time value as an absolute time far in the past, which impacts 367 cache utilization. 369 6. IANA Considerations 371 Based on the approach of integration, certain TLV registries from 372 [RFC8609] need to be updated. 374 7. Security Considerations 376 This document makes no semantic changes to [RFC8569], nor to any of 377 the security properties of the message encodings of [RFC8609], and 378 hence has the same security considerations as those two existing 379 documents. 381 8. References 383 8.1. Normative References 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 8.2. Informative References 392 [ICNLOWPAN] 393 Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch, 394 "Designing a LoWPAN convergence layer for the Information 395 Centric Internet of Things", Computer Communications, Vol. 396 164, No. 1, p. 114–123, Elsevier, December 2020, 397 . 399 [IEEE.754.2019] 400 Institute of Electrical and Electronics Engineers, C/MSC - 401 Microprocessor Standards Committee, "Standard for 402 Floating-Point Arithmetic", June 2019, 403 . 406 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 407 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 408 DOI 10.17487/RFC5497, March 2009, 409 . 411 [RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., 412 Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, 413 "Information-Centric Networking (ICN) Research 414 Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, 415 . 417 [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric 418 Networking (CCNx) Semantics", RFC 8569, 419 DOI 10.17487/RFC8569, July 2019, 420 . 422 [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric 423 Networking (CCNx) Messages in TLV Format", RFC 8609, 424 DOI 10.17487/RFC8609, July 2019, 425 . 427 [RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C., 428 Marxer, C., and C. Tschudin, "Information-Centric 429 Networking (ICN) Adaptation to Low-Power Wireless Personal 430 Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139, 431 November 2021, . 433 Appendix A. Test Vectors 435 The test vectors in Table 1 show sample time codes and their 436 corresponding time values according to the algorithm outlined in 437 Section 4. 439 +===========+======================+ 440 | Time Code | Time Value (seconds) | 441 +===========+======================+ 442 | 0x00 | 0.000000 | 443 +-----------+----------------------+ 444 | 0x01 | 0.007812 | 445 +-----------+----------------------+ 446 | 0x04 | 0.031250 | 447 +-----------+----------------------+ 448 | 0x08 | 0.062500 | 449 +-----------+----------------------+ 450 | 0x15 | 0.203125 | 451 +-----------+----------------------+ 452 | 0x28 | 1.000000 | 453 +-----------+----------------------+ 454 | 0x30 | 2.000000 | 455 +-----------+----------------------+ 456 | 0xF8 | 67108864.000000 | 457 +-----------+----------------------+ 458 | 0xFF | 125829120.000000 | 459 +-----------+----------------------+ 461 Table 1: Test Vectors 463 Appendix B. Efficient Time Value Approximation 465 A forwarder frequently converts compact time into milliseconds to 466 compare Interest lifetimes and the duration of cache entries. On 467 many architectures, multiplication and division perform slower than 468 addition, subtraction, and bit shifts. The following equations 469 approximate the formulas in Section 4, and scale from seconds into 470 the milliseconds range by applying a factor of 2^10 instead of 10^3. 471 This results in an error of 2.4%. 473 b == 0: 2^10 * a * 2^-3 * 2^1 * 2^-5 474 = a << 3 476 b > 0: (2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5 477 = (1 << 5 + a << 2) << b 479 Acknowledgments 481 We would like to thank the active members of the ICNRG research group 482 for constructive thoughts. In particular, we thank Marc Mosko and 483 Ken Calvert for their valuable feedback on the encoding scheme and 484 the protocol integration. 486 Authors' Addresses 488 Cenk Gündoğan 489 HAW Hamburg 490 Berliner Tor 7 491 D-20099 Hamburg 492 Germany 493 Phone: +4940428758067 494 Email: cenk.guendogan@haw-hamburg.de 495 URI: http://inet.haw-hamburg.de/members/cenk-gundogan 497 Thomas C. Schmidt 498 HAW Hamburg 499 Berliner Tor 7 500 D-20099 Hamburg 501 Germany 502 Email: t.schmidt@haw-hamburg.de 503 URI: http://inet.haw-hamburg.de/members/schmidt 504 Dave Oran 505 Network Systems Research and Design 506 4 Shady Hill Square 507 Cambridge, MA 02138 508 United States of America 509 Email: daveoran@orandom.net 511 Matthias Waehlisch 512 link-lab & FU Berlin 513 Hoenower Str. 35 514 D-10318 Berlin 515 Germany 516 Email: mw@link-lab.net 517 URI: http://www.inf.fu-berlin.de/~waehl