Flow Control in ATM.

Unlike the reactive end to end flow control mechanisms of TCP in internetworking, the gigabits/sec capacity of ATM network generates a different set of requirements for flow control. If flow control was left on end to end feedback, then by the time the flow control message was received at the source, the source would have already transmitted over several Mbytes of data into the ATM pipe exacerbating the congestion. And by the time the source reacted to the flow control message, the congestion condition might have disappeared altogether unnecessarily quenching the source. The time constant of end to end feedback in ATM networks (actually feedback_delay * link_bandwidth product) may be so large that solely relying on the user attachments to keep up with the dynamic network is impractical. The congestion conditions in ATM networks are expected to be extremely dynamic requiring fast hardware mechanisms for relaxing the network to steady state, and necessitating the network itself to be actively involved in quickly achieving this steady state. Thus a simplistic approach of end to end closed loop reactive control to congestion conditions is not considered sufficient for ATM networks.

The present consensus among the researchers in this field is to use a holistic approach to flow control. They recommend employing a collection of flow control schemes along with proper resource allocation and dimensioning of the networks to altogether try and avoid congestion, to try and detect congestion build up early by closely monitoring the internal queues inside the ATM switches and reacting gradually as the queues reach different high watermarks, and to try and control the injection of the connection data into the network at the UNI such that its rate of injection is modulated and metered there first before having to go to the user attachement for a more drastic source quenching. The concept is to exercise flow control in hardware very quickly, gradually, and in anticipation rather than in desperation. Rate based schemes which inject a controlled amount of data at a specified rate that is agreed upon at connection setup time, and automatically modulate the rate based on the past history of the connection as well as the present congestion state of the network have seen much press lately. The network state may be communicated to the UNI by the network very quickly by generating a flow control cell whenever a cell is to be dropped on some node due to congestion (i.e. the queues are getting full). The UNI may then police the connection by changing its injection rate, or notify the user attachment for source quenching depending on the severity level of the congestion condition.

The major challenge during flow control is to try and only affect those connection streams which are responsible for causing the congestion, and not affect other streams which are well behaved. And at the same time, allow a connection stream to utilize as much bandwidth as it needs if there is no congestion.