You just reinvented delay based congestion control. This has been tried int many forms dating back to TCP Vegas. https://en.wikipedia.org/wiki/TCP_Vegas
Unfortunately, it often failed in practice (which no one ever wanted to publish), Some of the reasons are: * Delay based CC is sensitive to cross traffic congestion where the perceived congestion event was not caused by that flow. I.e other elephant stomps on ant. * Delay based CC is not aggressive enough to compete with loss-based CC. Vegas flows lose to Reno. * Delay based CC requires careful tuning, one variant was FAST TCP which was highly tuned for 1G networks in research. It went proprietary never heard how well it works in modern networks. * Delay based CC was sensitive to middleboxes, polling intervals and other timing effects in the wild. * RTT data has a noise to signal ratio, a flow has to be consistently maintaining a given rate in order to get consistent feedback. Google has some delay based congestion control that is promised to be released some time, I am waiting. _______________________________________________ Bloat mailing list [email protected] https://lists.bufferbloat.net/listinfo/bloat
