Review: TCP Nice: A Mechanis for Background Transfers

 
The paper presents an end-to-end congestion control algorithm optimized
to support background transfers. The idea is that the operating system
should manage network resources in order to provide a simple abstraction
of zero-cost background traffic. They claim that a self-tuning
background transport layer will simplify applications, reduce the risk
of being to aggressive and make it easier to reap a large fraction of
spare bandwidth to gain the advantage of background transfers. Their two
conflicting objectives are:
1) main: minimize interference with foreground traffic.
2) secondary: make use of a significant amount of available spare
network capacity (ideally 100%).
The paper briefly discusses the problems with TCP Reno's and TCP Vegas'
congestion control:
1) Reno: using packet loss as a signal is not suitable because by then
it is too late to avoid interference
2) Vegas & Reno: designed to compete for throughput
3) Vegas: backs off only when its own flow increases and not when
others' flow increases, that is, each flow tries to keep 1-3 packets in
the bottleneck queue, and hence background flows would interfere.
TCP Nice has made 3 additions to Vegas:
1) A more sensitive congestion detector: Nice flows monitor round-trip
delays, estimates the total queue size at the bottleneck router, and
signals congestion when it exceeds a fraction of the estimated maximum
queue capacity. If the congestion doesn't trigger, Nice falls back on
Vegas and if a packet is lost, it falls back on Reno's rules.
2) multiplicative reduction in response to increasing round trip times:
when a Nce flow signals congestion, it halves its current congestion
window. The authors say that the combination of more aggressive
detection and more aggressive reaction may make it more difficult for
Nice to maximize utilization, but their main goal is to minimize
interference.
3) Allow the congestion window to multiplicatively decrease below one:
so the flow continues to send as many packets into the flow as it gets
out. This retains the non-interference property even for a large number
of flows. Their analysis and experiments show that this optimzation
significantly reduces interference, especially when testing against
severeal background flows.
The authors provide a very simplified analysis of TCP Nice, and then go
on to verify their hypothesis with a set on ns controlled simualtions as
well as internet microbenckmarks. They show that TCP Nice improves
application peformance by making use of a significant amount of spare
capacity on the Internet in a non-interfering manner. Furthermore, it
simplifies application design by eliminatng the need to hand-tune
parameters to balance utilization and interference. Finally, Nice can
achieve useful amounts of throughput throughout the day.
The paper ends by describing two applications of TCP Nice: 1)Self-tuning
HTTP prefetching system and 2) support massive replication of data and
services.
The paper is well written, it explains the modifications in a clear and
incremental manner. They also specify initial values for estimates
(which was not done in the TCP Vegas paper). However, they prive a very
simplified analysis and then later skip out results due to lack of
space, I feel providing those results might have been more insightful
then the analysis.
Received on Thu Oct 05 2006 - 10:34:14 EDT