## 5 Evaluation
### Loss Recovery Delay  
Loss recovery delay is defined as the time interval between the receiver first detecting the packet loss and the receiver receiving the recovery packet. Suppose there are \(R\) receivers. Let \(\overline{D}_{r}\) be the average loss recovery delay of multicast receiver \(r\), and \(\overline{RTT}\) be the mean round trip time from all multicast sources to all receivers. Then we evaluate the loss recovery delay by the normalized loss recovery delay (NLRD) \(\overline{D}\), which is defined in Equation (8). \[\overline{D}=\frac{\frac{1}{R}\sum_{r=1}^{R}\overline{D}_{r}}{\overline{RTT}} \tag{8}\]  
Figure 4 compares the NLRD achieved by the combinations of four cache strategies and three cache allocation mechanisms under different cache sizes. It can be seen that, as the cache size increases, the NLRD of all combinations becomes smaller. This is because the larger cache space allows more chunks to be cached. \begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline The maximum queue length (\(Q_{max}\)) & 700 packets \\ The upper threshold for queue length (\(Q_{high}\)) & \(0.75\times Q_{max}\) \\ The lower threshold for queue length (\(Q_{low}\)) & \(0.25\times Q_{max}\) \\ Cache size & 100–900 \\ Chunk size & 10 packets \\ Packet size & 1032 bytes \\ Weighting factor \(\theta\) for DCAM & 0.9 \\ The cache allocation cycle & 0.07 s \\ Cache probability threshold (\(P_{th}\)) for CAPC & 0.4 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Experiment parameters. Figure 3: Experiments on the setting of weight coefficients values. On the one hand, the NLRD achieved by the combinations of DCAM and different cache strategies are smaller than that of other combinations, for example, when the cache size is 600, the NLRD of DCAM-CAPC is 3.18% and 5.21% lower than that of AARM-CAPC and Equal-CAPC, respectively. When the cache size is 300, the NLRD of DCAM-LCE is 9.52% and 6.27% lower than that of AARM-LCE and Equal-LCE, respectively. This is because DCAM comprehensively considers factors such as packet loss probability, node depth, transmission rate to calculate the cache allocation result. DCAM can quickly respond and adjust cache quota for each multicast group with network changes. AARM first estimates the cache quota of a multicast group based on the ratio of weighted moving average of NACK of the multicast group to total number of NACK, and then adjusts for the group whose quota is lower than the number of packets arriving per unit time. In fact, only two factors, such as packet loss rate and transmission rate, are considered in AARM, therefore the NLRD achieved by various cache strategies based on the AARM allocation results is greater than that achieved by various cache strategies based on the DCAM allocation results. The NLRD achieved by the combinations of Equal and the four cache strategies are the largest. This is because Equal simply distributes the MTN's cache space evenly to all multicast groups, resulting in low cache resource utilization. On the other hand, as seen from Figure 4a,b, the NLRD achieved by the combinations of CAPC and all allocation mechanisms is the smallest, while the NLRD achieved by the combinations of LCE and all allocation mechanisms is the largest when the cache space is small. This is because CAPC takes into account the congestion condition and the location of cache nodes on the multicast tree, so that CAPC can provide better loss recovery services. The advantages of CAPC have been demonstrated in [20]. However, LCE caches all chunks along the way. Due to limited cache space, cache replacement occurs frequently. The requested chunks are likely to have been replaced before the corresponding retransmission  
Figure 4: Comparison of normalized loss recovery delay (NLRD). **(a)** Comparison of NLRD under LCE; **(b)** comparison of NLRD under CAPC; **(c)** comparison of NLRD under Prob; **(d)** comparison of NLRD under ProbCache. requests arrive. As the cache space becomes larger, LCE can cache more chunks, so NLRD is relatively small.