Self-defense for gateways

As we have shown, gateways are vulnerable to host mismanagement of congestion. Host misbehavior by excessive traffic generation can prevent not only the host's own traffic from getting through, but can interfere with other unrelated traffic. The problem can be dealt with at the host level but since one malfunctioning host can interfere with others, future gateways should be capable of defending themselves against such behavior by obnoxious or malicious hosts. We offer some basic self-defense techniques.

On one occasion in late 1983, a TCP bug in an ARPANET host caused the host to frantically generate retransmissions of the same datagram as fast as the ARPANET would accept them. The gateway that connected our net with the ARPANET was saturated and little useful traffic could get through, since the gateway had more bandwidth to the ARPANET than to our net. The gateway busily sent ICMP Source Quench messages but the malfunctioning host ignored them. This continued for several hours, until the malfunctioning host crashed. During this period, our network was effectively disconnected from the ARPANET.

When a gateway is forced to discard a packet, the packet is selected at the discretion of the gateway. Classic techniques for making this decision are to discard the most recently received packet, or the packet at the end of the longest outgoing queue. We suggest that a worthwhile practical measure is to discard the latest packet from the host that originated the most packets currently queued within the gateway. This strategy will tend to balance throughput amongst the hosts using the gateway. We have not yet tried this strategy, but it seems a reasonable starting point for gateway self-protection.

Another strategy is to discard a newly arrived packet if the packet duplicates a packet already in the queue. The computational load for this check is not a problem if hashing techniques are used. This check will not protect against malicious hosts but will provide some protection against TCP implementations with poor retransmission control. Gateways between fast local networks and slower long-haul networks may find this check valuable if the local hosts are tuned to work well with the local network.

Ideally the gateway should detect malfunctioning hosts and squelch them; such detection is difficult in a pure datagram system. Failure to respond to an ICMP Source Quench message, though, should be regarded as grounds for action by a gateway to disconnect a host. Detecting such failure is non-trivial but is a worthwhile area for further research.