Re: [Bloat] TCP congestion detection - random thoughts

[Stephen Hemminger <stephen@networkplumber.org>]

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.