Source-quench wrench

Fri, 26 Feb 88 19:23:00 EST


In a previous message I concluded that the source-quench policy implemented
for the NSFNET Backbone fuzzballs could in fact help reduce the impact of
severe congestion now affecting that network. This conclusion was reached on
the basis of scanty data involving a Cray TCP implementation.

Mike Minnich and I cooked up an experiment to determine the effectiveness of
the policy with the latest 4.3 TCP, including the Van Jacobson mods, and to
search for possible fairness problems. The experiment involves the following

        +-------+ +-------+ +-------+
        | | 10 Mb/s Ether | | 9600-bps | |
        |source |==============>|gateway|==============>| sink |
        | | | | | |
        +-------+ +-------+ +-------+

Data originates at the source (Sun/3), piles up at the gateway (fuzzball) and
is discarded at the sink (fuzzball). The gateway uses the same
selective-preemption and source-quench policies as in the NSFNET Backbone and
previously described to this list. In the experiment the traffic was four (4)
simultaneous FTP data connections, each with a max send window of about 4000
octets and a max receive window of about 2000 octets. There was enough
buffering that no packets were lost and only a few retransmissions during the
experiment, which involved a couple of megabytes.

The experiment was started with quench messages disabled at the gateway and
allowed to stabilize. The mean delay in the queue on the 9600-bps side of the
gateway was measured at about 6.3 seconds. Quench messages were then enabled,
with the result that the mean delay dropped to about 4.2 seconds, or a
reduction of about one-third. According to well-known results from queueing
theory, this means a reduction of one-third in buffering requirements as well.
All four transfers proceeded at similar rates, as confirmed by real-time

Without getting into a detailed discussion about the fuzzball or 4.3 TCP
implementations, it should be mentioned that the fuzzball sends ICMP Source
Quench messages to the host with the most data queued for transmission at a
rate depending on the excess of the measured mean queue length above a preset
threshold, in this case about 1.5. The 4.3 TCP reacts to a quench message by
immediately reducing the send window size and then allowing it to grow as the
result of ACKs for previously sent data. It would seem that the system
performance could be further improved by tuning the various time constants and
gain settings in both implementations.

Since much of the congestion now occuring in the NSFNET Backbone results from
very similar configurations, we conclude (a) the fuzzball policy can improve
system performance in a significant way and (b) the recent 4.3 mods should be
deployed quickly and to the widest possible extent.


This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:41:30 GMT