Final answer:
A sender detects congestion end-to-end by observing packet losses and delays, through network-assisted feedback like ECN, or by monitoring increases in delivery delays in delay-based congestion control.
Step-by-step explanation:
To understand how a sender detects congestion in various control approaches, it's pivotal to examine each method separately:
End-to-End Congestion Control
In end-to-end congestion control, there are no explicit feedback signals from the network; the sender infers congestion indirectly through observations such as increases in packet loss rates or growth in round-trip times of packets. The Transmission Control Protocol (TCP) uses end-to-end congestion control with mechanisms like slow start, congestion avoidance, fast retransmit, and fast recovery. Packet loss, detected by timeouts or duplicate acknowledgements, is typically interpreted as a signal of congestion.
Network-Assisted Congestion Control
Network-assisted congestion control involves the network providing explicit feedback to senders about the state of congestion. This can be achieved through protocols like the Resource Reservation Protocol (RSVP) or by incorporating Explicit Congestion Notification (ECN) in the IP header, which routers use to mark packets when encountering congestion, signaling the sender to reduce its transmission rate.
Delay-Based Congestion Control
With delay-based congestion control approaches, the sender observes the delay of packet deliveries. If the delay increases beyond a certain threshold, it's an indication that the network is likely experiencing congestion, prompting the sender to decrease its transmission rate before packet loss occurs.