## 5 Discrete Event-Based Simulator for Dynamic VoD Content Distribution  
The overall functionality of the simulator is as follows. Given as input, the network topology; the content catalog characteristics (number of VoD items, their sizes and the popularity distribution); and the locations and capacities of the caches (note that given the capacity of a cache also means the list of VoD items cached, as we consider a popularity-based caching strategy), the simulator provisionsthe dynamically-arriving VoD requests, based on current network status, and gives as an output the overall amount of network resources occupied to provision VoD content requests, requests served by each cache and blocking probability. We describe a VoD-content request by the tuple r = (\(t_{s}\), \(D_{r}\), \(m\), \(b_{r}\), \(d_{r}\)), where \(t_{s}\) is its arriving time, \(D_{r}\) defines the user requesting the content, \(m\) is the content requested with bit-rate \(b_{r}\) and a chunk duration \(d_{r}\). Moreover, as each item consists of a number of chunks and the chunks are provisioned one by one, the simulator allows one to deliver different chunks of the same VoD request from different caches. In addition, adopting the chunk-nature of the VoD request also allows one to degrade or upgrade, depending on the status of the network--the bit-rate assigned to a VoD request. The provisioning and deprovisioning process of a VoD chunk is described in Algorithm 1. First, when a request is generated for an item \(m\) from a user \(D_{r}\), a list of all the caches storing item \(m\) (including the video server) is identified. We assume that access nodes (ANs) act as HTTP proxies for users so that a TCP connection request is originated from them towards the caches every time a VoD content chunk is download through, e.g., an HTTP stream. The nearest cache storing item \(m\), assuming a path with available bandwidth at least equal to the \(b_{r}\), is identified, and it delivers the content to user \(D_{r}\), allocating a bandwidth equal to \(b_{r}\) along the shortest path from the cache to the access node \(AN\) aggregating user \(D_{r}\). Note that in a realistic network scenario, the choice of path is not necessary based on the shortest path, as a network operator/content provider may optimize content delivery based on other metrics; e.g., congestion avoidance, network/cache load balancing or desired user quality. If no path with bandwidth greater than or equal to \(b_{r}\) can be found, the provisioning process degrades the quality of the video delivery, i.e., setting the value of \(b_{r}\) to that corresponding to a lower video definition (described in Section 3.2.2), and then tries to provision the request. If no path can be found in this case, the VoD request is blocked. If a path is found, request \(r\) is provisioned for the duration of the chunk of content, and then it is deprovisioned at time \(t_{s}+d_{r}\), deallocating the assigned bandwidth from the utilized path. Simultaneously, a request for the successive chunk of the content request is initiated. Note that since the provisioning/deprovisioning process is performed for every chunk of a VoD request, different chunks can be delivered at different provisioning bit-rates, thereby imitating the functionality of the adaptive bit-rate streaming technique. For example, if a chunk is delivered with a bit-rate lower than \(b_{r}\), due to unavailable network resources, the successive chunk shall be allocated bit-rate \(b_{r}\) if network resources become available. Note that the in-network bit-rate adaptation approximates a realistic scenario in which the low-quality adaptation is performed at the user-side. The computational time of the algorithm considering the system used is around 10 ms per VoD chunk request.