[Bloat] TCP congestion detection - random thoughts
Stephen Hemminger
stephen at networkplumber.org
Sun Jun 21 21:50:52 EDT 2015
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.
More information about the Bloat
mailing list