Skip to main content

3. Usage of Time Values in CCNx

3. Usage of Time Values in CCNx​

3.1. Relative Time in CCNx​

CCNx, as currently specified in [RFC8569], utilizes delta time for only the lifetime of an Interest message (see Sections 2.1, 2.2, 2.4.2, and 10.3 of [RFC8569]). It is a hop-by-hop header value, and is currently encoded via the T_INTLIFE TLV as a 64-bit integer (Section 3.4.1 of [RFC8609]). While formally an optional TLV, every Interest message is expected to carry the Interest Lifetime TLV in all but some corner cases; hence, having compact encoding is particularly valuable to keep Interest messages short.

Since the current uses of delta time do not require both accuracy and dynamic range simultaneously, one can consider a logarithmic encoding such as that specified in [IEEE.754.2019] and as outlined in Section 4. This document updates CCNx messages in TLV format [RFC8609] to permit this alternative encoding for selected time values.

3.2. Absolute Time in CCNx​

CCNx, as currently specified in [RFC8569], utilizes absolute time for various important functions. Each of these absolute time usages poses a different challenge for a compact representation. These are discussed in the following subsections.

3.2.1. Signature Time and Expiry Time​

Signature Time is the time the signature of a Content Object was generated (see Sections 8.2-8.4 of [RFC8569]). Expiry Time indicates the time after which a Content Object is considered expired (Section 4 of [RFC8569]). Both values are content message TLVs and represent absolute timestamps in milliseconds since the POSIX epoch. They are currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit unsigned integers (see Sections 3.6.4.1.4.5 and 3.6.2.2.2 of [RFC8609], respectively).

Both time values could be in the past or in the future, potentially by a large delta. They are also included in the security envelope of the message. Therefore, it seems there is no practical way to define an alternative compact encoding that preserves its semantics and security properties; therefore, this approach is not considered further.

Recommended Cache Time (RCT) for a Content Object (Section 4 of [RFC8569]) is a hop-by-hop header stating the expiration time for a cached Content Object in milliseconds since the POSIX epoch. It is currently encoded via the T_CACHETIME TLV as a 64-bit unsigned integer (see Section 3.4.2 of [RFC8609]).

A Recommended Cache Time could be far in the future, but it cannot be in the past and is likely to be a reasonably short offset from the current time. Therefore, this document allows the Recommended Cache Time to be interpreted as a relative time value rather than an absolute time, because the semantics associated with an absolute time value do not seem to be critical to the utility of this value. This document therefore updates the Recommended Cache Time with the following rule set:

  • Use absolute time as per [RFC8609]
  • Use relative time, if the compact time representation is used (see Sections 4 and 5)

If relative time is used, the time offset recorded in a message will typically not account for residence times on lower layers (e.g., for processing, queuing) and link delays for every hop. Thus, the Recommended Cache Time cannot be as accurate as when absolute time is used. This document targets low-power networks, where delay bounds are rather loose or do not exist. An accumulated error due to transmission delays in the range of milliseconds and seconds for the Recommended Cache Time is still tolerable in these networks and does not impact the protocol performance.

Networks with tight latency bounds use dedicated hardware, optimized software routines, and traffic engineering to reduce latency variations. Time offsets can then be corrected on every hop to yield exact cache times.

Last updated on