1

I want to do some simulations with different TCP algorithms I was reading one of the earliest papers for TCP CUBIC and I don't see explicitly the strategy of Fast Recovery after a loss of the packet. For example : TCP Reno after the loss (3 dup AKCs) set the ssthresh = cwnd/2 , retransmit the missing segment, and set cwnd to ssthresh += 3 MSS (Maximum Segment Size). Each time another duplicate ACK arrives, increments by one MSS the cwnd (inflate the window). Now when the next ACK arrives and acknowledges new data, set the cwnd = ssthresh (deflate the window) and continue with the congestion avoidance until the next loss or time out RFC 2001.

Now TCP NewReno extends the previous algorithm and introduces the partial and the full acknowledgements, recovering from multiple losses in the same window RFC 6582.

If TCP cubic uses any of the above algorithms we will see inflation and deflation of cwnd but this is not the case. Also, the reduction of cwnd in cubic will not be 1/2 but 0.8 * cwnd according to the TCP CUBIC. Below same diagrams from TCP Reno, New Reno, and Cubic

TCP Cubic paper

TCP New Reno/Reno pp.12

So what strategy does the TCP Cubic use for Fast Recovery?? In RFC 8312 for TCP Cubic, the strategy for Fast Recovery is not mentioned explicitly.

1 Answer 1

0

Loss recovery algorithm is not specified in Cubic, and any available loss recovery algorithm can be used with Cubic.

It can use NewReno. If both sender and receiver support selective acknowledgements (SACK), then SACK can be used. Another option is proportional rate reduction (see rfc6937).

Now, you actually see neither inflation nor deflation of congestion window during loss recovery on any of your plots. See this answer for an explanation.

P.S. an overview of some loss recovery strategies is in sec 3.3. and 4.4 of rfc7414

0

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.