[Bug]: Reno/CUBIC ssthresh在min_cwnd clamp之后设置而非之前

[qisefengzheng]

What happened?

RFC 9002: Appendix B.6 OnCongestionEvent

RFC伪代码先设置ssthresh再应用min_cwnd clamp:
ssthresh = congestion_window * kLossReductionFactor // 先设ssthresh
congestion_window = max(ssthresh, kMinimumWindow) // 再clamp cwnd
xquic Reno先clamp cwnd再设置ssthresh:
xqc_reno_on_lost
reno->reno_congestion_window = XQC_kLossReductionFactor; // cwnd = 0.5
reno->reno_congestion_window = xqc_max(reno->reno_congestion_window, XQC_kMinimumWindow); // clamp
reno->reno_ssthresh = reno->reno_congestion_window; // ssthresh = clamped cwnd
CUBIC同样:
cubic->cwnd = cubic->cwnd * 718 / 1024;
cubic->cwnd = xqc_max(cubic->cwnd, cubic->min_cwnd); // clamp
cubic->ssthresh = cubic->cwnd; // ssthresh = clamped cwnd
影响: 当cwnd很小时，ssthresh被设为kMinimumWindow而非实际缩减值。例如:
cwnd = 3MSS, Reno: RFC ssthresh=1.5MSS, xquic ssthresh=2*MSS
这导致发送方在慢启动中停留更久，因为ssthresh更大

xquic位置:
Reno: xqc_reno_on_lost() (xqc_new_reno.c:61-63)
CUBIC: xqc_cubic_on_lost() (xqc_cubic.c:174-177)

ngtcp2参考: ngtcp2的CC算法实现在ngtcp2_cc.c中

Steps To Reproduce

Information and Steps to reproduce the behavior.

Relevant log output