## 3 Model Statement
### Scenario Description  
We use \(G=~{}<V,E>\) to represent an arbitrary topology, where \(V\) is the set of ICN caching nodes and \(E\) is the set of links between nodes. For node \(i\), \(c_{i}\) is its cache size, and \(E_{i,j}\) denotes the link between node \(i\) and its neighbor node \(j\). The ICN caching scenario with an NRS is depicted in Figure 1. Besides the aforementioned ICN caching nodes, the scenario has an NRS recording the mapping between the content name and the NAs, one or more source servers storing all contents persistently, and multiple users who continuously send requests for contents. The NRS is responsible for receiving registration messages for the content. In addition, the NRS will handle name resolution messages and respond to them with a list of the NAs of the content. This list is used by the user to further request the content. We use \(C\) to denote the set of contents and for content \(k\in C\), and \(S_{k}\) represents the size of content \(k\).  
According to the routing-by-resolution mechanism in ICN, the content will be registered to the NRS before being served. In the example of Figure 1, when User1 wants to download the content, he or she needs to send a name resolution message for the corresponding content to the NRS, and the NRS returns an NA list of the content to User1. User1 gets the NA of the Source Server and sends a request to the Server. The Server returns the content to User1, meanwhile the on-path nodes R1 and R3 cache the content and register  
\begin{table}
\begin{tabular}{l l} \hline \hline
**Name** & **Comment** \\ \hline \(V\) & Set of ICN caching nodes \\ \(E\) & Set of links between nodes \\ \(E_{i,j}\) & The link between node \(i\) and node \(j\) \\ \(C\) & Set of contents \\ \(s_{k}\) & Size of content \(k\), \(k\in C\) \\ \(c_{i}\) & Cache space equipped in node \(i\) \\ \(\lambda_{i}^{in}\) & Inflow request rate in node \(i\) \\ \(\lambda_{i}^{out}\) & Outflow request rate in node \(i\) \\ \(p_{i,k}\) & inflow request probability of content \(k\) in node \(i\) \\ \(h_{i}\) & Cache hit ratio of node \(i\) \\ \(x_{i,k}\) & Boolean variable indicates whether node \(i\) caches content \(k\) \\ \(h_{total}\) & Total cache hit ratio \\ \(r_{i}\) & Total number of served request counts in node \(i\) \\ \(r_{i,k}\) & Count of served requests of content \(k\) in node \(i\) \\ \(n_{base}\) & Base number of copies for the topology \\ \hline \hline \end{tabular}
\end{table}
Table 1: Summary of the notations.  
the content to the NRS. User2 retrieves the content following the same process. User2 first sends a name resolution message and the NRS returns a list containing the NAs of the Servers, R1 and R3. Then, User2 chooses to get the content from R1 and sends a request to R1. Finally, R1 serves the request and returns the content to User2.  
For users to get contents using the NA list, there are two simple ways: applying Nearest Replica Routing (NRR [20]) or applying random NA selection. In the first way, the user always sends a request to the nearest copy. However, in the second way, the user selects an NA at random from the NA list to send the request. We apply NRR in this paper, as the routing-by-resolution mechanism commonly sets NRR as the routing strategy.