patcat88
join:2002-04-05
Jamaica, NY
| reply to a333
Re: Is this a good thing for the net?
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). Its the same reason download accelerators who make multiple connections to download an HTTP file work.
The speed caps (2 mbit in this case) don't extend past the DSLAM/CMTS. After that its a single ethernet link, and packets and upstream routers do not see the original speed caps, or see IPs and current traffic behind each IP when deciding which traffic to toss at a congested point. The router will randomly drop traffic. The chance of a single TCP connection's packet being post is the same among all TCP packets at that congestion/dropping point. A droped packet means TCP will slow down the connection. So the more connections a user has (assuming the connection's destination's connection has infinite bandwidth), the less likely a packet will drop on the sum/pool of all of that user's connections.
Your acting as if every router has QOS support, and can see your current utilization and all other user's utilization, and decide to split bandwidth equally among all users (not all connections). A router doesn't see users and DSL modems and Cable modems, it sees a bunch of TCP connections with different source IPs. Only if the router sees each modem as a VPN tunnel (which is a single point to point connection) will your idea work.
P2P actually is better for a network, as (given enough peers) it completes downloads significantly faster than normal centralized server methods, thus getting heavy users off the network noticeably faster (obviously, unless the user is dumb enough to allocate their entire upstream bandwidth to seeding).
I'll be driving down to the Yacht club in my Maybach to be the host of my Yacht Party, laughing all the way by throwing datacenter/server/internet connection costs to the users to swallow.
There is so much content on the internet, only a couple people on your headend/DSLAM/Central Office/City will have that content. No current P2P system and no realistic future P2P system actively attempts to talk to local (same ASN/ISP/city/least hops) peers vs distent peers. P4P is dead since no open source coders have any incentive to help "the man" (ISPs). When Vuze and uTorrent come with ASN preference, thats when your not BSing.
Users do allocate almost all their upstream to seeding, otherwise you get banned from your private tracker and seed for 24/7. Nobody pumps HTTP traffic 24/7.
Do I even support the above solution? By itself, absolutely NOT!! IMHO, the ideal solution is to upgrade the core and its routers. However, that takes time and capital
If IP6 is DOA, so is any upgrades to TCP/IP. I'm still waiting for Xcast (Explicit Multicast), or some system to let me receive or send multicast traffic in P2P. P2P traffic would decrease exponentially if consumers had access to Multicast. My 1 upstream stream of sectors of the file can duplicate to 100s of peers with only 1 copy of the traffic on each ISP, and it can go across long haul backbone fiber optics as 1 copy. Only problem is if your download is too slow for my upstream stream, you will have to get "makeup" packets via conventional P2P P2P from peers who did get my packets. Sectors with the most users needing them/rarest get sent out first. So a torrent can be seeded to 1000 users in the time it takes for the initial seed to seed it exactly once. |
|
patcat88
join:2002-04-05
Jamaica, NY
| reply to a333
said by a333 :P2P software REDUCES congestion, and avoids the situations most HTTP downloads would just keep trying to hammer their way through. To distribute Blizzard patches to several million users simultaneously using the regular HTTP/unicast methods would require a port into the 'net that's the size of a national backbone. Pay Limelight or Akamai like a proper company »www.akamai.com/html/customers/cu···ist.html .
Intelligent localized caching and distribution and redirection of clients to the closest server. Datacenters all over the world. Almost no transoceanic link usage by clients connecting to a CDN. |
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
 ·Verizon Online DSL
 ·Skype
| reply to patcat88
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
| 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. |
|
funchords
Hello
Premium,MVM
join:2001-03-11
Washington, DC
·Verizon Online DSL
·Skype
| 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...
|
|
edam
@btopenworld.com
| reply to a333
said by a333 :P2P software REDUCES congestion, and avoids the situations most HTTP downloads would just keep trying to hammer their way through. Haha ha!! You've obviously never managed a network, mate... |
|
TC
@anheuser-busch.com
| reply to devnuller
so... isn't this ultimately about service providers overselling their capacity? i mean, so what if i use all of the bandwidth i pay for? is it my fault that my ISP can't handle what they sold me?
just playing devil's advocate here, but i'm failing to see how all internet users should pay the price of ISPs trying to cut corners and milk as much money as possible out of their service. this is their burden to "fix", and by "fix" i mean actually provide the service they have sold to millions of users at a certain price point. if they cannot do that and intend on limiting/restricting their advertised/sold service, then there will be lawsuits (in america at least, given our propensity for litigiousness) against them or at minimum they will be forced to lower their prices.
all the arguments about how much saturation a given protocol causes, connection "fairness", etc., are moot. this is an issue created by greedy companies and overzealous marketing. |
|
iDNbitT247
@embarqhsd.net | reply to devnuller
is this internet scrare tatics. FACT:this fight will never end its a matter of history so biz models are going to change or die |
|
swhx7
Premium
join:2006-07-23
Elbonia
 ·RoadRunner Cable
| reply to espaeth
said by espaeth : It is several orders of magnitude more expensive to deliver bandwidth to residential homes than it is to provide bandwidth for servers in data centers. That's why shifting the distribution burden from data center hosted servers to end-user links is such a poor idea. The P2P architecture is one that you arrive at when you develop an application with complete ignorance to the realities of the network infrastructure it will run on. ... Considering that technical hurdles make upstream capacity the most difficult to build out at the edge, an application designed to make constant use of upstream bandwidth is exceedingly bad.
If A and B are both necessary conditions of a bad result, and both are voluntary human actions, then it is a fallacy to treat A as if it were an inevitable fact of nature and only B as a choice for which someone is responsible. To blame B instead of A or both, one needs an argument for B being a bad action and A a good one.
The slowness of residential links in USA, and their asymmetry, are both due to severe lack of competition in broadband markets. This in turn is due to national policies of granting right of way, local monopolies, and subsidies to telcos and cable companies, and permitting them to abuse customers outrageously, with minimal corresponding requirements or enforcement of mandates on behalf of the public.
On the other hand, p2p developers have merely coded for the internet as it was meant to be, and has the potential to be, as a network of peers not reliant on big commercial content providers. It is somewhat backwards to blame p2p for not capitulating to the distortions introduced by bad policies, rather than concluding that the policies have artificially made p2p into a problem. |
|
atom_galaxy
@atomicity.org
|  reply to devnuller
Wouldn't this be a prime candidate to fix by properly using the TOS and priority packet fields? p2p apps should set priority to minimum and games and VoIP should set it at max and there we are, low-latency for apps that need it, in a protocol-defined well-mannered way.
I'm asking because I honestly don't know, I hope one of you gurus can enlighten me why this is not a solution (because if it was, it would already have been done). |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| 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. |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| reply to atom_galaxy
said by atom_galaxy :
Wouldn't this be a prime candidate to fix by properly using the TOS and priority packet fields? p2p apps should set priority to minimum and games and VoIP should set it at max and there we are, low-latency for apps that need it, in a protocol-defined well-mannered way. If applications and users could be trusted to appropriately set the priority of their traffic, then yes this would work.
Unfortunately there's too much of a "screw everyone else as long as I get mine" attitude for this to work. Just look at all of the effort that these developers are going to kludge together solutions to work around ISP prioritization. When presented with the problem of "Your application is causing issues on the network" the developers turned to find ways to stealth and hide their traffic even more. The ISPs aren't innocent in this -- this escalation in coding was largely the result of overreach in management such as the Sandvine TCP RST implementations.
A few folks have suggested that Comcast's interest in P4P (ie Pando Networks) is simply to show the FCC they are playing nice with P2P. I suspect in reality the interest is being able to inject network awareness into P2P transfers using an intelligent controller. Getting your content closer to you is a nice fluffy selling point, but it does nothing to address the concerns of congestion. The problem is right now it's up to the P2P clients to decide when the network is idle or not -- if the P4P controller could limit session setup based on network use thresholds, then there might be a better coexistence of P2P traffic on ISP networks. Of course, this requires P2P users to play nice and use the P4P controllers, which pretty much means this has a very limited chance of success. |
|
blank
@senescomarine.com
| reply to devnuller
if you ask me there all asses and should add more bandwidth problem solved
these companys have been given a ton of tax payer dollars to build and then town and city monopolies
then spend billions of dollars on software to shape and throttled peoples internets connections
they over sell there connections
if they built the network like they should have there would be no bandwidth problems to start with
what they want to do is sell less for more
being give us less for more moeny |
|
SuperWISP
join:2007-04-17
Laramie, WY
| reply to funchords
A very bad thing for the network
Robb, we all know that you're rooting for the pirates and bandwidth hogs, so of course you are going to try to characterize this "new" software as a gift from the Deity him/her/itself. The fact of the matter is that this new malware doesn't participate in any explicit congestion notification mechanism, including those proposed as IETF standards. Therefore, the only way it can decide to slow down is if it has ALREADY DAMAGED THE NETWORK by causing packets to be dropped. |
|
SuperWISP
join:2007-04-17
Laramie, WY
| reply to swhx7
Sorry, but espaeth is correct
It's necessarily much more expensive to deliver bandwidth to the end user via the last mile than it is to deliver it at a server farm. I know this because I'm out there every day -- on roofs, in users' homes, climbing radio towers -- to make that "last mile" link. Content providers should not be able to shift their bandwidth costs to ISPs, multiplying them in the process. See my testimony before the FCC at »www.brettglass.com/FCC/remarks.html for a detailed explanation of why. |
|
NetAdmin
CCNA
join:2008-05-22
| said by SuperWISP :Content providers should not be able to shift their bandwidth costs to ISPs, multiplying them in the process. Nobody is magically shifting costs anywhere because all the costs are paid for by everyone connected to the network.
--
There is no such thing as too much vacation, but I would wager that there is such a thing as too little. |
|
ezln23
@qwest.net
| reply to edam
Re: Is this a good thing for the net?
P2P does not reduce traffic because it enables the delivery of media that would otherwise cost too much money or is unavailable (music, movies, etc.). It may, in fact, be more efficient than delivering the same amount of data through a CDN and it is certainly cheaper for the distributor of the media. |
|
NetAdmin
CCNA
join:2008-05-22
| reply to a333
said by a333 :The throttling of particular packets by itself violates the principles of TCP. No, it violates the End-to-end design principle. TCP is designed is such a way that it works VERY well QoS schemes.
--
There is no such thing as too much vacation, but I would wager that there is such a thing as too little. |
|
NetAdmin
CCNA
join:2008-05-22
| reply to espaeth
said by espaeth :You start a standard upload of that 400MB video to Grandma Ginny, walk away, and once your transfer finishes there is no more traffic on the network. Using a P2P application, on the other hand, will keep putting bits on the network for as long as you let the application run. Little Timmy queues up some MP3s to download in the morning before he goes to school -- even though the transfer will probably finish in the first 30-45 minutes, the P2P app will keep uploading to other P2P clients the entire time he's away at school, or even longer if he leaves the client running after he gets home. I would like to point out that more BT clients are now setting defaults that eliminate this issue. Most BT clients will shutdown the transfer once the user has reached an Upload to Download ratio of greater than or equal to 1. Users have to manually change that option to seed indefinitely.
--
There is no such thing as too much vacation, but I would wager that there is such a thing as too little. |
|
espaeth
Digital Plumber
Premium,MVM
join:2001-04-21
Minneapolis, MN
·voip.ms
·Vitelity VOIP
·Callcentric
·VoiceStick
·ViaTalk
·Comcast
·Embarq
| said by NetAdmin :I would like to point out that more BT clients are now setting defaults that eliminate this issue. Most BT clients will shutdown the transfer once the user has reached an Upload to Download ratio of greater than or equal to 1. Users have to manually change that option to seed indefinitely. Which is great if people actually update their software. Considering the number of SQL slammer packets I still see hitting my firewall to this day, forgive me if I remain skeptical that this will make a difference anytime soon. |
|
