Browse Prior Art Database

Method to Prevent TCP Bandwidth Abuse

IP.com Disclosure Number: IPCOM000026357D
Original Publication Date: 2004-Apr-05
Included in the Prior Art Database: 2004-Apr-05
Document File: 2 page(s) / 30K

Publishing Venue

IBM

Abstract

This publication proposes a solution to detect and fix a misbehaving TCP implementation/client that is trying to get more than its fair share of bandwidth by artificially acknowledging unreceived packets in order to advance the senders window and thus obtain better bandwidth. This invention relies on the RTT estimate to detect if the receiver is misbehaving and if so proposes a solution to punish the misbehaving client.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 51% of the total text.

Page 1 of 2

Method to Prevent TCP Bandwidth Abuse

TCP/IP is the ubiquitous Internet protocol that forms an integral part of the communications infrastructure. It has many parameters that help provide guaranteed reliability, congestion control, rapid data flow increase to utilize available bandwidth among other features. However, some of these features can be abused by unscrupulous clients to usurp more than their fair share of bandwidth to the detriment of other clients. Described is one of these scenarios and propose a solution to prevent abusers from exploiting TCP features to get more than their fair share of bandwidth.

TCP operates using a sliding window protocol where data to the left of the window has been ackowledged and data to the right of the window has not been sent yet. The window is the region of interest for the sender and as the receiver ACKs the data in that region, the window moves to the right and more data is sent. Otherwise, the sender may have to retransmit the data if the ACK has not been received within a certain time limit (a function of the estimated round trip time from the sender to receiver).

Consider the following scenario where a misbehaving receiver (client) sends some forward ACK for some data it has not received. At that point in time it may be data that the sender may not have sent or the sender may have just sent. Also, the client probably does not care about the data (or is willing to take the chance of losing it just so that it can increase its bandwidth more rapidly than others) since it is willing to falsely acknowledge it. However, the sender on receiving the ACK will increase the window size (thus the bandwidth) and may even get a skewed (reduced) estimate of the RTT(round trip time) which will force it to transmit faster for this client and will unfairly impact others (produce more congestion while unfairly giving an advantage...