All reviews of published articles are made public. This includes manuscript files, peer review comments, author rebuttals and revised materials. Note: This was optional for articles submitted before 13 February 2023.
Peer reviewers are encouraged (but not required) to provide their names to the authors when submitting their peer review. If they agree to provide their name, then their personal profile page will reflect a public acknowledgment that they performed a review (even if the article is rejected). If the article is accepted, then reviewers who provided their name will be associated with the article itself.
It appears that the comments from both reviewers have been addressed.
Please respond to the reviewer comments in a revised version, with special attention to comparisons with the ComboCoding work that the second reviewer mentioned.
No comments.
No comments.
No comments.
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
No Comments
No Comments
No Comments
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.
Please carefully address the comments from both reviewers, especially the second reviewer, in the next round of major revision of this manuscript.
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.
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.
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.
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.
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.
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.
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.