------------- Review from Reviewer -------------
Evaluation of work and contribution : 9
Significance to theory and practice : 7
Originality novelty : 7
Relevance to the call of papers : 9
Readability and organization : 9
Overall recommendation : 9
Reviewer familiarity : 6

-- Comments to the author(s):
This paper addresses the problem of how a sender prevents a
malicious receiver from manipulating a receiver-drivien
congestion control protocol in order to get more than its
fair-share of bandwidth or deny service to others. This is an
interesting problem and the paper is generally well-written.

I take issue with the authors on two main points. First, the
whole paper is based on the notion that senders are benign, while
receivers are potentially malicious. There is a fundamental flaw
here in relying on the good will of end-systems to protect the
network. While there is an argument that since most traffic
originates at large information providers, which are less likely
to be irresponsible, senders can be more readily trusted than
receivers. But this is a weak argument, at best.

Second, the authors are much too quick to dismiss the application
of fair queueing techniques in the network to address these
issues. The authors seem to be making the bizarre argument that
because fair queueing algorithms give equal bandwidth shares to
flows, rather than penalizing flows with large RTTs, as TCP does,
that they are somehow deficient. I find it very weird that the
authors choose to rationalize one of TCP's shortcomings to such a
degree that it becomes a feature, rather than a bug.

In the performance results, it's often difficult to clearly
identify the different curves in the charts. This is mainly
because the charts rely on legends, which are a real nuisance for
a reader trying to get a full understanding of the data. Please
label the curves explicitly, so that the reader can see
immediately what curve corresponds to what case.

Also, the chart in figure 9 appears to be missing some data. I
trust that a complete version will appear in the final paper.

-- Summary:
Accept.
---------- End of Review from Reviewer ----------

------------- Review from Reviewer -------------
Evaluation of work and contribution : 8
Significance to theory and practice : 8
Originality novelty : 7
Relevance to the call of papers : 10
Readability and organization : 9
Overall recommendation : 8
Reviewer familiarity : 10

-- Comments to the author(s):

This paper examins the security aspect of receiver-driven CC, and
how they can be modified by untrusted receivers to achieve more
than its fair share of resources or to simply attack a sender.
the atuhors, descirbe various ways that such a mis-behavior can
be conducted, illustrate its impact on different time scales,
show the limitations of previously proposed mecahnisms to protoct
against these mis-behaved receivers, and finally proposes some
alternative solution.

The main benefit/contribution of this paper is to present the
proble in such structured manner, and identify some of the key
design tradeoffs between trust and performance, rather than the
specific mechanism that they proposed. The paper is more of
"evaluation of key design tradeoffs" than presenting a specific
solution.

The paper is well written, and well structured.
-- Summary:
none
---------- End of Review from Reviewer ----------

------------- Review from Reviewer [1] -------------
Evaluation of work and contribution : 9
Significance to theory and practice : 9
Originality novelty : 9
Relevance to the call of papers : 10
Readability and organization : 10
Overall recommendation : 9
Reviewer familiarity : 6

-- Comments to the author(s):
The paper study the deployability of receiver driven TCP (RCP)
with misbehaving receivers which can potentially tamper with the
congestion control algorithm to steal resources or for DoS
attack. The paper proposes an end-point solution for detecting
misbehaving receivers with high probability. The solution
compares the TCP throughput measured at the sender with the TCP
friendly rate obtained by TFRC (computed throughput) to detect
misbehaviors. If the ratio of the measured throughput to the
computed throughput exceeds some preset threshold a misbehavior
is detected, However because TFRC througput is conservative there
is a probability of false detection. The authors compare the
false positive probability and the false negative probability for
different types of misbehavior. The authors conclude that end
point solutions can potentially detect long-time scale receiver
misbehaviors and enforce TCP-friendly rate but such enforcement
removes the performance benefits of receiver-driven protocols.
By arguing that moderate bandwidth stealers can be overlooked the
authors show the possibility of acheiving a balance between
protocol performance and vulnerability to misbehaviors.

The reviewer feels the problem discussed is very relevant, the
motivation is quite appealing and the conclusions from this
study shall provide valuable guidelines in the deployment of RCP.


Some interesting issues:
1. What should be the approach to detect short-time scale behaviors ?
What can be a representative "computed rate" to compare for
short-time scale misbehaving scenarios ?

2. What will happen in a multicast scenario ? When there are multiple untrustworthy receivers, how will the sender detect misbehaviors ?
-- Summary:
The paper study the deployability of receiver driven TCP (RCP)
with misbehaving receivers which can potentially tamper with the
congestion control algorithm to steal resources or for DoS
attack. The paper proposes an end-point solution for detecting
misbehaving receivers with high probability. The solution
compares the TCP throughput measured at the sender with the TCP
friendly rate obtained by TFRC (computed throughput) to detect
misbehaviors. If the ratio of the measured throughput to the
computed throughput exceeds some preset threshold a misbehavior
is detected, However because TFRC througput is conservative there
is a probability of false detection. The authors compare the
false positive probability and the false negative probability for
different types of misbehavior.

The paper addresses an important problem and is very well written.
The reviewer is very much impressed by the presentation style
(the authors first model misbehavior, study proposed network
solutions to detect misbehaviors and point out their inherent
limitations and then propose a novel end-point solution to detect
long-time scale misbehavior). The authors conclude that end
point solutions can potentially detect long-time scale receiver
misbehaviors and enforce TCP-friendly rate but such enforcement
removes the performance benefits of receiver-driven protocols.
By arguing that moderate bandwidth stealers can be overlooked the
authors show the possibility of acheiving a balance between
protocol performance and vulnerability to misbehaviors. Further
short-time scale misbehaviors are shown to severly degrade
response-times of well behaving HTTP clients.

The reviewer feels the problem discussed is very relevant, the
motivation appealing and the conclusions from this study shall
provide valuable guidelines in the deployment of RCP.

Some interesting issues:
1. What should be the approach to detect short-time scale behaviors ?
What can be a representative "computed rate" to compare fwith for
detecting short-time scale misbehaving scenarios ?

2. What will happen in a multicast scenario ? When there are multiple untrustworthy receivers, how will the multicast sender detect misbehaviors ?
---------- End of Review from Reviewer [1] ----------

------------- Review from Reviewer
-------------
Evaluation of work and contribution : 5
Significance to theory and practice : 5
Originality novelty : 5
Relevance to the call of papers : 9
Readability and organization : 6
Overall recommendation : 7
Reviewer familiarity : 7

-- Comments to the author(s):
(same as my sigcomm review - since not much has changed)

The paper describes a simple mechanism to verify TCP-friendliness of a
connection using information available at the end hosts.


The problem of detecting misbehaving Internet hosts is important.

The proposed scheme is simple (i.e. not very innovative) and the evaluation
is weak.

The problem addressed in this paper is indeed both important and
interesting. The title of the paper lead me to believe that the paper
will describe interesting tradeoffs between performance and end-point
congestion control. Instead, the paper presents a simple proposal
proposal - just verify that the bandwidth received by this connection
is within the bounds predicted by a TCP model. There is very little
discussion of the tradeoff mentioned in the title. This tradeoff itself
can be a topic of a nice theoretical study. It also seems that the
authors are saying that this scheme is appropriate only for receiver-based
congestion control. This is fine, but as of now, sender-based congestion
control is more common. The evaluation is also weak - based only on
simulations. To improve the paper, the authors should consider the
following:

- Why focus so much on RCP and receiver-driven protocols? Yes, they are
probably a good idea in many situations, but they are not yet common. It
would be good to discuss how this work applies (which it does) to more
common sender-based congestion control as well.

- I would have liked to see some numbers about how common misbehaving
receivers really are. For example, observe a busy web server for a month
or so, and see how many (if any!) misbehaving receivers show up. This
would provide a much more concrete motivation.

- One way a receiver might cheat is by opening multiple conformant
connections when possible (e.g. in case of an HTTP server). This is
perhaps less of a concern than a receiver that cheats outright. However,
the paper should at least discuss this in some detail.

- The evaluation is based only on simulations. It would have been nice to
see a real implementation of the scheme. A major drawback of any end-host
based scheme is the extra work required by the end host. A good way to
measure this overhead is to implement the scheme, and run it alongside,
say, a busy web server. Without overhead numbers from a real implementation,
the paper is incomplete.

- More theoretical discussion of the tradeoff mentioned in the pape
should be added. For example, the parameter "k" in the Eq (6) controls
the threshold for this tradeoff. Do the authors have any thoughts on
how to automatically set the value of k? Perhaps it should be dependent
on the load on the server? (at low load, do we care if a receiver
is misbehaving?)

-- Summary:
see above.
---------- End of Review from Reviewer