TCP Nice Review

From: Vladan Djeric <djeric_at_eecg.toronto.edu>
Date: Wed, 4 Oct 2006 22:32:27 -0400

TCP Nice is a modification of TCP Vegas designed to provide a mechanism
for background transfers. It is important to develop a general
algorithm for tuning the aggressivenes of such mechanisms because
incorrect hand tuning could complicate applications, interfere with
other applications, and leave available bandwidth unused. Having the
operating system manage the resources provides a more elegant and
reliable solution. Toward this end, TCP Nice can provably bound the
interference of background transfers with "foreground" flows.

TCP Nice makes 3 additions to TCP Vegas: more sensitive congestion
detection, multiplicative reduction in response to increases in RTTs,
and reducing the congestion window below one. In order to be more
atuned to congestion, TCP Nice determines minimum and maximum values of
RTT and uses these numbers to determine whether bottleneck queue size
has exceeded a threshold which would eventually signal congestion and
multiplicatively decrease the window size. If congestion is not
signaled, TCP Nice reverts to Vegas congestion avoidance. Window sizes
below one mean that the sender should wait the corresponding number of
round trips before transmitting a packet.

Experiments and simulations show that TCP Nice interferes little with
foreground flows, uses a large portion of unused bandwidth, and
simplifies the development of applications which employ background
transfers. In fact, Nice is able to nearly approximate the results of
an ideal reouter-piroirtiziation stratgegy. TCP Nice flows interfere
with Reno flows by a factor that falls exponentially relative to the
size of the buffer at the bottleneck router, regardless of the number of
flows. Further, foreground flows' latency and bandwidth experience
insignificant changes in the presence of background Nice flows.
Finally, experiments show that there is a wide range of permissible
values for threshold although it is unclear what the trade-offs may be
in choosing a threshold value. This is exacerbated with the use of RED
queues.
Received on Wed Oct 04 2006 - 22:32:31 EDT

This archive was generated by hypermail 2.2.0 : Wed Oct 04 2006 - 22:38:18 EDT