## 4 Strategy Description
### Popularity-Based Caching Strategy with Number-of-Copies Control  
Our goal is to maximize the network cache hit ratio, as well as keeping the content transfer latency low. To avoid redundant content, we design the caching strategy as choosing at most one on-path caching node for content placement. The cache location is selected as the on-path node that carries the content of minimum popularity. Furthermore, the hit node will compare the current number of copies and the expected number of copies,to decide whether to cache this content. We define the proposed strategy as PB-NCC for short. To implement PB-NCC, we expand the Cache-Control field in the transport layer header of the ICN request packet and the data packet, as depicted in Figure 2. The Cache-Control field is made up of the Cache flag, the Popularity field, and the Copy Number field. The Cache flag is used to quickly filter out data packets for cache operation. If the Cache flag is 1, on-path nodes will further judge whether the caching conditions are met. Otherwise, the data packets will be forwarded to the user directly. The Popularity field in request packets is used to find the minimum popularity from on-path nodes, while those in data packets are used to find the eligible nodes for cache operation. The Copy Number field is used to record the current number of copies in the topology in request packets. The hit node will use this information to control the number of copies of contents. PB-NCC is implemented by constructing and processing ICN request packets and data packets. The request packet is constructed by the user and shown in Algorithm 2. With the NA list returned from the NRS, the user gets the current number of copies and fills it into the Copy Number field of the request packet. The Popularity field in the request packet is initialized to the maximum, to find the minimum popularity of on-path nodes. ```
1 The user sends a name resolution message for content \(k\) and receives the NA list from the NRS;
2 set Cache flag to 0, set Popularity field to the maximum;
3 set Copy Number field to the current number of copies;
4 forward the request packet;
```  
**Algorithm 2**Request Packet Construction  
The request packet forwarding process is shown in Algorithm 3. When a caching node \(i\) receives a request packet, it will first check out whether the destination NA is itself. If yes, then node \(i\) processes the popularity estimation and constructs and returns the data packets. Otherwise, node \(i\) compares the value of the Popularity field in the request packet with the minimum popularity recorded itself and updates the Popularity field with the smaller value before forwarding the request packet. The data packet is constructed in the hit node, as shown in Algorithm 4. If the hit node is a Source Server, the Number-of-Copies Control will not be triggered, for the reason that request hit at caching nodes other than at Source Servers will bring higher cache hit ratio and lower latency. Thus, in this case, the Cache flag is set to 1 and the Popularity field is set equal to that from the request packet for content \(k\). If the hit node \(i\) is a caching node, this node first needs to compare the Copy Number field and \(int(n_{\text{base}}p_{i,k})\). If the Copy Number field is smaller, meaning that more replicas of content \(k\) can be cached in the topology. Thus, the Cache flag of data packets is set to 1, and the Popularity field is set  
Figure 2: Cache-Control field design. equal to that from the request packet for content \(k\). If the Copy Number field is larger, all values in the Cache-Control field are set to 0, and on-path nodes will not cache content \(k\).