 tommy13vPremium
join:2002-02-15
Niskayuna NY | No Clue The guy has no clue as to what he is talking about. |
|
Reviews:
 ·Comcast
1 edit | wait... So if I am getting this right... say I have a web browser that opens 10 connections to download 10 images at once... if I use this guys method say the first image is on a slow server... and it is downloading at 20kbit per second... the other 9 images will not use the rest of the available bandwidth on the connection? if so that is just plain stupid and would destroy server's ability to serve information in a fast manner!
The guy makes it sound like currently if we have 1 download at 6mbit and open 10 more now we have 66mbit connections from the simplistic view they took on it... you never get 11x more bandwidth.. you get what you where provisioned at... TCP/IP is not the problem! overselling lines is.. if you have a DOCSIS 3 node and 250 users on it only sell them what they can sustain all at once.... which is what? 1.5Mbit? dont go oh we are on DOCSIS3 now give 250 people 50Mbit connectiosn then whine "they're using up all our pipe" boo hoo... you caused the problem (isp)... |
|
|
|
 LinklistPremium
join:2002-03-03
Longport, NJ
kudos:5 | Well worth reading on why P2P causes problems Everyone who has an axe to grind in the P2P debate and why cable companies throttle P2P should read this commentary. It is 4 pages long and technical, but it explains how the current implementation of TCP has allowed P2P software to hog bandwidth to everyone's detriment.
It also explains that the problem can be fixed without banning P2P. But to do that requires the IEEE to modify TCP protocol standards and for ISPs to develop bandwidth limiting procedures for those users who won't upgrade to the new TCP stack client software.
--
My BLOG .. .. Internet News .. .. My Web Page |
|
approval from:
Cabal 
| reply to tommy13v
Re: No Clue You really know how to support your opinion! |
|
 CabalPremium
join:2007-01-21
Austin, TX | reply to Linklist
Re: Well worth reading on why P2P causes problems Seconded. Unfortunately, I think we're only likely to see armchair quarterback discussions on the matter.
--
Interested in open source engine management for your Subaru? |
|
 BF69Premium
join:2004-07-28
Camden, TN | reply to Hehe
Re: No Clue said by Hehe :
You really know how to support your opinion!
Just read more of his articles over at znet and then come back here. |
|
 knightmbEverybody Lies
join:2003-12-01
Franklin, TN | reply to Hehe
No, really he doesn't.
"TCP currently gives the user with 11 opened TCP streams 11 times more bandwidth than the user who only uses one TCP stream"
That statement right there is when I stopped reading his blog. If that was true, you could never download 11 files and play streaming music at the same time. |
|
knightmbEverybody Lies
join:2003-12-01
Franklin, TN
1 edit | reply to Linklist
Re: Well worth reading on why P2P causes problems said by Linklist:Everyone who has an axe to grind in the P2P debate and why cable companies throttle P2P should read this commentary. It is 4 pages long and technical, but it explains how the current implementation of TCP has allowed P2P software to hog bandwidth to everyone's detriment. It also explains that the problem can be fixed without banning P2P. But to do that requires the IEEE to modify TCP protocol standards and for ISPs to develop bandwidth limiting procedures for those users who won't upgrade to the new TCP stack client software. Maybe if they used what TCP/IP already has built in like, TOS, which is Type of Service, flags for lowdelay, throughput, reliability, mincost, congestion. The stuff that is already in there and adding another one like "even more uber ultra lower" is just more from the Redundancy Department of Redundancy.  |
|
 Matt3All noise, no signal.Premium
join:2003-07-20
Jamestown, NC
kudos:12 | said by knightmb:said by Linklist:Everyone who has an axe to grind in the P2P debate and why cable companies throttle P2P should read this commentary. It is 4 pages long and technical, but it explains how the current implementation of TCP has allowed P2P software to hog bandwidth to everyone's detriment. It also explains that the problem can be fixed without banning P2P. But to do that requires the IEEE to modify TCP protocol standards and for ISPs to develop bandwidth limiting procedures for those users who won't upgrade to the new TCP stack client software. Maybe if they used what TCP/IP already has built in like, TOS, which is Type of Service, flags for lowdelay, throughput, reliability, mincost, congestion. The stuff that is already in there and adding another one like "even more uber ultra lower" is just more from the Redundancy Depart of Redundancy. Agreed. QoS is also a viable option (it works on my $40 Buffalo router for christ sakes) but the big ISPs aren't interested in throttling P2P traffic, they want to either 1) kill it by making it unreliable ala Comcast or 2) implement byte caps to start hammering users with overages ala Time Warner. These are all being discussed by the companies most threatened by the advent of streaming video ... the cable companies.
There are solutions to P2P "flood" right now, but a lot of companies want it to fail because it's detrimental to their ancient and flawed business model. |
|
axus
join:2001-06-18
Washington, DC | reply to knightmb
Re: No Clue Well, in theory your limit is the connection you're buying... for a 5/1 connection, you aren't going to use more bandwidth than that.
But, the TCP stream issue still comes into play when you have two people who are maxing out their 5/1 connection. User #1 has 11 TCP streams, 500kbit/100kbit each. User #2 has 1 TCP stream, 5000kbit/1000kbit.
What happens when each drops a packet? User #1 has one stream drop to 250kb, the rest stay at 500. User #2 has his whole stream drop to 2500k/500k, while #1 is now at 4750k/950k. The algorithm will ratchet them back up, but packets are still going to be dropped.
Fixing the client side is stupid, because people can change their TCP stack to whatever they want. This guy should know better. It must be fixed on the ISP's side, the question is what is the fair way to drop packets, that causes the least work for the router. Cisco and Sandvine would love to sell more hardware, they don't care about efficiency, but the ISP should.
I think they should just drop a packet from a random open stream, regardless of the number of packets used by that stream. This way, the 11 stream guy has an 11/12 chance of one of his streams getting hit (for not much loss), and the 1 stream guy has a 1/12 chance of getting hit (but for a bigger loss). I believe the standard method is to pick a random packet, but random stream would be more fair when considering the TCP algorithm.
Also, the DHCP server could put heavy users on one router gateway (or group of routers), and light users on a different one. Define use as their last months bandwidth total. Treat the routers equal, and the light users will have plenty of space while the heavy users compete with each other. Neither suggestion inspects packets, or breaks applications, I think they are network neutral. |
|
| reply to neufuse
Re: wait... What you are saying is somewhat true, but not thinking in the right way. First off the situation that you are proposing would actually be helped by the proposed scheme. Think of it this way, P2P works by opening up 10s/100s of TCP connections. So lets say that you are sharing a pipe w/ a P2P user and the pipe is saturated (together you are wanting to use more that what is available). Lets say the pipe has a capacity of 100. Currently if you have 1 TCP connection open and someone else has 90, you get to use a total of 1.1% of the pipe. Now lets say you open 10 connections to download your pictures (something a browser typically won't do, unless things are changed they limit you to 2). Now you get to use 10% of the connection. Now lets move to the way that the article says it should work (without the special burst addition which would help you even more). For simplicity, again let the other user have 90 connections and you only have 1. When you go to download your your first picture you get to use 50% of the connection. In this scenario you can actually download all 10 of your pictures one after the other in less than 1/5 of the time.
Now the second part of the argument that the other user on P2P is not hurt by this. Why? Lets say they are downloading a large file (the reason most people go to P2P). Now your files are small in comparison and will easily finish under either circumstances before the other user's download. This means that you didn't actually reduces the total length of their download because under the old way you would have used a smaller amount of bandwidth but used it for longer, while the new way you use more for shorter, but the total size is same.
As for your commented about overselling the connections, I don't want to go too much into that issue, but this suggested protocol would help in those situations as well. Basically it will guarantee you an equal part of the bandwidth. Also, you are misinterpreting the problem. This has nothing to do with the speed caps that are given to you and multiplying them.
In reality the author is correct that the TCP protocol is broken in this aspect. You could argue that the protocol itself violates Net Neutrality. It depends on where you are trying to keep things equal. Should it be on the TCP connection level or at the subscriber level. Basically should we even it out between the # of connections that my neighbors and I make or the # of neighbors. Personally I vote fore the # of neighbors. |
|
tommy13vPremium
join:2002-02-15
Niskayuna NY | reply to Hehe
Re: No Clue And your response certainly showed yours as well. Get back to work.  |
|
 justbitsMore fiber than ATT can handlePremium
join:2003-01-08
Chicago, IL | reply to Matt3
Re: Well worth reading on why P2P causes problems QOS/TOS flags are not a solution. Anybody can set those flags. Anybody can ignore those flags. QOS/TOS is only useful between you and your first hop onto the Internet, not between you and anybody else. Otherwise, everybody who is greedy would mark all of their packets as highest priority.
The proposed change to TCP can result in fair-sharing of major Internet backbones as well as fair-sharing on your home Internet router. The big win with a fair-sharing TCP stack is that the major Internet backbones that carry GB/sec of traffic wont need to deploy excessive traffic shaping or deploy fake RST packets. And they can even detect the difference between a "greedy" TCP stack and a "fair-sharing" TCP stack so they can continue to throttle "greedy" consumers, but not excessively screw "fair-sharing" Internet users. The average case for the "fair-sharing" stack appears to result in no excessive detriment to P2P apps that would/could otherwise be more severely throttled by your ISP. And it seems to result in a huge increase in performance for lower-bandwidth single-connection users like VoIP and web surfing. However, an implementation of the protocol and testing needs to be done before this can really be proven.
The key here is that people who excessively use the Internet would be fairly throttled by a change to everyone's TCP stack to help ease congestion on Internet backbones. With fair-sharing TCP stacks, ISPs wouldn't need to excessively punish people using P2P protocols that are designed to take advantage of TCP's "congestion control".
If you want to think of it another way, P2P protocols are NOT designed to be a "green" or environmentally friendly protocol. They are designed to be greedy and take advantage of known flaws in the current TCP congestion algorithm. A fair-sharing change to TCP would result in helping all traffic move more smoothly, not just on your connection to your ISP, but across the entire Internet backbone between you and your end destination. |
|
| reply to Linklist
said by not said by user TK Junk Mail but he should have :
Everyone who has an axe to grind in the P2P debate and why cable companies throttle P2P should read this commentary. It is 4 pages long and technical, but it explains how the current implementation of TCP has allowed P2P software to hog bandwidth to Cable business model's detriment.
It also explains that the Cable cash flow problem can be fixed without banning P2P or competing video services delivered via broadband. But to do that requires the IEEE to modify TCP protocol standards and for Cable ISPs to develop bandwidth limiting procedures for those Cable users who won't upgrade to the new TCP stack client software or dare to venture outside the Cable walled garden.
There. That is much more accurate. |
|
| reply to Linklist
said by Linklist:Everyone who has an axe to grind in the P2P debate and why cable companies throttle P2P should read this commentary. It is 4 pages long and technical, but it explains how the current implementation of TCP has allowed P2P software to hog bandwidth to everyone's detriment. The article would be okay if (a) it didn't have technical issues and (b) didn't start with the assumption that TCP is broken. The problem is not TCP, but rather how the applications are coded and the last mile networks. P2P applications need more aggressive TCP session pruning and last mile networks need to implement basic, protocol-neutral QoS to ensure that everyone gets a fair slice of the network - using settings like minimum Committed Bit Rates, etc.
TCP was NEVER designed to be "fair" and does not need to be updated to make it "fair". ECN would help with performance to end users if the makers of crappy SOHO routers could code with a damn to respect ECN flags. But the fact is, TCP is designed to do ONE thing and to do that well - move packets. Once we start adding in additional "fairness" mechanisms into the protocol, you break the concept that makes IP, TCP and UDP work so well - Keep It Simple Stupid.
But it is hard to ignore issue like this-
Simply by opening up 10 to 100 TCP streams, P2P applications can grab 10 to 100 times more bandwidth than a traditional single-stream application under a congested Internet link.
There are so many issues with that statement.
For example, if a P2P user already has one TCP session open, sending out data at 128kbps over his connection with a 256kbps upload, he is only using 128kbps. Open a second connection and upload at 128kbps and his total usage is 256kbps, his limit. Open three or four more sessions, and all of the sessions slow down as the user has hit the maximum rate upload speed of his connection. Open 100 sessions, the user still only uses 256kbps of upload bandwidth.
And his assumption than single sessions always generate less traffic than multiple sessions is also flawed. He, apparently, is not familiar with IP video cameras, Slingbox, etc.
As well those multiple sessions are not immune from congestion as the author thinks. Just because the user has 100 sessions open, does NOT guarantee that he will get 256kbps all the time. How much data TCP sessions can transfer are a function of the lower levels, including the network layer and how saturated it is.
Then there is the apparent assumption that P2P TCP sessions are immune from the AIMD algorithm that the author complains about... Simply false.
Then there is this statement:
Despite the undeniable truth that Jacobson’s TCP congestion avoidance algorithm is fundamentally broken, many academics and now Net Neutrality activists along with their lawyers cling to it as if it were somehow holy and sacred.
The author is the ONLY person that has labeled AIMD as being "fundamentally broken" as "undeniable truth". The internet engineering community has not said this, only the author has said this. Sorry, just because one guy with a ZDnet (a publication known for shoddy technical articles in the past) blog said it, does not make it so.
Then there is the whole last page on weighted TCP... The problem is that without some sort of hardware in the network to manage flows, what is proposed will never happen. TCP can not do what is being shown on its own, even if patched. It would require the network to target SPECIFIC TCP flows for the "weighted TCP" model to work. And it, essentially, is no different than using WFQ or CBWFQ, where class X can use a class Y's bandwidth until class Y needs it.
Sorry, but I'll take the positions in this article more seriously when a better written article shows up someplace like the IETF (not the IEEE) or someone writes about it on NANOG. |
|
| reply to justbits
said by justbits:QOS/TOS flags are not a solution. Anybody can set those flags. Anybody can ignore those flags. QOS/TOS is only useful between you and your first hop onto the Internet, not between you and anybody else. Otherwise, everybody who is greedy would mark all of their packets as highest priority. The QoS issue only applies to the first mile anyway, where the problem is. There is not bandwidth problem at the internet backbone level.
As well, QoS can easily be implemented in a way that prevents the "flags" issue you have mentioned.
The proposed change to TCP can result in fair-sharing of major Internet backbones as well as fair-sharing on your home Internet router. The big win with a fair-sharing TCP stack is that the major Internet backbones that carry GB/sec of traffic wont need to deploy excessive traffic shaping or deploy fake RST packets. Major backbone providers have not even thought about using traffic shaping or forged RST packets. There is not a bandwidth problem on the internet backbones, nor will there be for awhile as there is still a lot of available bandwidth and many options to alleviate any problems (turning up new wavelengths, etc.) This is a problem in last mile networks only.
And it seems to result in a huge increase in performance for lower-bandwidth single-connection users like VoIP and web surfing. There are VERY few single-session TCP applications left. VoIP is not one of them. And web surfing is not one either (any longer).
If you want to think of it another way, P2P protocols are NOT designed to be a "green" or environmentally friendly protocol. Then the problem is the P2P algorithm, NOT TCP. Fix the P2P algorithms, fix them problem. Mangle TCP, problem remains. |
|
| Throttle them... You can try to fix them any way you want but they will find a work around one way or another. Throttling their connection on the ISP side is the only true way to stop bandwidth hogs.
Simply set a xGB tiers and then start throttling the connection back. As they go up further into additional tiers, throttle their connection further. Then reset it to normal and let the process start over.
Then they can market higher throttling points for power users that should pay more to use the additonal bandwidth they are requesting. |
|
 swhx7Premium
join:2006-07-23
Elbonia | reply to factchecker
Re: Well worth reading on why P2P causes problems I think you're basically right. Here are some views of Slashdotters who said it as well as I could:
Not all sessions experience the same congestion (Score:5, Interesting) by thehickcoder (620326) * on Monday March 24, @10:44AM (#22844896)
The author of this analysis seems to have missed the fact that each TCP session in a P2P application is communicating with a different network user and may not be experiencing the same congestion as other sessions. In most cases (those where the congestion is not on the first hop) It doesn't make sense to throttle all connections when one is effected by congestion.
Re:Not all sessions experience the same congestion (Score:4, Informative) by Mike McTernan (260224) on Monday March 24, @12:12PM (#22845810)
Right. The article seems to be written on the assumption that the bandwidth bottleneck is always in the first few hops, within the ISP. And in many cases for home users this is probably reasonably true; ISPs have been selling cheap packages with 'unlimited' and fast connections on the assumption that people would use a fraction of the possible bandwidth. More fool the ISPs that people found a use [plus.net] for all that bandwidth they were promised.
FUD (Score:5, Insightful) by Detritus (11846) on Monday March 24, @11:27AM (#22845298)
The whole article is disingenuous. What he is describing are not "loopholes" being cynically exploited by those evil, and soon to be illegal, P2P applications. They are the intended behavior of the protocol stack. Are P2P applications gaming the system by opening multiple streams between each pair of endpoints? No. While we could have a legitimate debate on what is fair behavior, he poisons the whole issue by using it as a vehicle for his anti-P2P agenda. |
|
 ureihcim3Freshly made
join:2007-12-16
Miami, FL | reply to Hehe
Re: No Clue Hey you, I know we don't just use government systems to surf on any site we wish. Great now we got employees from the Social Security Administration discussing TCP/IP. |
|
| reply to axus
Dropping packets only increases congestion. Every thing from the client to you has already spent cycles processing the packet. Now the packet has to be retransmitted. So what you end up accomplishing is increasing the load on downstream links in proportion to the percentage packets that you drop. This is the reason Comcast used the RST packets. Dropping packets would have only increased the load on their concentrators.
In addition it does nothing to address the fairness issue. The guy with one stream open waits on the dropped packet before reassembling the file while the guy with multiple streams continues to receive data in other streams.
There already exist many 'fair' protocols, Token Ring is fair, ATM is fair, these are two data-link layer protocols. DCCP is one more recently proposed transport layer protocol designed to be 'fair'. To understand why TCP persists you need to examine why some ( Token Ring ) fell by the wayside, and why others ( ATM ) are used as carriers for TCP.
This whole debate is amusing to me as it's very reminiscent of the ethernet vs. Token Ring debate of the 80's. Token Ring lost for several factors including cost, flexibility and performance. Although to be fair there are still many token ring installs out there. Mostly in applications where latency is critical. |
|
