Round  1

Reviewer 1 Report

= A. Regarding the system design =

Why does the system use flat names? Is it because HEAs are formed based on latency?

Another question lies on how often do HEAs get updated, which is in general important and, in particular, about mobile content as discussed by the suggested work by V. Siris bellow (see point 1 in comments about related work).

= B. Comments on related work =
In general, the authors have done quite meticulous work regarding related work. There is still room for improvement:
1) I suggest adding "Popularity-aware intra-domain mobility management" by V. Siris in section 2.1. This is an approach using a popularity-aware intra-domain mobile content management model on the basis of which the NRS tracks the current location of mobile content only when the content has a sufficiently high popularity and sufficiently low mobility, while it discovers low popularity/highly mobile content via broadcasting. Scalability gains lie in reducing total signaling and memory requirements of the NRS. Such gains can be also seen in mobile caching solutions, using the same principle. The authors may also refer to, e.g., the work of Vasilakos et al. "Addressing niche demand based on joint mobility prediction and content popularity caching" where the interplay between mobility and popularity is more extensively studied or even the work of "Exploiting mobility prediction for mobility & popularity caching and dash adaptation" again by V. Siris et al.
2) I suggest adding reference [42] as related work in section 2.1 about scalability, alongside the preceding work on "Cloud computing for global name-resolution in information-centric networks" by the same authoring team presented at IEEE Network Cloud Computing and Applications Symposium '12, which analyses DONA's scalability at a first stage and discusses the potential of cloud technologies towards enhancing scalability.

= C. Wrong/incomprehensible language usage =

Unfortunately, the language quality drops significantly at parts of the text, particularly in section 3, making it difficult to understand the important design aspects of the system. Some few examples are as follows:

- "REGISTER message will forward to proper HM in" - do you mean "be forwarded"?

- "nested Hierarchical Elastic Area (HEA) with" => "nested Hierarchical Elastic Areas (HEAs)"

- "DNHT is made up of which including the"  - I do not understand what the authors wish to say at this point.

= D. Evalaution results = 

1) Regarding the results of figure 6(b): 
The outcome presented in 6(b) is expected, but as a trade-off, the resolution latency should in principle also increase with the higher level of resolution. Is this right to assume? If so, then it necessary to present evaluation results that compare resolution latency and total traffic (in terms of a number of messages) next to the results of 6(b).

2) Regarding the results of figure 7:

Total traffic is better perceived in terms of a number of messages, not MBs which is subject to the setup details of the simulation evaluation experiments. 

3) Regarding the results of figure 8:

The results on figure 8 show a good performance, however, this is partly due to the choice of benchmarks. A DHT-based NRS would most probably perform better. Nevertheless, I am not implying this is not an important and encouraging evaluation performance merit of the proposed system. I am only requesting to consider presenting a comparison to DHT-based systems or - if this is not feasible at this stage - at least comment on that and state why the proposed design has better overall merits.

Author Response

Response for Reviewer 1’s Comments

 Dear editors and reviewers,

    I would like to submit a manuscript entitled “A Temporally Hierarchical Deployment Architecture for Enhanced Name Resolution System”, which I wish to be considered for publication in Journal of Applied Sciences. I believe the paper would be of particular interest to the readers of your journal. The comments and responses for the revised edition of our paper are written in the later of this article. The comments and suggestions are written in black and the responses are written in blue.

    Correspondence should be addressed to Yi LIAO, Yiqiang SHENG at the following e-mail address and phone number.

    E-mail: [email protected]; [email protected]

    Tel : +8615201226257

    Thanks for considering my manuscript for potential publication.  

                                                   Sincerely yours,

                                                      Yi LIAO

 Comments and Response:

Comment: A. Regarding the system design

1. Why does the system use flat names? Is it because HEAs are formed based on latency?

Response: In ICN, there are two kinds of naming schemes: hierarchical name and flat name. We use flat name is because flat name has some outstanding merits on higher flexibility, simpler name allocation and benefits in terms of persistency and privacy, especially the advantage on security that flat name can support self-certifying which containers the hash values of its owner and can be verified without need of third party. In ENRS, latency is a distance metric to partition the service area of resolver. To make our proposal easier to be understood, we have added more content on page 6 paragraph 3 to describe the reasons of choosing flat name and using IP as network address.

Comment: 2. Another question lies on how often do HEAs get updated, which is in general important and, in particular, about mobile content as discussed by the suggested work by V. Siris bellow (see point 1 in comments about related work).

Response: Mobility is an important issue worth considering. The nodes involved in a HEA will get updated if nodes move and the bindings of EIDs and NAs will get updated, either. The position of resolver served for a HEA won’t change once the HEA has been partitioned at the first stage, the list of the nodes a resolver working for will get updated if a new node moving into or leaving from the HEA.

ENRS is a local NRS, the load of which is much smaller than the global ENRS. We assume that 100 ENRS sub-systems to form a global NRS, thus each ENRS is expected to process about 10 million mobile devices’ a day and 10 thousand update requests per second. Fast update and synchronization mechanisms under mobility conditions must be designed to make EID accessible.

We have added the content about HEA’s update on page 7 paragraph 2 and discussed the name binding’s update frequency on page 12 paragraph 1. However, the issue of name binding’s synchronization is out of the scope of this paper.

Comment: B. Comments on related work

1. In general, the authors have done quite meticulous work regarding related work. There is still room for improvement:

1) I suggest adding "Popularity-aware intra-domain mobility management" by V. Siris in section 2.1. This is an approach using a popularity-aware intra-domain mobile content management model on the basis of which the NRS tracks the current location of mobile content only when the content has  sufficiently high popularity and sufficiently low mobility, while it discovers low popularity/highly mobile content via broadcasting. Scalability gains lie in reducing total signaling and memory requirements of the NRS. Such gains can be also seen in mobile caching solutions, using the same principle. The authors may also refer to, e.g., the work of Vasilakos et al. "Addressing niche demand based on joint mobility prediction and content popularity caching" where the interplay between mobility and popularity is more extensively studied or even the work of "Exploiting mobility prediction for mobility & popularity caching and dash adaptation" again by V. Siris et al.
Response: Thanks for your sincere advice. We have added the introduction about “Popularity-aware intra-domain mobility management” in related work, please see paragraph 4 on page 4 for more details.

Comment: 2) I suggest adding reference [42] as related work in section 2.1 about scalability, alongside the preceding work on "Cloud computing for global name-resolution in information-centric networks" by the same authoring team presented at IEEE Network Cloud Computing and Applications Symposium '12, which analyses DONA's scalability at a first stage and discusses the potential of cloud technologies towards enhancing scalability.

Response: We have added the introduction about paper “Cloud computing for global name-resolution in information-centric networks” to enrich the work on scalability in related work, please see paragraph 6 on page 4 in the revised edition of this paper for more details.

Comment: C. Wrong/incomprehensible language usage

Unfortunately, the language quality drops significantly at parts of the text, particularly in section 3, making it difficult to understand the important design aspects of the system. Some few examples are as follows:

- "REGISTER message will forward to proper HM in" - do you mean "be forwarded"?

- "nested Hierarchical Elastic Area (HEA) with" => "nested Hierarchical Elastic Areas (HEAs)"

- "DNHT is made up of which including the"  - I do not understand what the authors wish to say at this point.

Response: Thanks for your meticulous review of this paper. We have modified the language errors, including the errors you listed here and improved the writing of the whole article. In addition, we have added pseudocode of Algorithm 1 to make the solution design easier to understand, and improved the pseudocode of Algorithm 2 to make it consistent with Algorithm 1. In the article, the modifications are marked in purple with strikethrough and underline.

Comment: D. Evaluation results

1) Regarding the results of figure 6(b): The outcome presented in 6(b) is expected, but as a trade-off, the resolution latency should in principle also increase with the higher level of resolution. Is this right to assume? If so, then it necessary to present evaluation results that compare resolution latency and total traffic (in terms of a number of messages) next to the results of 6(b).

Response: Thanks for this suggestion. The relationship between resolution latency and resolution traffic is really a question worth thinking about. In our proposed ENRS, the upper bound of resolution latencies within each HEA in different hierarchies are deterministic and guaranteed by HEAs’ partitioning algorithm. The forwarding hops of registration and query requests are constant, of which the complexity is O(1), thus the traffic of single query is stable and constant. Thus, the resolution latency and total traffic is not a trade-off. In our paper, we have evaluated the resolution latency (please see Figure 7) and total traffic (please see Figure 9) in different conditions. In ENRS, we do a trade-off between the hit ratio and the resolution traffic under the condition of guaranteeing the deterministic resolution latency first.

Comment: 2) Regarding the results of figure 7:

Total traffic is better perceived in terms of a number of messages, not MBs which is subject to the setup details of the simulation evaluation experiments.

Response: Thanks for your suggestion. We have modified the figure using message count instead of MB to represent the total traffic, please see Figure 8 in page 20 in the revised paper. Since we added a new graph in the previous of the work, thus the number of the figure change from “7” to “8”.

Comment: 3) Regarding the results of figure 8:

The results on figure 8 show a good performance, however, this is partly due to the choice of benchmarks. A DHT-based NRS would most probably perform better. Nevertheless, I am not implying this is not an important and encouraging evaluation performance merit of the proposed system. I am only requesting to consider presenting a comparison to DHT-based systems or - if this is not feasible at this stage - at least comment on that and state why the proposed design has better overall merits.

Response: Thanks for your advice. 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 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) at the best case, while in the majority situation, the complexity would be logN, where N is the length of EID. Thus, the control overhead of DHT-based NRS may be larger than ENRS in general.

In order to show the merits of our proposed ENRS more clearly, we have added the discussion on the performance comparison between ENRS and DHT-based ICN name resolution system in paragraph 2 on page 20. Since we added a new graph in previous, thus the number of the figure change from “8” to “9”.

Author Response File: Author Response.docx

Reviewer 2 Report

This paper proposes a deterministic low latency name resolution service. 

- The problem statement is clear, but the proposed solution and explanation about proposed algorithms are not clear enough. 

- Need to describe the differences between existing "domain name system (DNS)" and the proposed ENRS, since the DNS also has cache and hierarchical structure and many researches have been proposed regarding these matters.

- Need to consistently describe algorithms 1 and 2. Recommend to use pseudo-codes. 

- Need more explanation about Fig. 3. No red star. Seems a missing green arrow. Numbering for each arrow according to the sequential procedures can make the figure more understandable.

- Need to explain the BF more in Fig. 3 using an example.

Minor typos

- line 215 for references

- line 219: provide -> provides

- line 459: registere -> register

- page 14: T1 should use subscripts 

Author Response

Response for Reviewer 2’s Comments

Dear editors and reviewers,

    I would like to submit a manuscript entitled “A Temporally Hierarchical Deployment Architecture for Enhanced Name Resolution System”, which I wish to be considered for publication in Journal of Applied Sciences. I believe the paper would be of particular interest to the readers of your journal. The comments and responses for the revised edition of our paper are written in the later of this article. The comments and suggestions are written in black and the responses are written in blue.

    Correspondence should be addressed to Yi LIAO, Yiqiang SHENG at the following e-mail address and phone number.

    E-mail: [email protected]; [email protected]

    Tel : +8615201226257

    Thanks for considering my manuscript for potential publication.  

                                                   Sincerely yours,

                                                      Yi LIAO

Comments and Responses:

Comment: 1. The problem statement is clear, but the proposed solution and explanation about proposed algorithms are not clear enough.

Response: Thank you for your suggestion. In order to make our proposed solution and explanation more clearly, we have added some content about the update of HEA (please see paragraph 2 on page 7), and added the comparison of proposed ENRS with current DNS (please see paragraph 5 on page 7 ). In addition, we have added the pseudo code of Algorithm 1 on page 9 to make the steps of the algorithm easier to understand.

Comment: 2. Need to describe the differences between existing "domain name system (DNS)" and the proposed ENRS, since the DNS also has the cache and hierarchical structure and many pieces of research have been proposed regarding these matters.

Response: To clarify the characteristics of proposed ENRS and DNS, we analyze the differences between DNS and ENRS into four aspects:

1) They are different in the working layers of the Internet. The DNS is working on the application-layer while our ENRS is working on network-layer.

2) The binding methods of them are different. DNS using early-binding technology that the bindings of URL and IP are static. If the IP is unreachable when data routing, the session is interrupted. While ENRS is support for the late-binding technique that the bindings of EIDs and NAs are dynamic. If the IP is unreachable, the equipment can initialize a new query with EID to get the latest IP of destination. URL is a hierarchical name and is related to the position the content resides, while EID is permanent and location-independent.

3) The name record caching methods of them are different. Both of DNS and ENRS can cache name records, DNS’s cache is reactive and is influenced by user’s request, while ENRS employ proactive name caching method to realize nearest-replica-routing of ICN

4) Message forwarding methods of them are different. DNS is in favor of recursive query while ENRS is support for constant hop resolution.

  We also add two ICN NRS applications which are realized on the basis of DNS. The contents mentioned above are added in paragraph 4-8 on page 7.

Comment: 3. Need to consistently describe algorithms 1 and 2. Recommend to use pseudo-codes. 

Response: Thanks for your suggestion. We have added the pseudocode for Algorithm 1, please see Algorithm 1 on page 9. We have also improved the pseudocode of Algorithm 2 to make it clear and consistent with Algorithm 1, the modification please see Algorithm 2 on page 12.

Comment: 4. Need more explanation about Fig. 3. No red star. Seems a missing green arrow. Numbering for each arrow according to the sequential procedures can make the figure more understandable.

Response: Thanks for your meticulous review. We have corrected the missing symbols in the figure and add the number of the procedures to make it easier to understand. Please see Figure 4 for more details on page 14. Since we have added a new figure in the previous work, the number of Figure 3 change to Figure 4.

Comment: 5. Need to explain the BF more in Fig. 3 using an example.

Response: We have added some description and a new figure using an example to illustrate the principles of BF, please see paragraph 3 on page 7 and Figure 2 on page 7 respectively. We also added two main advantages of BF when introducing BF at the beginning, please paragraph 7 on see page 4 for more details.

Comment: 6. Minor typos

- line 215 for references

- line 219: provide -> provides

- line 459: registere -> register

- page 14: T1 should use subscripts 

Response: Thanks for your meticulous review for this paper. We have corrected the typos in full and improved the writing of this article. The corrections are marked in purple with strikethrough and underline in the revised edition.

Author Response File: Author Response.docx

Round  2

Reviewer 2 Report

The revised version of the paper has properly covered the comments and issues provided for the previous version.

One minor comments

- Algorithm 2 should be in the same format as Algorithm 1 for better readability.

Author Response

    Thanks for your suggestion. We have added a new table to describe the meanings of symbols used in Algorithm 2, please see Table 2 on page 12. To make Algorithm 2 more clear to read, we have corrected the pseudo-code of Algorithm 2 to make it the same formate as Algorithm 1 and modified the steps of Algorithm 2 to make it more understandable, please see the pseudo-code on page 12 for more details.  In addition, we have corrected minor typos in the revised edtion of this paper, which is marked in purple in the newest edition of this paper.