Reviewer: Christoph Jechlitschek
Date: 10-13-2005
How would you rate this paper, relative to others we have read? bottom 50%
How would you rate your knowledge of the topic of this paper? familiar, but not expert
What problem or issue does the paper address? Why is it important?
They paper tells us that the appearance of receiver driven TCP stacks opened a new way for misbehavior. Because the receiver has all means and the incentive to accelerate it's transfer it is important that the sender can detect and punish misbehaving flows.
What are the main contributions of the paper and why are they important?
The authors review the architecture of receiver based TCP stacks and show possible ways of misbehavior. Then the discuss very shortly why detection of misbehavior inside the network is much harder if possible at all. Then the authors possible ways to detect misbehaving flows by using a senderside TFRC agent that calculates the "correct rate". I the single scenario that they used an flow that uses more than 1.8 time the calculated rate is with a high probability a misbehaving flow. The authors showed further that to much short term misbehavior reduces not only the throughput of the background traffic but also had severe impact on the misbehaving flow as well. The authors solutions to that are rate limiting (which is not work conserving) and the enforcement of exponention backoff. The final conclusion is that it is very difficult to distinguish between good and bad flows.
How significant are these contributions relative to previous work?
I don't know about previous work.
Give detailed comments justifying your view of the paper.
I put this paper into the bottom 50% because i think it doesn't provide us with any new insights. The title makes us to expect a thorough evaluation of performance versus trust, but what the paper shows is different. The authors came up with the idea of computing the "correct" throughput for each flow with help of a simple formula. They showed in two experiments that it is very hard the decide on a ratio of measured/computed throughput that split between good and misbehaving flows. Therefore, they concluded, you always have the tradeoff between protection and protocol innovation. (To be honest, I could have told you the same thing even without running experiments.) So what I'm complaining about is that in my opinion they should have looked at other possible methods to detect misbehavior before generalizing from a single failing case.