Response for Receiver-Centric Congestion Control with a Misbehaving Receiver: Vulnerabilities and End-Point Solutions

The authors investigate the vulnerabilities that arise from misbehaving receivers, focusing on end-to-end approaches. The types of vulnerabilities studied include DoS attacks and resource stealing. The authors extensively explore the effects of maintaining modified AIMD parameters, as well as a reduced RTO value. The paper provides both numerical and experimental results which demonstrate the impact of manipulating these parameters by misbehaving receivers.

The paper can be improved if the authors take the following into consideration:

The authors occasionally make speculations/assumptions without providing the corresponding results (e.g. Fig. 15 - the direct effect of a greedy receiver on corporate traffic is not shown). Such results can be easily included and improve the evaluation quality.

The Related Work Section, apart from summarizing relevant studies, includes some experimental work and discussion. Either the title of the section should be changed, or the experimental work should be placed separately in another section - so that the specific section would contain only a summary of related work. Generally, a subsection "End-to-end vs network-based solutions" would further promote the benefits of end-point approaches.

TCP Westwood (especially in its initial version) does not yield significantly improved TCP performance over wireless links. The protocol is not able to decouple wireless from congestive losses. Some gains might be achieved, since the protocol avoids the "blind halving" of cwnd in response to a wireless error; instead it employs a gentle reduction in the cwnd maintaining a higher transmission rate than standard TCP. Along these lines, a subsequent version of Westwood can be alternatively used (i.e. Westwood+), or another TCP variant which is tweaked for wireless environments.

This paper analyzes a set of possible receiver misbehavior and their impact on TCP-friendliness. It further proposes sender-side mechanisms designed to detect and thwart receiver behavior.Esepcially, the authors studied two cases of misbehaving receivers: (a) modifying protocol stacks that maximize their own throughput without regard to fairness or network stability and (b) attackers that seek only to transmit at a high rate in order to deny service to others.

The topic is interesting and important. The paper is very well written and organized, and is overall technically deep.

This paper can be improved on the following issues:

1. The citations should be in square bracket (e.g. [12] instead of (12), which can be Equation (12))

2. In the footnote 4 (which refers to Equation (2)), the authors cited the deterministic model in [24]. However, I'm very surprised that the following paper providing a stochastic model is not cited, since it's very close to the work shown in the Appendix.

"General AIMD Congestion Control", Yang Richard Yang and Simon S. Lam. Technical Report TR-00-09, Department of Computer Sciences, UT Austin, May 9, 2000. A shorter version appeared in Proceedings of ICNP '00, Osaka, Japan, November 2000

3. On p.11, in the paragraph below Fig. 4, "..... and RTO=1". What is the unit? 1 second?

4. In section 4.1 paragraph 3, the authors propose two methods to measure the RTT with an untrusted receiver. However, in some routers, ICMP messages (e.g ping) are placed in a separate queue with different weights/priority. The problem with the other method is that it looks like an attack (port scan) and can trigger security alarms. Some discussions are necessary.

5. Another question is: if the sender can simply measure RTT and packet loss rate, and the maximum rate allowed by TCP-friendliness is set by Equation (1), why not just use something like TFRC? Of course a misbehaved TFRC receiver may cheat the TFRC sender with incorrect packet loss rate. How about replace the RTT measurements and packet loss reports in TFRC by the mechanism proposed by this paper?

Furthermore, if the sender can simply measure RTT and packet loss rate, and the maximum rate allowed by TCP-friendliness is set by Equation (1), why still use receiver-oriented method?

6. In the 3rd paragraph on p.3 ("Second, we evaluate ..."), the authors claim that a set of router- and edge- based mechanisms are evaluated, and this is the second major contribution of this paper. However, I can only find some discussions in Section 6 (Related Works)

7. I assume most of the results in the paper are obtained through ns2 simulation. ns2 is mentioned somewhere in the middle of the paper. However, this should be clarified before the first result (Figure 3) is presented. At the end of p.8, it is said that "In the experiment, ...". If it is really based on ns2, it is a simulation rather than an experiment. In addition, the network bandwidth and topology are missing in the descriptions of several results (e.g. Figure 3)

The paper presents the performance and functionality gains that a fully receiver-centric congestion control protocol can achieve, and discusses the vulnerabilities induced by misbehaving receivers that manipulate protocol parameters. Next, the authors suggest a sender-side protection mechanism that tries to detect bandwidth-stealing receivers.

I generally agree with the conclusions of the paper, especially with the statement that network-based solutions are limited in their ability to detect and punish end-point misbehaviors. Such solutions also add to the complexity of the network and are less easily deployable than end-point solutions.

Nevertheless, I have some concerns regarding the end-point scheme for misbehavior detection proposed in the paper. This sender-side scheme (which includes a TFRC agent for accomplishing its task) must estimate RTT and packet loss ratio in order to compute and possibly enforce the TCP-friendly rate in real time. Yet not much attention is paid to the frequency of RTT measurements taken to compute the TCP-friendly rate at the sender. Due to the dynamic nature of network congestion and especially in scenarios of rapidly and/or drastically changing network conditions, such changes must be promptly tracked and reflected in the senders' data sending rate. Considering also that TFRC (which essentially decides about the target sending rate) responds mildly to network congestion, this fact coupled with infrequent RTT measurements can possibly result in persistent congestion.

However, apart from the increased sender-side implementation complexity (think of a server serving 100s of clients or even more), another issue that arises is the overhead induced by senders trying to estimate the current RTT value: the sender transmits ping packets or short TCP packets (at a random port number) to conclude what the current RTT is. The impact of this overhead is not shown in the paper, especially in cases of high contention where this overhead is increased too.

I have no objection publishing the paper once the aforementioned concerns are cleared.