# T-Move: A Light-Weight Protocol for Improved QoS in Content-Centric Networks with Producer Mobility
## 3 Related Work  
### Caching in Information-Centric Networks  
Caching has been widely explored in the form of web caching to reduce the content retrieval time. The caching decision policy decides when and where data must be cached and is a major aspect of caching. Two extreme solutions to the caching decision problem are the _cache-everything_ scheme, where all data through a router is cached by it, and the _cache-nothing_, where no data is cached at the intermediate nodes. An important issue in caching is the cache replacement policy to be followed. There are several contending solutions for this ranging from simple Least Recently Used (LRU) and FIFO to complex popularity-based learning algorithms. LRU, FIFO or random replacement schemes may serve fairly well if the data objects are uniform in size and priority. However, it is an established fact that frequency-based cache replacement schemes out-perform LRU and other simple schemes [12]. While predicting the popularity of online content has been studied by several researchers ([13; 14] etc. ), using it for caching is a relatively recent trend. In [15], the authors study how popular social media content can be used to optimize content replication. In [16], the authors use an off-line model-based scheme for forecasting popularity and model parameters are obtained using training datasets. The issue with training-based schemes is that the popularity of content changes with time and models based on older training sets may not result in correct prediction of popular content. More recently, [PERSON]. [17] has proposed PopCaching which works online. The novelty of PopCaching is that it does not require a training phase and learns about the popularity of content online. PopCaching converges quickly and shows promising results in terms of cache hit ratio. However, PopCaching follows a greedy approach based on the number of hops for deciding where content must be cached. This caches popular content closer to the user and unpopular content closer to the servers and implies that two routers at the same hop distance away from the requesting users have the same probability of caching the content. In reality, however, such routers may not receive interests for data with the same probability. Caching in ICN has been the topic of interest for many researchers. Popular ICN designs and projects (CCN, DONA, PSIRP, NETInf) categorized caching into on-path and off-path caching [18; 19]. On-path caching minimizes the content retrieval time and bandwidth consumption by caching the content at intermediate nodes on that path from producer to consumer, but results in high content replication. Off-path caching focuses more on frequency of access of the content and cache capacity to allocate cache space optimally [19]. ICN inherently supports caching in either form, but has different features and requirements compared with the IP-based Internet, as pointed out by [12]. Except for a few, all existing web caching solutions cache entire data objects. On the contrary, data in ICN is partitioned in sub-objects or chunks. This may result in chunks of the same content object being cached at different routers. Also, routers in ICN must make caching decisions and replacements online, which makes most web caching solutions unsuitable for ICN [20]. In a related study, Ref. [20] proposes random fractional caching for CCN. In this scheme, the routers maintain a packet store and an index table to locate each packet. Each packet has a pre-set probability of getting indexed and cached. Our argument is that packet caching and replacement should not be random, but should be based on the popularity of the content, instead of being random. Refs. [21; 22; 23] present popularity-driven caching strategies for ICN. These solutions formulate the caching problem as an optimization problem and/or use coordinated caching for replicating data. However, coordination requires time and results in increased traffic in the core network.