TCP MIN_ A dialectical study of RTO

TCP In the process of continuous evolution, there are many things that are self defeating , All of these things are “ I guess it is. X, But I'm not sure ” Lead to .

There is no need to say more about packet loss judgment in congestion control , Nagle Algorithm and Delayed ACK I have said that . Talk to colleagues RTO What happened , This is another example .

Linux TCP In the implementation MIN_RTO Why? 200ms So big , about IDC Internal communication is obviously very unreasonable ,100us Class RTT It is obvious that there is no need for 1000 Times the time to determine the timeout .

It's not difficult to solve this problem , Extract a configuration parameter , Give Way MIN_RTO Just match it . This is also the most natural idea , I believe many private implementations do this . But the question is why the famous LInux The configuration was not exported ？

In order to cater to Delayed ACK, It is also the standard ,Delayed ACK There is a delay upper bound , For example 200ms ( The exact number is not important ),RTO This must be considered Delay, Otherwise, it may be pseudo timeout .

therefore MIN_RTO configure Delayed ACK Delay Magnitude , such as 200ms .

It looks like it's going well . But things got complicated ：

• The opposite end can Delay To Delayed ACK Is the upper bound of ？ If only Delay 了 10ms Well ？
• Delayed ACK Of Delay Is time a constant value or an adaptive value ？
• The end of a set of data , Not enough ACK When a fast retransmission is triggered , Need to be compared with RTO Small TLP.
• If not for Delayed ACK Lead to RTO Too big ,TLP There is little need to introduce .

…

then Google Came up with a plan ：draft-wang-tcpm-low-latency-opt-00

In fact, all this is not necessary , In a circle .

In order to reduce ACK Number , extraction Delayed ACK, To cater to Delayed ACK Upper bound of delay ,MIN_RTO It's obviously too big , For more efficient detection of tail drop , extraction TLP, To adapt IDC RTT But also abide by Delayed ACK upper bound ,Google extraction TCP Low Latency Option.

The root cause is Delayed ACK, Then solve it .

Read the following article ：
TCP Delayed ACK Dialectical examination

How to solve MIN_RTO The problem? ？

MIN_RTO No longer need , No need to pander to Delayed ACK,RTO Completely based on RTT Calculation .TLP And there's no need for , Just in PSH Package settings “ It must be done immediately ACK” sign . With the above guarantee , There is no need to worry about pseudo timeouts ：

• Spaced “ immediately ACK” Flags always trigger a fast retransmission before the timeout .
• If it does time out , That's almost a real packet loss .

Special , In case of unidirectional transmission , Knowing that the opposite side is unwilling to carry ACK Under the circumstances , Why not just tell the opposite end , Instead of having to adapt . in fact Linux TCP A... Is maintained for the connection pingpong Variable , It's adaptive TCP timeout . The reality is even more complicated .

You can set it for every package “ immediately ACK” sign , Or ease up a little , Every time 2 individual ,3 individual … Set once “ immediately ACK”. Even the first few packages and the last one PSH Set on the package “ immediately ACK”. It depends on the congestion control algorithm .

Is it very refreshing ？

Just promise RTT There is one in the order of magnitude “ immediately ACK“ Data packets can be sent at RTT Plan within a certain amount of time RTO, There is no need to set MIN_RTO, Make your own decisions , Instead of guessing the other person's behavior . Don't guess the behavior of the link .
TCP Poor performance , Include QUIC There is also an upper limit to performance , The basic reason is that the link behavior basically depends on guessing , This is the end-to-end principle that leads to , As long as you agree with end-to-end self-determination , This problem cannot be solved , You can't get the link behavior information , It can only be predicted , inspire , In the final analysis, it's all guessing .
This is me. “ Suggest ” very good , But the opposite end does not necessarily support , So we have to negotiate ？
The negotiation is always larger than the previous export “ Mechanism ” It is better to . So , If it can be standardized, it can be standardized , Negotiation without standardization , But don't guess .

Who cares? 7 Are 100 million Chinese men tired of walking ？ Aokang cares .
Zhejiang Wenzhou leather shoes wet , It's not fat when it's raining .