Jump to content

Flow control (data)

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Shellreef (talk | contribs) at 23:55, 12 October 2006 (disambig abr). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In computer networking, flow control is the process of managing the rate of data transmission between two nodes. This should be distinguished from congestion control, which is used for controlling the flow of data when congestion has actually occurred [1]. Flow control mechanisms can be classified by whether or not the receiving node sends feedback to the sending node.

Flow control is important because it is possible for a sending computer to transmit information at a faster rate than the destination computer can receive and process them. This can happen if the receiving computers have a heavy traffic load in comparison to the sending computer, or if the receiving computer has less processing power than the sending computer.

Transmit flow control

Transmit flow control may occur between data on and off terminal equipment (DTE) and a switching center, via data circuit-terminating equipment (DCE), or between two DTEs. The transmission rate may be controlled because of network or DTE requirements. Transmit flow control can occur independently in the two directions of data transfer, thus permitting the transfer rates in one direction to be different from the transfer rates in the other direction. Transmit flow control can be either stop-and-go or use a sliding window.

Flow control can be done either by control lines in a data communication interface (see serial port and RS 232), or by reserving in-band control characters to signal flow start and stop (such as the ASCII codes for XON/XOFF). Common RS 232 control lines are RTS (Request To Send)/CTS (Clear To Send) and DSR (Data Set Ready)/DTR (Data Terminal Ready), which is usually referred to as "hardware flow control". XON/XOFF is usually referred to as "software flow control".

Hardware flow control typically works by the DTE or master end first raising or asserting its line, such as RTS, which signals the opposite end (the slave end such as a DCE) to begin monitoring its data input line. When ready for data, the slave end will raise its complimentary line, CTS in this example, which signals the master to start sending data, and for the master to begin monitoring the slave's data output line. If either end needs to stop the data, it lowers its respective line. For PC-to-modem and similar links, DTR/DSR are raised for the entire modem session (say a dialup internet call), and RTS/CTS are raised for each block of data.

An earlier version of this section was based on Federal Standard 1037C.

Open-loop flow control

The open-loop flow control mechanism is characterized by having no feedback between the receiver and the transmitter. This simple means of control is widely used. The allocation of resources must be a “prior reservation” or “hop-to-hop” type. The Open Loop flow control has inherent problems with maximizing the utilization of the ATM network resources. Resource allocation is made at connection setup using a CAC (Connection Admission Control) and this allocation is made using information that is already “old news” during the lifetime of the connection. Often there is an over-allocation of resources. Open-Loop flow control is used by the CBR, VBR and UBR services (see traffic contract and congestion control) [2].

Closed-loop flow control

The Closed Loop flow control mechanism is characterized by the ability of the network to report pending network congestion back to the transmitter. This information is then used by the transmitter in various ways to adapt its activity to existing network conditions. Closed Loop flow control is used by ABR (see traffic contract and congestion control) [3]. Transmit Flow Control described above is a form of Closed-loop flow control.

See also

References

  1. ^ Network Testing Solutions, ATM Traffic Management White paper last accessed 15 March 2005.