3. Usage of Time Values in CCNx (Utilisation des valeurs temporelles dans CCNx)

3.1. Relative Time in CCNx (Temps relatif dans CCNx)

CCNx, tel que actuellement spécifié dans [RFC8569], utilise le temps delta uniquement pour la durée de vie d'un message Interest (voir sections 2.1, 2.2, 2.4.2 et 10.3 de [RFC8569]). Il s'agit d'une valeur d'en-tête saut par saut (hop-by-hop), actuellement encodée via le TLV T_INTLIFE comme un entier de 64 bits (section 3.4.1 de [RFC8609]). Bien que formellement optionnel, chaque message Interest devrait porter le TLV Interest Lifetime dans tous les cas sauf quelques cas particuliers; par conséquent, avoir un encodage compact est particulièrement précieux pour garder les messages Interest courts.

Étant donné que les utilisations actuelles du temps delta ne nécessitent pas à la fois précision et plage dynamique simultanément, on peut envisager un encodage logarithmique tel que spécifié dans [IEEE.754.2019] et décrit dans la section 4. Ce document met à jour les messages CCNx au format TLV [RFC8609] pour permettre cet encodage alternatif pour des valeurs temporelles sélectionnées.

3.2. Absolute Time in CCNx (Temps absolu dans CCNx)

CCNx, tel que actuellement spécifié dans [RFC8569], utilise le temps absolu pour diverses fonctions importantes. Chacune de ces utilisations de temps absolu pose un défi différent pour une représentation compacte. Ceux-ci sont discutés dans les sous-sections suivantes.

3.2.1. Signature Time and Expiry Time (Temps de signature et temps d'expiration)

Le Signature Time (temps de signature) est le moment où la signature d'un Content Object (objet de contenu) a été générée (voir sections 8.2-8.4 de [RFC8569]). L'Expiry Time (temps d'expiration) indique le moment après lequel un objet de contenu est considéré comme expiré (section 4 de [RFC8569]). Les deux valeurs sont des TLV de message de contenu et représentent des horodatages absolus en millisecondes depuis l'époque POSIX. Ils sont actuellement encodés via les TLV T_SIGTIME et T_EXPIRY comme des entiers non signés de 64 bits (voir respectivement sections 3.6.4.1.4.5 et 3.6.2.2.2 de [RFC8609]).

Les deux valeurs temporelles pourraient être dans le passé ou dans le futur, potentiellement avec un grand delta. Elles sont également incluses dans l'enveloppe de sécurité du message. Par conséquent, il semble qu'il n'y ait aucun moyen pratique de définir un encodage compact alternatif qui préserve sa sémantique et ses propriétés de sécurité; par conséquent, cette approche n'est pas considérée davantage.

3.2.2. Recommended Cache Time (Temps de cache recommandé)

Le Recommended Cache Time (temps de cache recommandé, RCT) pour un Content Object (section 4 de [RFC8569]) est un en-tête saut par saut indiquant le temps d'expiration pour un objet de contenu mis en cache en millisecondes depuis l'époque POSIX. Il est actuellement encodé via le TLV T_CACHETIME comme un entier non signé de 64 bits (voir section 3.4.2 de [RFC8609]).

Un temps de cache recommandé pourrait être loin dans le futur, mais il ne peut pas être dans le passé et est susceptible d'être un décalage raisonnablement court par rapport au temps actuel. Par conséquent, ce document permet au temps de cache recommandé d'être interprété comme une valeur de temps relatif plutôt qu'un temps absolu, car la sémantique associée à une valeur de temps absolu ne semble pas critique pour l'utilité de cette valeur. Ce document met donc à jour le temps de cache recommandé avec l'ensemble de règles suivant:

Utiliser le temps absolu selon [RFC8609]
Utiliser le temps relatif si la représentation temporelle compacte est utilisée (voir sections 4 et 5)

Si le temps relatif est utilisé, le décalage temporel enregistré dans un message ne tiendra généralement pas compte des temps de résidence sur les couches inférieures (par exemple, pour le traitement, la mise en file d'attente) et des délais de liaison pour chaque saut. Ainsi, le temps de cache recommandé ne peut pas être aussi précis que lorsque le temps absolu est utilisé. Ce document cible les réseaux à faible consommation, où les limites de délai sont plutôt lâches ou n'existent pas. Une erreur accumulée due aux délais de transmission dans la plage des millisecondes et des secondes pour le temps de cache recommandé est encore tolérable dans ces réseaux et n'impacte pas les performances du protocole.

Les réseaux avec des limites de latence strictes utilisent du matériel dédié, des routines logicielles optimisées et de l'ingénierie du trafic pour réduire les variations de latence. Les décalages temporels peuvent alors être corrigés à chaque saut pour obtenir des temps de cache exacts.