said by espaeth:
Now say you had 17 users, but one of the users had 2 TCP sessions. 9mbps channel capacity / 18 TCP sessions = 500kbps per TCP connection. That means 16 people will see 500kbps, and the 1 user using 2 TCP sessions will see 1mbps.
Here's the problem I see with this discussion... The emphasis is being place on TCP when the problem is within the network. TCP, in your situation is functioning EXACTLY as it is suppose to - move data for each session as quickly as possible, scaling back each session only when network conditions dictate that full speed ahead won't work.
TCP is not what is broken. And anyone who frames the discussion in terms of TCP being broken is missing the more fundamental problem.
The _network_ allows a single users to get more than their "fair share" of the network. In your example, one user is able to get more bandwidth because the network allows it. It is one of the problem with contention based (or shared) networks - one station can monopolize the network if nothing prevents it from doing so.
Instead of rewriting TCP, a much easier step can be taken.
Enable QoS in a manner than enables the bandwidth to be equally shared among uploading systems when congestion exists, otherwise allow system to send as fast as their connection permits.
See the following on fair queuing:
»en.wikipedia.org/wiki/Fa ··· _queuing
Routers, DSLAMS and CMTSs all have the capabilities to enable this type of behavior. ISPs just need to leverage it. This solution is MUCH easier than writing, testing and deploying patches to TCP on a myriad of platforms.