An Enhanced Virtual Cord Protocol Based Multi-Casting Strategy for the Effective and Efficient Management of Mobile Ad Hoc Networks

Round 1

Reviewer 1 Report

The article proposes to use a Virtual Coordinates System (VCS) to manage multicast groups and transmission within mobile ad hoc networks without the help of flooding. 

First of all, the paper feels a bit outdated in its wording (PDA, Infrared communication) and in the evaluation methods (NS-2, ...). For a subject that has been explored in the past, the reader would expect some real experimental results. 

In terms of bibliography, the authors do cite most of the key contributions, but could cite other articles such as https://ieeexplore.ieee.org/document/1264376 to get a more complete picture. 

However, my main concern with this research is that the protocol in itself is never really described in its details. The use of virtual coordinates is obscure and the only part of the proposal that is discussed is the capacity nodes have to accept registrations to the multicast group(s) they already belong to without notifying the source node.

First, this may cause some issues since the information on the members of a given group is scattered across the network, which may prevent rebuilding the groups in case of failure. The authors should elaborate on fault tolerance. 

Second, it is not possible to understand, from that description if, for example, the broadcast capacity of the radio medium is used or not. This can save a lot of energy and there have been a few articles on that topic in the past, for multicast (see above reference) and for flooding too. 

Finally, in the evaluations, there is no comparison with real alternative propositions, only with the plain VCS protocol whose objective is not the same. 

I therefore would recommend to clearly state the objective, better describe the proposition and improve the experimental results before publication. 

Author Response

Dear Reviewer,

Thank you very much for your time and efforts to review our paper. I believe that the quality of our manuscript has been enhanced after considering your comments/ suggestion. please see the attached file for detailed responses to your comments.

Thanks,

BR,

Sheraz

Author Response File: Author Response.docx

Reviewer 2 Report

- The abstract would be a little stronger with just one or two more sentences on context and motivation before you start talking about technical details. - The same comment applies to the introduction, I think you could include a short paragraph explaining the context and motivation for using multicast routing in ad-hoc networks. The introductory paragraph is written as if the reader should assume this is a given. Placing your solution in context and explaining why it's useful will make your results clearer and more compelling. - Is the blue text in response to a previous round of reviews? - Some minor language mistakes on page 2. - Figure 1 doesn't seem to be discussed in the text, I would like to see either a short paragraph on the route discovery it depicts or at least a detailed caption that walks through the flowgraph. - Is this pseudocode starting on line 81 supposed to have some kind of formatting? It is not displaying correctly for me, it just looks like text. - The background section would benefit from some subsection dividers to help break up the text and organize the narrative a little bit. - Figures 2 and 3 are properly referenced in the text this time, but I would still like to see some detailed captions, you have plenty of space for them. - If you're going to use a full page for Figures 4 and 5 then you may as well expand them to use all of the space and populate the captions a little more. - In this background section, you have cited plenty of relevant sources but the narrative is not as coherent as it needs to be. Why did these other others investigate these various techniques? How are the useful? What are their shortcomings? How does the literature relate to your contributions? What does your solution provide that isn't provided elsewhere? I would like to see a more coherent narrative that summarizes the field and places your work in this context. - I really like that you put the "Problem Statement" section right at the beginning of Section 3 in its own subsection, but as I read it I grow more confused about what specific problem you are solving. This discussion lacks context, clarity, and most importantly specificity about what the problem is, why it's a problem, and how you are going to solve it. Without a strong problem statement at the front, it is difficult for me to understand your results at first glance. - I need much more information about your simulation setup. What exactly are you doing? What are you measuring? How are you conducting experiments? What happens in said experiments? Do you have some kind of diagram that can help clarify the configuration? You could probably add a whole page just on your experimental setup and clearly explaining what your experiments are. - These results are very difficult to interpret, partly because the explanation of the setup was lacking, partly because there wasn't really any prior discussion about what these performance metrics are or what they mean, and partly because there simply isn't a lot of data. Is there really only one other comparable technique to compare your proposed method too? - As a whole, this manuscript feels like it was written specifically for a network engineer who is already an expert in multi-cast routing, not for the more general audience that I assume this journal is targetting. I think the biggest things that need to change to address this are:
a) Introduce your topics before you start diving into technical details or discussion. This can be as few as one or two sentences describing the topic as a whole (e.g. routing, casting, flooding, etc.). As it's written, the manuscript assumes that all of these things are familiar and therefore lacks a strong guiding narrative to contextualize the results.
b) Use stronger topic sentences to guide your discussion through different talking points. Many of your paragraphs start by immediately discussing details of a topic that hasn't been properly introduced, which makes it difficult to navigate the text, even for someone familiar with the various topics.

 

Author Response

Dear Reviewer,

Thank you very much for your time and efforts to review our paper. I believe that the quality of our manuscript has been enhanced after considering your comments/ suggestion. please see the attached file for detailed responses to your comments.

Thanks,

BR,

Sheraz

Author Response File: Author Response.docx

Round 2

Reviewer 1 Report

I thank the authors for their update that clarifies several points. However, I still have some reservations and questions that seem important to me and that are not solved by the new version.

 

Concerning the evaluation (Point #1), I  disagree that NS-2 is still among today's tools. 

It has not been updated since 2011 (version 2.35 that you use) and that version had several issues with the model of the MAC and radio layers (capture effect, shadowing etc.). The development efforts have been moved to NS-3 since then.

More generally, there has been many discussions about simulations accuracy in the past and research should definitely favor experimental results when possible. 

Simulations is a good tool to evaluate scalability of a tested protocol, but can hardly be the only source of evaluation anymore. 

There are several open experimental platforms on which protocols can be tested live with mobility and a large number of nodes.

 

 

Concerning the description of VCP (Point #3), I still don't have the description I am looking for. 

Behind that question is the evaluation of the overhead fore building and updating the DHT structure. 

If there is no flooding involved, there may be a larger number of transmissions to update the overlay and this needs to be evaluated. 

If I am taking the arguments from §2.2, your description sounds a lot like a link-state or distance vector (aka proactive) routing protocol to me. 

It only requires neighbor information, keeps a list of successors & predecessors, etc. and still they have scalability issues.

Please include a real 

 

Concerning point 4, it all comes to a balance. Would a protocol that has tremendous delay and PDR for only 1% of the requests be considered successful?

 

And I am not sure I have an answer from my question on using the broadcast characteristic of the network either. 

By this I mean that with one transmission you reach all neighbours in range, and this is something that can lead to excellent optimisation of flooding, and therefore is also very interesting for multicast if the paths are chosen wisely.

Author Response

Dear Reviewer,

Thank you very much for your time and efforts to review our paper. I believe that the quality of our manuscript has been enhanced after considering your comments/ suggestion. please see the attached file for detailed responses to your comments.

Thanks,

BR,

Sheraz

Author Response File: Author Response.docx

Reviewer 2 Report

[13] - The abstract rewrite is much better. [87] - The added explanation for Figure 1 is good. [87] - Algorithm 1 seems to be formatted properly now. [73] - The bulleted list of contributions helps clarify your narrative. [103] - Most of your text in Section 2.2 describes what VCP achieves but I would also like to see a sentence or two on what it does that is unique. [113] - The subcaptions of Figure 2 are small and hard to read. [168] - I think Section 2 is much stronger with the changes you made, I have no further requests. [189] - The updated problem statement and proposed system models are much stronger. [226] - The simulation setup explanation is much stronger, and most importantly in line 225 you have told me exactly what I wanted to see, which was "The main objectives of this study are: (a) to reduce the number of MAC transmissions, (b) to minimize the end-to-end delay, and (c) to maximize the packet delivery ratio". This is exactly what your three plots are and they are now properly introduced. I would break this sentence into an enumerated list to clearly separate it from the text. [239] - I previously complained about only comparing the proposed solution to VCP in Figures 9 - 11, but now that the setup is clearer I don't think you need to add any others; it is now clear that you are only measuring a delta from VCP. [268] - I previously complained that the manuscript as a whole was written for too narrow of a target audience. I think the extensive revisions have fixed this and your manuscript is now much more accessible and legible. [277] - The summary table here is fine, but can you also include some kind of quantitative conclusion about your three test metrics? For example: "The proposed enhanced VCP approach reduces the # of MAC transmissions by X %, reduces the end-to-end delay by Y %, and increases the packet delivery ratio by Z%". If you can summarize your results in a concrete, quantitative sentence like this I think your conclusion will be complete.
I may have been harsh in the initial review, but you have clearly made significant revisions to address my complaints and I think that all of my major points were addressed. Thank you for taking the time to make the changes.

 

Author Response

Dear Reviewer,

Thank you very much for your time and efforts to review our paper. I believe that the quality of our manuscript has been enhanced after considering your comments/ suggestion. please see the attached file for detailed responses to your comments.

Thanks,

BR,

Sheraz

Author Response File: Author Response.docx

Round 3

Reviewer 1 Report

The paper has not really been updated, a few new sentences give additional precision, but I find no answer to the deeper questions I had over the previous reviews. 

On the simulations vs. experimentations discussion, I understand that the simulations are only a first step, and I understand the stakes behind publishing works. Yet, from the perspective of the community, I don't see the value in publishing results in which the confidence level is low. I'll leave the final decision on this matter to the editorial board. 

Concerning scalability (which was not a request but could be an interesting aspect to highlight), why stop at 150 nodes and not go to a few thousands ? Also, why not compare the protocol to different, more traditional approaches?

Reviewer 2 Report

My feedback has been sufficiently addressed.