[CSC2231] Paper Review: TCP Congestion Control with a Misbehaving Receiver

From: Kenneth Po <kpo_REMOVE_THIS_FROM_EMAIL_FIRST_at_eecg.toronto.edu>
Date: Mon, 31 Oct 2005 01:08:37 -0500

This paper looks for enhancements to the existing TCP protocol to
prevent TCP clients from exploiting TCP congestion control to obtain
higher transfer speed than usual. It lists three ways a receiver can
play with the TCP acknowledgments to fool the sender such that more data
will be sent in the next window. The authors suggest the use of nonce to
create a data dependency between the data and the acknowledgment
messages to resolve these problems.

I think the contribution of this paper is that it identifies two new
vulnerabilities of the well-established TCP protocol. Since the TCP
congestion control protocol is created for the good of the whole
Internet community, it should not tolerate greedy individuals to get
higher speed than they should. The disclosure of these vulnerabilities
certainly urges the protocol designers to fix the bugs.

I personally do not believe the nonce approach is a good solution. Since
this paper focuses on misbehaving receivers only, this means the sender
can perform more robust checking before it increases its cwnd value. For
example, the sender can keep track of the number of acknowledgments
received versus the number of data messages being sent in a window. If
the number of acknowledgments is more than the number of data messages,
then there is a potential congestion or misbehaving receiver. In both
cases, the cwnd value should not be increased to worsen the situation.
If it is really a misbehaving receiver that causes the problem, the lack
of increase in data throughput shall discourage the receiver from
issuing more acknowledgments than it should. If a few more simple checks
will fix the problem, I don't see the necessity to modify the TCP
envelop structure to accommodate the nonce field.
Received on Mon Oct 31 2005 - 01:09:00 EST

This archive was generated by hypermail 2.2.0 : Mon Oct 31 2005 - 02:46:04 EST