I am analyzing the time it takes between a churn occurring in the network (e.x. that causes packet drops or delays) and when the congestion event handling codes are triggered in the TCP kernel in the UE, say if TCP is used.

My understanding is it can take either around the RTT to trigger the congestion handling if 3 duplicated acks are received and hence TCP enters the fast retransmit. Or it can take the timeout amount of time set up in TCP if no duplicated acks follow up. Could anyone double check?

  • 2
    Could anyone double check? You could always read the RFC.
    – Ron Trunk
    Nov 16, 2021 at 11:18
  • Removed the off-topic host-specific TCP implementation question.
    – Ron Maupin
    Nov 16, 2021 at 13:33
  • Please start with RFC 793, Transmission Control Protocol, which is the definition of TCP and all TCP implementations must support, before you tackle TCP variants that use things like three duplicate ACKs that are covered by other RFCs.
    – Ron Maupin
    Nov 16, 2021 at 13:38

1 Answer 1


basically you are correct. packet losses are discovered either by 3 (or more) duplicate ACKs or by a retransmission timeout. The former should happen in about one RTT, provided that there are enough packets that can still be delivered.


(1) congestion response differes in these two events. if retransmission timeout occurs, TCP starts from the beginning (there is no fast retransmit and similar)

(2) congestion losses are supposed to happen if "the bandwidth along the same path is exhausted", not if topology changes. If network churn results in a packet switching to a new path, it is actually highly desirable that congestion control resets (i.e., gets the same reaction as if retransmission timeout has fired). This is because the bandwidth of the new path is not known. I do not know if there is a standardized mechanism that can enforse this.

(3) if your UEs are mobile devices, that move, especially at high speeds (e.g., sitting in a train), there are additional mechanisms necessary.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.