> Not at all. TCP already does its own rate limiting without external throttling.

Individually, cars brake on the freeway to avoid hitting the car in front of them.

Collectively on a busy freeway, that sets off a chain reaction that results in the familiar rush hour crawl.

Minnesota did a study in 2001 on the effect of ramp meters, and disabling the meters (ie, removing throttling) resulted in statistically significant increase in overall freeway travel times.[0]

Statistically multiplexed shared networks like mobile wireless face similar issues. For a single TCP session the only metrics that can be divined by the endpoints are round-trip time and loss. As the shared network reaches capacity, larger numbers of TCP connections all back off around the same time, but large flows are more aggressive at ramping up than smaller flow (email/instant messaging, etc) and can result in an effective breakdown of network usability. A network control that has visibility to multiple flows and awareness of capacity of the system can influence overall performance much more effectively.

Ideally mobile providers would be trying to shoot for maintaining uniform latency per flow, similar to what queuing strategies like CoDel[1] achieve, but that's likely beyond the CPU and buffering capabilities of their existing hardware. Lacking the perfect solution, it's human nature to move on to the next approach: managing the biggest problem. Video is usually easy to identify, and so it wins the "able to be managed" prize.

[0]http://www.dot.state.mn.us/rampmeter/study.html [1]https://en.wikipedia.org/wiki/CoDel

tcp doesn't work well for wireless because packet drops due to signal interference look like collisions

This is somewhat true, but there's a lot of work done in the data link layer to provide a robust connection. TCP falls over with packet loss of less that 1%[1], so it's not really good at that, anyway.

https://www.netcraftsmen.com/wp-content/uploads/2014/12/2012...