Response for Receiver-Centric Congestion Control with a Misbehaving Receiver: Vulnerabilities and End-Point Solutions
Reviewer #1: 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
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.
(*) We do not show the impact of misbehaving RCP flows on the
background traffic in Figure 15 because these effects have essentially
already been shown in Figure 3, and then analyzed in Section 3. The
key point of Figure 15 is to demonstrate that being too greedy does
not pay off, and that the attacker should be careful when tuning its
parameters. We change the text on page 23 (below Figure 15), to
better bring out these points.
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.
(*) We change the titles/subtitles in Section 6 as suggested by the
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.
(*) We change the text on page 19 to convey the above point.
Reviewer #2: 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.  instead of
(12), which can be Equation (12))
(*) We also like square brackets better, but for COMET submissions, we
are forced to use the elsart.cls style file, which provides the given
2. In the footnote 4 (which refers to Equation (2)), the authors cited
the deterministic model in . 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
(*) We cite the above reference.
3. On p.11, in the paragraph below Fig. 4, "..... and RTO=1". What is
the unit? 1 second?
(*) It is 1 second. We fix the text on page 11.
4. In section 4.1 paragraph 3, the authors propose two methods to
measure the RTT with an un-trusted 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.
(*) The reviewer is correct in both observations. Still, despite
potentially different treatment of pings at routers, they are still
almost exclusively used to measure delay in the Internet. Regarding
the TCP probing, once a port replies to TCP probes, no other ports
need to be scanned, and thus it will not look as a port scan attack.
Anyhow, we believe that any client that applies a receiver-based
congestion control must provide a port number that would enable
servers to independently control clients' behavior. We add a
discussion along these lines in Section 4.1 on page 14.
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?
(*) Using receiver-centric method still makes sense because it affects
not only performance, but also provides additional functionality gains
that are briefly outlined in Section 2.2.2; in summary, reduce the
protocol state on the servers which must handle large-scale workloads,
avoid connection disruptions during handoff, etc. Detailed analysis
could be found in reference .
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)
(*) In Section 6, we evaluated the RED-PD method, and discuss many
others. We accordingly change the text in the 3rd paragraph on page 3
to: "Second, we evaluate and discuss ."
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)
(*) All the results in the paper are obtained via ns2 simulations. We
change the text below Figure 3 to indicate this explicitly. We change
"experiment" to "simulation." Regarding the network topology, we do
not discuss it below Figure 3, because that might destruct the main
message we want to send here, which is that the attack is quite
effective. Thus, we make a future reference to Section 4 (page 15),
which is where we provide more details about the simulation. Also, the
ns2 simulation code is publicly available at
http://www.ece.rice.edu/networks, as indicated on page 15.
Reviewer #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
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.
(*) The first issue is the frequency of RTT measurements taken to
compute the TCP-friendly rate at the sender. In our design, we take a
single measurement per RTT. This is exactly what all TCP stacks do.
Despite the fact that they typically have a larger number of samples
per RTT, only one sample per RTT is used to compute the smoothed RTT
(SRTT). The second issue is the responsiveness of TFRC algorithm and
its ability to track changes in the network. This issue has been
analyzed in depth in reference , and it has been shown that TFRC
is capable of successfully avoiding persistent overload in highly
dynamic scenarios. In our paper, we change the text on pages 14 and 16
to better explain the above two issues.
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
(*) As discussed above, in our design, a sender probes the
corresponding receiver approximately once per RTT. Consider a scenario
in which the throughput between the two endpoints is limited by the
receiver advertised window, which is typically the case in today's
Internet (we add the appropriate reference in the paper). Consider the
receiver advertised window of 64 kBytes. In such a case, the overhead
imposed by a single ping per RTT is 40 Bytes / 64 kBytes = 0.0625%. In
absolute terms, consider 100 clients hosted by a server and average
RTT of 100 ms. The throughput overhead due to out-of-band pinging
becomes 40 kB/s. We add a paragraph on page 14 to explain the overhead
I have no objection publishing the paper once the aforementioned
concerns are cleared.