kumar@hpindwa.HP.COM (Krishna Kumar) (03/21/89)
Hello, With more and more implementations adopting Van Jacobson's source-based congestion avoidance and control mechanisms, is it likely that in the near future gateways will stop sending ICMP source quench messages when they discard packets? There seem to be conflicting documentation on sending ICMP source quench messages in the first place. RFC 792 [Postel: Internet Control Message Protocol, Sep '81] states: "If a gateway discards a datagram, it *may* send a source quench message to the internet source host of the datagram." RFC 896 [Nagle: Congestion Control in TCP/IP Internetworks, Jan '84] states: "The present ICMP standard specifies that an ICMP Source Quench message *should* be sent whenever a packet is dropped, and additionally may be sent when a gateway finds itself becoming short of resources. There is some ambiguity here but clearly it is a violation of the standard to drop a packet without sending an ICMP message." RFC 1016 [Prue and Postel: The Source Quench Introduced Delay (SQUID), July '87] states: If a gateway discards a datagram, it *may* send a source quench message to the Internet source host of the datagram." (referring to RFC 792). It goes on to suggest, "We propose gateway IP nodes start SQing before the node is flooded at a level we call SQ Keep but forward the datagram.... Once the gateway starts sending SQs it *should* continue to do so until the queue level goes below a low water mark level..." Can anyone shed some light on these issues? Any comments or suggestions? Thanks, Krishna Kumar, Business Networks Division, HP. (kumar@hpindwa.HP.COM) ------------ (Disclaimer: All opinions are my own and not my employer's.)
smb@ulysses.homer.nj.att.com (Steven M. Bellovin) (03/22/89)
RFC 1009 requires that source quench be sent; this statement should be taken as authoritative: 2.2.3. Source Quench All gateways must contain code for sending ICMP Source Quench messages when they are forced to drop IP datagrams due to congestion. Although the Source Quench mechanism is known to be an imperfect means for Internet congestion control, and research towards more effective means is in progress, Source Quench is considered to be too valuable to omit from production gateways. There is some argument that the Source Quench should be sent before the gateway is forced to drop datagrams [62]. For example, a parameter X could be established and set to have Source Quench sent when only X buffers remain. Or, a parameter Y could be established and set to have Source Quench sent when only Y per cent of the buffers remain. Two problems for a gateway sending Source Quench are: (1) the consumption of bandwidth on the reverse path, and (2) the use of gateway CPU time. To ameliorate these problems, a gateway must be prepared to limit the frequency with which it sends Source Quench messages. This may be on the basis of a count (e.g., only send a Source Quench for every N dropped datagrams overall or per given source host), or on the basis of a time (e.g., send a Source Quench to a given source host or overall at most once per T millseconds). The parameters (e.g., N or T) must be settable as part of the configuration of the gateway; furthermore, there should be some configuration setting which disables sending Source Quenches. These configuration parameters, including disabling, should ideally be specifiable separately for each network interface. Note that a gateway itself may receive a Source Quench as the result of sending a datagram targeted to another gateway. Such datagrams might be an EGP update, for example.