how-to block ads
|
|
Share Topic
 |
 |
|
|
 funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | reply to patcat88
Re: Is this a good thing for the net? said by patcat88:said by a333:Yawn, here comes the typical argument... bandwidth is bandwidth, either way you look at it. All p2p does is open several simultaneous connections, splitting the user's bandwidth. Unless you horribly misconfigured your client to open up, say, 1000 ports. It's not as if the user is using any more bandwidth than if they were conducting a regular http download. Yes it is. Lets make an example. TCP equalizes the bandwidth equally for all TCP connections on the link at a single roadblock. User A and User B have 2 mbit connections to the DSLAM. The DSLAM has no one other than User A and User B. The DSLAM has a 3 mbit connection to the core router. User A is running P2P with 100 connections, User B is running an HTTP download with 10 connections. User A's speed will be 2 mbit (limited only by his DSL modem's 2 mbit speed), User B will be 1 mbit. Shouldn't it be 1.5 mbit for User A and 1.5 mbit for User B? Its not. If User A has a 3mbit connection to the DSLAM (DSLAM to internet is still 3 mbit), his speed would be 2.72 mbit ((3/110)*100), and User B will be left with .27 mbit ((3/110)*10). Nope, because as long as the 1 Mbps connection has upward headroom, it's going to take a creep at it and some of the resulting dropped packets at the 3 Mbps choke point will belong to the other user. This means that the equilibrium will continue to creep up until some balance was made. (This thought experiment is easier if you think in terms of 1 and 10 connections instead of 10 and 100, but the outcome is the same).
There is possibly a temporary unfairness, and that's because the 100-connection link will experience a less deep cut on a dropped packet than the 10-connection link will. But ulitimately routers are stateless, they only know data packets and balance will eventually be achieved such that A and B packets get dropped at about the same rate.
Besides, none of us have a 3 Mbps choke point. You need to apply that as well.
The relative tiny broadband modem pipe is a good unfairness equalizer. If it wasn't for that, then it actually might be more prone to work the way you describe.
Its the same reason download accelerators who make multiple connections to download an HTTP file work.
Nope. Download accelerators work because you're taking a larger share of the distant server's ports, each of which is allocated a share of the total bandwidth.
They would work the way you envision if we had 100 Mbps connections fighting for a smaller upstream pipe. But as it is we all have a small pipe competing in a larger one -- so it doesn't.
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| |
patcat88
join:2002-04-05
Jamaica, NY
kudos:1 | said by funchords:Nope, because as long as the 1 Mbps connection has upward headroom, it's going to take a creep at it and some of the resulting dropped packets at the 3 Mbps choke point will belong to the other user. This means that the equilibrium will continue to creep up until some balance was made. (This thought experiment is easier if you think in terms of 1 and 10 connections instead of 10 and 100, but the outcome is the same). 100 connections will all try at creeping up, just the same as the 10 connections will try creeping up, 100 connections will still have more bandwidth. Unless a TCPIP stack is designed to think of all connections as a whole when deciding whether increase speed (which i don't think is possible, since the stack has no way of telling if the congestion is on the local link, or out in the internet link after many routers).
There is possibly a temporary unfairness, and that's because the 100-connection link will experience a less deep cut on a dropped packet than the 10-connection link will. But ulitimately routers are stateless, they only know data packets and balance will eventually be achieved such that A and B packets get dropped at about the same rate.
Your talking about packets, I'm talking about connections. packets A and B can be part of the same connection.
Besides, none of us have a 3 Mbps choke point. You need to apply that as well.
Its an example, it makes less sense if I talk about User A through User ZZ and a 1 gigabit link from the CMTS to core router, and a 100 gigabit backplane, and a 40 gigabit link to a peering center, then a 1 gigabit link to some Tier 1, hand off to a Tier 2 in same datacenter, then taking a trip across the country on a leased MPLS OC768 shared with a handful of Tier 2 ISPs and find that at 6PM most days of the week there is congestion on that, or we can go further and say, then it arrives another coast of the USA, goes into a Tier 1's datacenter, where its split into its Tier 2's bonded 1 gigabit circuits where it flys off to a colo datacenter through the Tier 2's router then in that datacenter it goes to another floor and then down a congested 100mbit link to a new hot Web 2.0 video sharing site which offers videos in torrent with 30 1U servers inside each torrent, or a HTTP download from 1 server, where exactly all Users A through ZZ are trying to connect. Lets hope no line cards are out of spec and not causing congestion.
Nope. Download accelerators work because you're taking a larger share of the distant server's ports, each of which is allocated a share of the total bandwidth.
Thats true too. Same drowning out effect as in TCP connections. Except now for Apache threads.
They would work the way you envision if we had 100 Mbps connections fighting for a smaller upstream pipe. But as it is we all have a small pipe competing in a larger one -- so it doesn't.
But our small pipes summed up, are much larger than the "large" pipe we are trying to get into (consumer ISP contention).
P2P is like an ISP with 75% of its customer being botnet infect and DDOSing youtube off the net by drowning out legitimate connections. Except replace youtube with a peering link. | |
funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | 100 will try at creeping up, and more connections will experience packet drop -- (more connections, but not a bigger proportion) -- but either way, routers don't understand connections -- they just deal with packets and when congestion hits, they drop in proportion.
If B is transmitting more data than A, then B will have more drops. We have to mentally turn the situation back into connections in order to predict what happens next.
As to your last sentence:
Client-server is not more legitimate than P2P (The Internet started as P2P), and well-moneyed companies don't deserve the only voice on the 'net.
You might like a receive-only network -- but we've had that before, we called it "Television."
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
More features, more fun, Join BroadbandReports.com, it's free...
| | |
|
 espaethDigital PlumberPremium,MVM
join:2001-04-21
Minneapolis, MN
kudos:2
 ·Clear Wireless
| reply to funchords
said by funchords:There is possibly a temporary unfairness, and that's because the 100-connection link will experience a less deep cut on a dropped packet than the 10-connection link will. But ulitimately routers are stateless, they only know data packets and balance will eventually be achieved such that A and B packets get dropped at about the same rate. Even if A & B have packets dropped at the same rate, connection A has 100 instances of congestion avoidance compared to connection B having 10 instances.
The likelihood of a packet in a TCP flow of B being dropped is 10x greater than the likelihood of a packet in a TCP flow of A being dropped. 1:10 vs 1:100
If packets were uniformly dropped across flows then it might balance in the way you suggest. The problem is that congestion / drops happens without regard to specific flows, so the impact across TCP flows is not even. | |
|
