# Caching Transient Contents in Vehicular Named Data Networking: A Performance Analysis
## 5 Caching Transient Contents in V-NDN
### Cache Inconsistency in Existing Solutions  
In mobile wireless and broadcast environments such as VANETs, vehicles act like data mule that collect packets and move them across distances thus offering a valuable dissemination service. Transient data, however, require an ad hoc caching strategy that is aware of their lifetimes. Storing stale data can lead to cache inconsistency, i.e., distinct cachers can have inconsistent copies of the same content that result in multiple adverse effects in the real life. For instance, if a vehicle looks for an empty space by transmitting an Interest in its neighborhood, it may uselessly reach a wrong (busy) space, by wasting both fuel and time, if stale data are received as a reply. In vanilla NDN, the transient feature of a content is expressed in term of a _FreshnessPeriod_ (in the following shortened as FP), a field in the Data packet header indicating the lifetime of the content. The parameter is application-specific and it is set by the original producer. If the lifetime is not expired, the content can be considered still _fresh_. Otherwise, the original source may have produced new content. Tracking the freshness is, therefore, crucial in presence of transient data not to incur in cache inconsistency effects. A policy that honors content freshness (we refer to as \"FP-Aware\" policy) is implemented in vanilla NDN and applied in conjunction with a standard replacement policy such as LRU. Basically, when caching a received Data packet, the NDN node sets a timer equal to the FP value; when this latter expires, the content is removed. Literature on caching transient data in NDN is still at its infancy and almost unexplored in vehicular environments. Some proposals were devised in IoT sensor networks, with the main target of reducing the data retrieval latency and limit the energy consumption [4; 5; 6]. Other works considered caching transient contents in wired networks segments [7; 8]. With focus on V-NDN, a Multi-Metric Cache Replacement (\(M^{2}CRP\)) scheme is presented in [25]. There, content popularity, freshness, and distance between the content producer and the cache are used to select the packet that must be evicted from the CS. \(M^{2}CRP\) is coupled with the CEE policy: when a new Data packet is received, it is always cached and, if the CS is full, then an existing cached item must be replaced. Popularity, freshness and distance metrics are used to compute a score for every cached item; the one with the minimum score is selected as the candidate for eviction. A similar replacement strategy, but implemented in RSUs only, is deployed in [35]. Works [25; 35], however, do not consider the effect of freshness in the caching decision process. By using CEE, all the contents are indiscriminately cached regardless of their freshness period. On the one hand, CEE does not create content diversity within the vehicles' neighbourhood: the CSs of vehicles in the same area are filled with the same information, thus resulting in an inefficient use of the distributed storage space. On the other hand, caching contents with a long lifetime could be more convenient than caching contents with a shorter lifetime, since these latter must be evicted more frequently from the CS. We also observe that the FP information is static, i.e., it is not decreased by caching nodes when answering requests. Indeed, NDN Data packets are immutable [36]: if some information in the packet changes, the producer must generate a new packet and sign it. Under such conditions, cache inconsistency can still occur. As an example, we consider a scenario where an RSU monitors the average speed on a certain road and produces new Data packets named _/RoadY/avgSpeed_ every 60 s. An NDN vehicle A, implementing CEE+LRU+FP-Aware policy, requests a Data packet at time \(t=0\) s and it is allowed to cache it for 60 s. At time \(t=50\) s a vehicle B asks for the same content and receives it from A.