Flow control in the generic sense refers to mechanisms that allow for the increase or decrease of traffic across a given data link by a transmitter based on some kind of signal (implicit or explicit) captured from the receiver.
Back in the days when serial communication was more common we used hardware flow control (RTS / CTS) to allow the endpoints on the serial link to signal when they were- or were not- capable of receiving data. A DCE (a modem, for example) might have buffers that could be overrun by the sending station. When this device passed a certain threshold of buffering, it would lower the appropriate signal line and the sending station would respond by pausing its data transfer until the DCE indicated that the immediate congestion issue had cleared. A similar mechanism was also implemented in-band (i.e. as part of the data being transmitted) known as XON/XOFF - same ideas as RTS/CTS but implemented as special control characters rather than dedicated hardware lines.
More recently (~15 years ago, or so) similar mechanisms were introduced in Ethernet in the IEEE 802.3x standard. This introduced a so-called "pause" frame. As in the serial case, a given receiver can emit such a frame when it is unable to accept more traffic. This is a MAC-layer mechanism (i.e. layer 2) which is has been implemented in a fair number of devices but whose actual usage and deployment has been quite limited. The issue with 802.3x is that when a PAUSE frame is issued then all traffic is held, regardless of the importance of said traffic. More recently there have been newer standards (collectively known as DCB) that allow for more fine-grained controls (i.e. pausing traffic on a per CoS basis) as well as complimentary facilities to define different classes of traffic and how they map to these CoS values. Other examples of extensions to L2 networking for active flow control include buffer credits in Fibre Channel and the feedback mechanisms found in ATM ABR.
True flow control isn't really applicable at layer 3, which is largely concerned with reachability and addressing. There are mechanisms at layer 4, however - notably TCP windowing - which allow senders to throttle back transmission based on network conditions. The operation and caveats of TCP windowing deserve their own question/post as there's a huge amount of literature on the subject. Another mechanism that has been specified but not extensively implemented/used for TCP is ECN (explicit congestion notification) which potentially allows a more proactive approach to throttling transmitter bandwidth (vs relying on packet drops for TCP windowing).
In addition to strict flow control there are also mechanisms to shape, selectively drop and police traffic on a per-sender basis (i.e. L2 / L3 and some L4 QoS mechanisms) but these aren't precisely flow control, at least in the usual definition of the term.