RFC 1018 (rfc1018) - Page 2 of 3
Some comments on SQuID
Alternative Format: Original Text Document
RFC 1018 Some Comments on SQuID August 1987 behavior proposed in RFC- 1016 may be appropriate for both cases. Since we assume that Funneling congestion is the result of short- lived phenomena, it is appropriate for gateways which are the sites of this congestion to attempt to smooth it without excessive control actions. This is the basis for the "hint" in the ICMP specification that maybe an SQ should be sent only when a datagram is dropped. It is the basis for the idea in RFC- 1016 that a gateway should be slow to cry "congestion" (SQK = 70% of queue space filed), even if persistent in attempting to eliminate it (SQLW = 50% of queue space filled). Since Funneling congestion is the result of the actions of multiple senders, the growth of internal queues is the only reasonable place to watch for its existence or measure its effects. Mismatch congestion, on the other hand, is the result of incorrect or inadequate information about available transmission bandwidth on the part of a single sender. The sending host has available to it information about destination host capacity (TCP window size and ACK rate) and about local link capacity (from the hardware/software interface to the directly-connected network), but no real information about the capacity of the Internet path. As noted in RFC-1016, hosts can obtain the best throughput if their datagrams are never dropped, and the probability of dropped datagrams is minimized when hosts send at the appropriate steady-state rate (no "bunching"). Therefore, it is a disservice to a host which is the source of Mismatch congestion to wait a "long" time before taking control action. It would be preferable to provide immediate feedback, via SQ's, to the host as soon as datagrams with too short an inter-arrival time begin to arrive. The sending host could then immediately (begin to) adjust its behavior for the indicated destination. There are, of course, many implementation issues which would need to be addressed in order to implement the type of SQ-sending behavior suggested here. Perhaps, though, they are not as severe as they might appear. Two specific issues and possible solutions, are: 1. How should a gateway differentiate between Funneling and mismatch congestion? Perhaps whenever there are more than q" items on an output queue to a slower subnet which have been received from a faster subnet, then look to see if any h" of them have the same source. It so assume Mismatch and send an SQ to that source. The "q" test might be implemented by a small set of counters which are incremented when a packet is placed on an output queue and decremented when a packet is sent. The search for a common source might require more cycles but be performed less often. The value of "q" would have to be small enough to give an early warning, but bigger than a small multiple of "h". The value of "h" would have to be big enough to avoid triggering McKenzie
