Canadian TV, Computing and Home Theatre Forums banner

1 - 5 of 5 Posts

·
Registered
Joined
·
2,579 Posts
Discussion Starter #1
Article on TCP exploitation: The real reason for bandwidth congestion and throttling

I guess this could have gone in one of several existing threads, but since it doesn't deal with a specific ISP, and barely discusses net neutrality (ironically, not neutrally ;)), I have posted it as a new thread.

This is a must read:
Fixing the unfairness of TCP congestion control

As a non-IT professional, I found this to be a well written explanation of why internet congestion occurs. I know that I have played with (as in patched) my TCP settings on my PC in the past to increase my # of connections, but I didn't really understand why it worked.

I'm not sure I agree with his proposed solution that Weighted TCP could deliver the best of both worlds:
This is essentially a win for everyone since the typical web surfer or email user will get blazing responsiveness while the P2P application finishes their transfers in the same amount of time.
I would be interested in hearing the opinions of network specialists as to whether this is a valid article, or merely tripe.

And can anyone tell me does this solution completely avoid dropped packets? As long as packets are getting dropped, which happens when demand out paces resources, those packets will have to be re-sent.
 

·
Registered
Joined
·
5,463 Posts
TCP congestion control and how it interacts with other levels of network flow control is a favourite topic of academic research.

There are actually quite a few variants of TCP out there. Each one changes certain parameters (window size, etc) to try and get better performance for the particular application that is being run.

Long story short, opening up lots of TCP sessions MAY help you get more bandwidth, or it may not. There are lot of variables that can affect this.

The proposed solution, while called "weighted TCP" is really user level QoS restrictions in disguise and no ISP is ever going to roll that out. It's a nightmare to enforce and the users would revolt. That leaves it up to the application to decide, and guess what they will do? Something equivalent to opening up multiple TCP sessions.

The article also goes on to discuss using ECN as a solution. Well ECN, and every other end to end, or even hop by hop, congestion avoidance mechanism have largely not been implemented because interoperability is a PITA and doing things to TCP can cause very strange behaviour in both the network and the applications.
 

·
Banned
Joined
·
6,296 Posts
TCP protocols are not perfect and there will be people who take advantage of the loopholes. OTOH, it's the best we have and unilateral tinkering by networking providers should not be allowed. Flaws need to be addressed by the standards process to improve the protocol for everyone, not just the interests of a few corporations.
 

·
Registered
Joined
·
5,463 Posts
I don't disagree.

I just find issue with the simplistic view that a "simple" fix to TCP will all of a sudden make things better.

Several years ago the "answer" to network congestion and higher efficiency was end to end congestion control at the user/application/host level. Many, many $$$ were spent researching the problem, building products with fancy features, standardizing in the ATM-forum, IETF, etc. None of them were ever deployed.

It's a very hard problem to solve and the very nature of the Internet, many thousands of routers and switches and PCs all working together make it nearly impossible for any end to end network solution to work.

Application to application protocols, which is essentially what TCP is, work because they make no assumptions (generalizing) about how the network behaves.
 

·
Banned
Joined
·
6,296 Posts
One solution is for user applications to tag internet traffic as high, normal or low priority. That would work, except for the fact that game theory (which is very predictive in regards to human behaviour) precludessuch practices on modern day networks.

The answer lies in packet shaping. However, Bell's solution is unacceptably anticompetitive, punitive and simplistic in implementation. Bell's network restrictions should be stopped immediately and delayed until an acceptable policy on packet shaping can be adopted and implemented.
 
1 - 5 of 5 Posts
Top