There is a deep misunderstanding of flow control in the industry amongst people; i liken it to subnetting, most people have a hard time understanding it because they dont have the time to sit down and study it.
Flow control is simple in its abstract view: Basically the person sending the packets wont send so many as to over flow the “buffers” of the reciever by sending too many packets / too quickly.
By enabling flow control, the receiving party has a way to control this by *explicitly* telling the sender how much buffer space they have available (Note: This is dynamic i.e. constantly changing so the receiver needs to be in constant communication sending updates). This is known as the “RcvWindow” field in the TCP segment. If you look in Wireshark you can see a “WIN” field which speaks to this:
578 22.020649 192.168.0.3 69.63.176.179 TCP 36272 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=877827 TSER=0 WS=6
“WIN” of 5480 means that my local client 192.168.0.3 is telling the BBC Server during my “SYN” packet (1st packet of three during the “Three way handshake” (Covered later)) that I can receive 5840 bytes at a time.
Now, the sender, when flow control is enabled, will keep the amount of transmitted, but un ACKnowledged (no ACK response from reciever to confirm receipt of packet) data less than the most recently received RcvWindow from the client. In TCP, there are 2 key fields for this topic; “RcvWindow” which is the amount of spare room in the buffer, and “RcvBuffer” which is the size of the receive buffer.
Now, Flow control is interesting in performance environments as sometimes users / architects can see negative results when enabling flow control. Key point here, is that flow control MUST be enabled END TO END. That means that from the NIC on the PC, to the switchport attached to the PC, to the switchport attached to the server (for example) to the NIC on the server in use. If end to end flow control is not in use then you will end up with bottle necks and high rates of retransmissions causing congestion on certain LAN segments.
Congestion is typically detected by lost packets (high retransmit / RETX rate), and large delays in the time stamps beetween packets (again, could cause send mechanisms to hit timer and RST and RETX the packets).
There is a really good powerpoint presentation available here:
http://www.cs.fsu.edu/~zzhang/CNT5505_Fall_2008_files/week12_2.ppt
This talks to the reasons of Congestion and has some great diagrams which talk to how it can occur and how flow control helps.
