● Objective: The primary goal of flow control in TCP is to prevent a fast sender from overwhelming a slow receiver. It ensures that the sending application does not transmit data at a rate faster than the receiving application can process the data and clear space in its receive buffer.

● Scope: Flow control is an end-to-end mechanism, operating directly between the TCP modules of the two communicating hosts (sender's TCP and receiver's TCP). It focuses on managing the resources (specifically, the buffer space) at the receiving end system.

TCP implements flow control using the sliding window protocol concept, specifically by leveraging the Window Size field in the TCP header.

● Receiver's Role in Flow Control:
- The TCP receiver maintains a receive buffer (a finite amount of memory) to store incoming data segments that have arrived correctly and are awaiting processing by the application layer.
- The receiver continuously monitors the amount of free buffer space available in its receive buffer.
- It communicates this available buffer space to the sender by advertising its Receive Window (Rwnd). The Window Size field (16 bits) in the TCP header of every acknowledgment (ACK) segment sent by the receiver contains the current size of this Rwnd. This Rwnd indicates the maximum number of bytes that the receiver is currently willing to accept, starting from the byte acknowledged in the Acknowledgment Number field.

● Sender's Role in Flow Control:
- The sender maintains a Send Window. The effective size of the sender's send window is limited by the minimum of its own congestion window (cwnd) (determined by congestion control) and the receiver's advertised Rwnd.
- The sender will not transmit data whose sequence number falls outside the current allowed window (i.e., it will not send more data than Rwnd allows, starting from the last acknowledged byte). This ensures that data is sent only if the receiver has sufficient buffer space to accommodate it.

● Dynamic Adjustment:
- As the receiving application reads data from its receive buffer, free space becomes available. The receiver then advertises a larger Rwnd in subsequent ACKs, allowing the sender to transmit more data.

● Zero Window:
- If the receiver's application is slow or temporarily pauses, its receive buffer might fill up completely. In this case, the receiver will advertise a Window Size of zero. This effectively tells the sender to stop transmitting new data until buffer space becomes available.
- To prevent a deadlock if a zero-window advertisement is lost (where the sender would wait indefinitely), TCP senders implement a zero-window probe mechanism. Even with a zero window, the sender will periodically send a single small segment (a "window probe") to the receiver. This probe encourages the receiver to re-advertise its current Rwnd, allowing the flow to resume if space has become available.

● Objective: The primary goal of congestion control is to prevent the entire network from becoming overwhelmed by too much traffic. It aims to prevent network congestion collapse (a severe degradation where throughput drops dramatically due to excessive retransmissions and router queue overflows), to share network bandwidth fairly among competing TCP flows, and to ensure efficient operation of the network infrastructure.

● Scope: Congestion control is a network-centric mechanism. While implemented at the Transport Layer of end systems, its impact is global, affecting the rate at which all flows sharing common network paths inject data into the shared network resources (routers, links). It attempts to infer the network's carrying capacity and adapt the sending rate accordingly.

TCP congestion control is a complex, adaptive, and self-regulating set of algorithms. It primarily infers the state of network congestion from two main signals:
1. Packet Loss: Detected through retransmission timeouts or through the reception of multiple duplicate acknowledgments.
2. Increased Round-Trip Time (RTT): While traditional TCP primarily uses loss, some modern variants explicitly use RTT variations to infer impending congestion.

TCP employs several interacting phases/algorithms to manage congestion: Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery. The actual data transmitted by the sender is limited by the minimum of its Advertised Window (from flow control) and its Congestion Window (cwnd). Min(cwnd, Rwnd).

1. Slow Start (SS):
2. Purpose: To quickly determine the initial available bandwidth at the beginning of a TCP connection or after a retransmission timeout. TCP starts conservatively and then rapidly probes the network to discover capacity.
3. Mechanism: When a TCP connection begins, the congestion window (cwnd) is initialized to a small value, typically 1 MSS (Maximum Segment Size) or 2-4 MSS. For every ACK received that acknowledges new data, the cwnd is increased by 1 MSS, leading to an exponential growth of cwnd. Slow Start continues until cwnd reaches a predefined threshold called the slow start threshold (ssthresh).
4. Congestion Avoidance (CA):
5. Purpose: To operate the TCP connection in a stable manner and to probe for additional available bandwidth more cautiously once the initial exponential growth phase (Slow Start) has completed. In this phase, TCP assumes it is operating close to the network's capacity. Mechanism: When cwnd is greater than or equal to ssthresh, TCP increases cwnd by 1 MSS per RTT for every RTT or based on ACKs.
6. Reaction to Packet Loss and Congestion (Loss-Based Congestion Control):
7. TCP primarily detects network congestion through packet loss. If a retransmission timeout occurs, it suggests severe congestion, leading to resetting cwnd to 1 MSS and re-entering Slow Start. If three duplicate ACKs occur, it indicates an isolated loss, triggering Fast Retransmit and Fast Recovery processes instead.

TCP variants like Tahoe and Reno primarily rely on loss-based congestion control algorithms. Loss-Based Congestion Control assumes that packet loss is the primary signal of network congestion. While these algorithms are simple to implement and effective, they are reactive, which can lead to issues like underutilization of network capacity. Delay-Based Congestion Control, on the other hand, attempts to detect congestion before it results in packet loss by monitoring changes in Round-Trip Time (RTT). Examples include TCP Vegas and TCP BBR, which aim to optimize network efficiency by proactively adjusting to real-time conditions.