blank.gif (43 bytes)

Church Of The
Swimming Elephant

What to do when an ICMP Source Quench is received Connected: An Internet Encyclopedia
What to do when an ICMP Source Quench is received

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 896
Up: The two problems
Up: Congestion control with ICMP
Prev: When to send an ICMP Source Quench
Next: Self-defense for gateways

What to do when an ICMP Source Quench is received

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.

Next: Self-defense for gateways

Connected: An Internet Encyclopedia
What to do when an ICMP Source Quench is received


Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

Have you gone to church today?
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609