Review History


To increase transparency, PeerJ operates a system of 'optional signed reviews and history'. This takes two forms: (1) peer reviewers are encouraged, but not required, to provide their names (if they do so, then their profile page records the articles they have reviewed), and (2) authors are given the option of reproducing their entire peer review history alongside their published article (in which case the complete peer review process is provided, including revisions, rebuttal letters and editor decision letters).

New to public reviews? Learn more about optional signed reviews and how to write a better rebuttal letter.

Summary

  • The initial submission of this article was received on May 21st, 2016 and was peer-reviewed by 2 reviewers and the Academic Editor.
  • The Academic Editor made their initial decision on June 8th, 2016.
  • The first revision was submitted on August 1st, 2016 and was reviewed by 2 reviewers and the Academic Editor.
  • A further revision was submitted on September 6th, 2016 and was reviewed by the Academic Editor.
  • The article was Accepted by the Academic Editor on September 7th, 2016.

Version 0.3 (accepted)

· · Academic Editor

Accept

It appears that the comments from both reviewers have been addressed.

Version 0.2

· · Academic Editor

Minor Revisions

Please respond to the reviewer comments in a revised version, with special attention to comparisons with the ComboCoding work that the second reviewer mentioned.

·

Basic reporting

No comments.

Experimental design

No comments.

Validity of the findings

No comments.

Comments for the author

The paper has been improved significantly and should be accepted except the following minor issues:

1. The authors' response to my concern on the file size in the evaluation is
not fully convincing. The authors argue that the decoding delay is not overly
significant and can be comparable with the file-wise delay. This may still mean that
the additional latency to transmit a small file can be larger than TCP without
NC. A more explicit and clearer explanation is needed in the paper.

2. The font size in Fig. 5/6/7/8/11 is still too small, and
much smaller than the font size in other figures. Please update and make them
consistent. Besides, colors of TCP+NC and TCPFender in Fig. 6/7/8 still look similar in
greyscale.

3. Please correct the following typos:
line 25: became -> become
line 294: an -> a

Reviewer 2 ·

Basic reporting

No Comments

Experimental design

No Comments

Validity of the findings

No Comments

Comments for the author

I'm glad to see that some of my previous comments have been carefully addressed. For example, additional related works have been cited and discussed, and the important concept of `innovative packets' has been explained in detail.

To justify the novelty of the paper, the authors stated (in their response) that the main contribution of the paper is to ``design an adaptation layer over the network layer to support TCP-Reno without any change to TCP-Reno itself" instead of the two extensions of MORE (which have been proposed before). In addition, the authors claimed that their paper is the ``first paper that is designed to support TCP Reno by opportunistic data forwarding and network coding" in wireless multi-hop networks. This is a strong claim! However, this claim doesn't seem to be convincing. For example, the work of ComboCoding (by Chien-Chia Chen, Mario Gerla, and others) proposed a network-coding scheme that is ``implemented in the network layer" and is ``transparent to TCP." In particular, their scheme supports a variety of TCP protocols, including TCP-Reno and TCP-NewReno.

Therefore, I'd like to suggest the authors to compare their work with ComboCoding and other similar works.

Version 0.1 (original submission)

· · Academic Editor

Major Revisions

Please carefully address the comments from both reviewers, especially the second reviewer, in the next round of major revision of this manuscript.

·

Basic reporting

This paper contains a lot of typos or grammatical errors to correct.
In line 54, showes -> shows.
In line 55, opportunisty -> opportunity.
In line 128, in a same batch -> in the same batch.
In line 158, a crucial importance -> of crucial importance.
In Figure 1, fowarding -> forwarding.
In line 236, initially -> initial.
In line 268, it -> its.
In line 306, each links -> each link
In line 307, ploted -> plotted.
In line 313, throughput -> throughputs.
In Figure 8, througput -> throughput.
Besides, there are articles missing in some cases. Please correct them.

The introduction of background knowledge and related work is thorough. Though it is a choice of style, I think that many citations in the first three paragraphs of the introduction can be moved to related work.

Fonts of numbers in Figure 5 look very small, and colors of TCP and TCPFender are hard to differentiate in Figure 6, 7, and 8, when printed in the greyscale. Also, the legend is missing in Figure 7.

The code and raw data relevant to the performance evaluation are not available.

Experimental design

In this paper, the authors propose a solution that incorporate opportunistic forwarding and network coding with the loss-based TCP congestion control algorithm. The studied question is defined clearly and interesting. The key idea of this solution is an adaption layer working between TCP and the network layer, which can encode and send multiple batches of data simultaneously at the source, and provide early congestion feedback at the destination.

Validity of the findings

In this paper, all nodes including the source, forwarders, and the destination need to store packets in multiple batches. It is not shown in this paper that how much more memory will be used to store packets from multiple batches, under different network conditions.

In the evaluation, a large file is transmitted and the throughput is the major metric measured. As the elephant flow is typically not sensitive to the delay, it would be interesting to investigate if TCPFender could improve the delay of mice flows that are not sensitive to throughput but delay.

Besides, as stated in the paper, opportunistic forwarding may introduce extra packets which can congest the network and hurt the actual goodput. However, it is unknown how many extra packets in total are transmitted through the network. Moreover, the reviewer suggests evaluating the performance with background traffic.

Reviewer 2 ·

Basic reporting

Some important prior literature is missing. For example, the following paper also extends MORE to allow multiple batches to flow in the network:

[R1] Y. Lin, B. Li, and B. Liang, ``CodeOR: Opportunistic routing in wireless mesh networks with segmented network coding," IEEE International Conference on Network Protocols (ICNP), 2008.

In fact, the work of MORE has been cited over 1000 times. So, I believe that more papers should be discussed in the section of Related Work.

Experimental design

I believe that the concept of `innovative packets' should be explained in more detail, because it is an important concept in the design of TCPFender.

Validity of the findings

It is unclear that how many simulations have been conducted for each experiment. Without such information, it is hard to assess the statistical significance of the conclusions.

Comments for the author

This paper proposes a new TCP scheme that supports opportunistic routing and network coding. The proposed scheme extends MORE in the following ways. First, the scheme applies accumulative coding so that the source can perform random linear network coding before it collects all the packets in a batch. Second, the scheme allows multiple batches to flow in the network. With these two extensions, the paper proposes a variant of TCP-Reno on top of MORE, which is called TCPFender.

However, I don’t think that the paper can be accepted in its current form. My concern is mostly about the novelty of the paper. First of all, the idea of `accumulative coding’ is well known in the literature of network coding. So, its application to multi-hop wireless networks is quite straightforward. Second, the idea of allowing for multiple batches in MORE has already been studied in several papers including [R1] mentioned above. Therefore, the proposed two extensions of MORE in the paper do not have sufficient novelty.

Another concern of mine is about the simulation part of the paper. In particular, the paper only compares its proposed scheme with MORE, but not with some extensions of MORE (such as CodeOR proposed in [R1]). Since the work of MORE receives more than 1000 citations, there must be plenty of good extensions in the literature. Some exemplary ones should be compared with the proposed scheme in this paper.

Therefore, I would like to suggest the authors to conduct a comprehensive literature survey on the extensions of MORE and then revise the paper accordingly.

All text and materials provided via this peer-review history page are made available under a Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited.