What to do when an ICMP Source Quench is received
We inform TCP or any other protocol at that layer when ICMP receives a Source
Quench. The basic action of our TCP implementations is to reduce the amount of
data outstanding on connections to the host mentioned in the Source Quench.
This control is applied by causing the sending TCP to behave as if the distant
host's window size has been reduced. Our first implementation was simplistic
but effective; once a Source Quench has been received our TCP behaves as if the
window size is zero whenever the window isn't empty. This behavior continues
until some number (at present 10) of ACKs have been received, at that time TCP
returns to normal operation.³ David Mills of Linkabit Corporation has since
implemented a similar but more elaborate throttle on the count of outstanding
packets in his DCN systems. The additional sophistication seems to produce a
modest gain in throughput, but we have not made formal tests. Both
implementations effectively prevent congestion collapse in switching nodes.
Source Quench thus has the effect of limiting the connection to a limited
number (perhaps one) of outstanding messages. Thus, communication can continue
but at a reduced rate, that is exactly the effect desired.
This scheme has the important property that Source Quench doesn't inhibit the
sending of acknowledges or retransmissions. Implementations of Source Quench
entirely within the IP layer are usually unsuccessful because IP lacks enough
information to throttle a connection properly. Holding back acknowledges tends
to produce retransmissions and thus unnecessary traffic. Holding back
retransmissions may cause loss of a connection by a retransmission timeout. Our
scheme will keep connections alive under severe overload but at reduced
bandwidth per connection.
Other protocols at the same layer as TCP should also be responsive to Source
Quench. In each case we would suggest that new traffic should be throttled but
acknowledges should be treated normally. The only serious problem comes from
the User Datagram Protocol, not normally a major traffic generator. We have not
implemented any throttling in these protocols as yet; all are passed Source
Quench messages by ICMP but ignore them.
Garth Grayson
Network Administrator
Caledonian Group Services Ltd .
Grand Cayman, Cayman Islands
( (345) 949-0050 (Main)
( (345) 914-4881 (Direct)
( (345) 949-8062 (Fax)
* garth.grayson@caledonian.com
& www.caledonian.com <http://www.caledonian.com/>
