回答:
タイムアウト時に何が起こるかは、実際には図面からかなりはっきりしています...輻輳ウィンドウのサイズは元の値の1に戻り、スロースタートが再度実行されます。
TCPスタックが輻輳イベントを処理する方法の詳細は、使用しているバリアントによって異なります。この図は、TCP Renoアルゴリズムの例のように見えます。
3つの重複するACKを確認すると、TCP Renoは輻輳があると結論付けますが、一部のセグメントが確認応答されたため、ネットワークはまだ機能しています。タイムアウトの場合、状況はさらに悪化します。ネットワークは完全に応答しないようです。実際には、再送タイマーが切れる前に重複した確認応答が受信されるという事実は、一部が失われた（または再順序付けされた）可能性があるにもかかわらず、セグメントがまだ相手側で受信されていることを意味します。
したがって、3つの重複ackの場合、輻輳ウィンドウは半分にカットされ、その後線形的に増加します。これは高速復旧と呼ばれ、その目的は実際には再送信のタイムアウトを待たないようにすることです。
再送信のタイムアウトが発生すると、反応はより激しくなります。TCP Renoは、サイズ1の輻輳ウィンドウからのスロースタート、およびタイムアウトが発生したときの輻輳ウィンドウの値の半分のスロースタートしきい値で最初からやり直します。しきい値に達すると、増加は再び線形になります（加算的増加）。
TCP Tahoeには高速リカバリが含まれておらず、輻輳ウィンドウを初期値にリセットしてスロースタートを実行することで、どちらの場合も同じように反応します。TCP Renoの高速リカバリは基本的にスロースタートをスキップし、すぐに輻輳ウィンドウをしきい値に設定して線形増加を開始します。
さらに多くのバリアントが存在し、実際の実装はより複雑になる可能性があることに注意してください。また、他のTCPメカニズムが干渉する可能性があるため、これらのアルゴリズムを動作中に監視することは容易ではありません。
（両方の状況で高速リカバリを使用して）考えていたものが、既知の実装された輻輳回避アルゴリズムとして存在するかどうかはわかりません。リノが実装されたときにおそらくテストされ、破棄されました。この領域の科学論文を掘り下げてみてください。
