## 5 Analysis and Evaluation
### Control Overhead  
We compare the message lengths of ENRS, KNN-DNRS, and Random-NRS, and get the result in Table 3. As shown in Table 4. The lengths of the REGISTER messages of ENRS, KNN-DNRS, and Random-NRS are 240 bits, 224 bits, and 224 bits, respectively. The lengths of the QUERY messages of ENRS, KNN-DNRS, and Random-NRS are 248 bit, 224 bits, and 224 bits, respectively. As we mentioned in Section 3.2.2, except for EID, NA, and timestamps, we also define some customized parameters to realize our name registration and resolution mechanisms, i.e., 8-bit STO parameter, 8-bit ENRT parameter, 8-bit RNDR parameter. The RTL is an optional parameter, thus we omit it when comparing the message length.  
We evaluate the total query traffic with different numbers of queries with different query nodes. The result is shown is Figure 9. As shown in Figure 9, the total traffic overhead of ENRS is the smallest compared with KNN-DNRS and Random-NRS with different query distributions. The query traffic overhead of KNN-DNRS and Random-NRS are 33.3-times and 2-times larger than ENRS, respectively, with the increase of queries. In ENRS, we assign different hierarchical resolvers for every node to satisfy different response requirements and make constraints on the forwarding hops of queries. Thus, the paths of look-ups are deterministic, so the look-up traffic overhead is relatively stable and controllable. With the same number of resolvers available, KNN-DNRS has to calculate the end-to-end latency with every resolver to select the nearest one to register or query, so the traffic of name resolution increases sharply with the increase of node sizes and queries. In Random-NRS, nodes randomly select a resolver to register and query. If the resolver does not have the requested name, it will forward the request to  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**System Name** & **REGISTER Message** & **QUERY Message** \\ \hline ENRS & 240 bits & 248 bits \\ KNN-DNRS & 224 bits & 224 bits \\ Random-NRS & 224 bits & 224 bits \\ \hline \hline \end{tabular}
\end{table}
Table 4: The length of messages.  
Figure 8: The total offloading traffic (MB) in different levels of HMs in ENRS with different query counts. (**a**) demonstrate the variation of offloading traffic in L\({}_{1}\) and L\({}_{2}\) HMs with different number of nodes when the query count is 1000. (**b–d**) demonstrate the variation of offloading traffic in L1 and L2 HMs with different number of nodes when the query counts are 2000, 4000 and 8000 respectively.  
its neighboring resolvers by flooding, so the traffic overhead is larger than ENRS and increases with the growth of resolvers.  
As we introduced in Section 2, there are many proposed DHT-based ICN NRSs. In each DHT-based NRS, name bindings are offsite storage. The entrances of name queries are selected by the value of hash (EID). Thus, the query paths may exist as multi-hops, which increase the query traffic overhead and the query latency, while in ENRS, the entrances of name queries are selected by the location of the requestor and the response delay requirements, and the query paths are single-hops, of which the complexity is O(1), thus the query traffic overhead is small. For a DHT-based system, the query complexity is O(1) in the best case, while in the majority of situations, the complexity would be log N, where N is the length of EID. Thus, the control overhead of DHT-based NRS may be larger than ENRS in general.