Summary: TCP Nice: A Mechanism for Background Transfers

This paper describes TCP Nice, a protocol intended for low-priority background
transfers, analogous to "niced" processes on Unix. The design goals are:
1. Cause no interference to demand (ie. ordinary) transfers
2. Consume 100% of the spare bandwidth

The protocol they describe is TCP Vegas with several modifications that they
proved and empirically demonstrated will lower the degree with which a TCP
Nice flow interferes with non-Nice flows.

TCP Nice uses the minimum observed RTT to estimate the no-queueing RTT of a
path, just as TCP Vegas. Additionally, Nice tracks the maximum RTT value in
an attempt to determine the maximum queue capacity at the bottleneck router.
If the ACK-time for more than a specified fraction of the packets that the
protocol sends during one RTT exceeds a threshold defined by the min/max RTT
times, the protocol aggressively backs off by dividing the window size by
two. Notice that this backoff is different than Vegas, which only linearly
backs off due to congestion avoidance signals (it only ever multiplicative
backs off in response to loss).

The protocol also allows window sizes to be divided down below one. For
example, a window size of 0.1 would cause the protocol to send out a packet
on every 10th RTT. The purpose of this optimization is to allow the
non-interference property to hold, even when there are many Nice flows and
comparatively fewer normal ones.

The basis for the protocol is analytically derived. The paper presents
empirical results based on ns simulations. Finally, the paper presents a
case study, where they consider the effects of HTTP prefetching using both
ordinary TCP and TCP Nice. The authors note that unless the authors of the
prefetching software are careful, they can actually increase the
client-observed latencies due to interference with the cache's own background
retrieval operation. However, if the cache uses TCP Nice, the cache software
need not carefully regulate its own network usage.
Received on Thu Oct 05 2006 - 01:56:18 EDT