[fulafel]

> Most TCP stacks will cut their send windows in half (or otherwise greatly reduce them) at the first sign of loss.

This was obsoleted by fast retransmit which was standardized in the 90s and ~everyone uses, right?

(loss generally is still used as a congestion signal, but first loss is usually not)

[drewg123]

No, fast retransmit basically does what it says -- retransmits things quicker. However, it is orthogonal to what the congestion control (CC) algorithm decides to do with the send window in the face of loss. Older CC like Reno halves the send window. Newer ones like CUBIC are more aggressive, and cut the window less (and grow it faster). However, RACK and BBR are still superior in the face of a lossy link.

[joveian]

Depending on the particular situation maybe vegas would work as well?

In particular, since Wireguard is UDP, using vegas over Wireguard seems to me like it should be good (based on a very limited understanding, though :/ ), it is just a question of how well it would work on the other side of the reverse proxy since I don't think it can be set per link?

[joveian]

Er, I was confused; of course being over UDP won't make the kind of difference I was thinking since the congestion control is just about when packets are sent. Although I heard a while back that UDP packets can be dropped more quickly during congestion. If that is the case and the congestion isn't too severe (but leading to dropped packets because it is over UDP) then possibly vegas would help.