Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Actually, as someone who used to help run a mico-ISP, the problem with P2P for ISP's has little to do with piracy.

The major problem is it can absolutely rape networks - and it only takes one or two abusers to clog it up for everyone else.

In the end we simply kicked anyone who consistently ate up bandwidth with P2P - and network reliability improved no end.



Help me understand this. Did you not have bandwidth caps?

I understand how 'one or two abusers' could clog up a network at, say, a university where there might not be per-port or per-device limits on bandwidth.

But I pay my $40/mo. for 10 down 1 up, and I never get more than that. How does, say, seeding WoW updates 'clog it up for everyone else'?


P2P is a deliberately greedy process - you are consistently opening a large number of connections (as opposed to a single high volume connection).

One of the big issues with P2P is not the downloads per-se but the discovery process - that can seriously hammer the network (imagine how you stress test a server!)

Also; it's entirely infeasible to offer a service as you describe - partly because networks just don't work like that (this answers the other commenter too).

ADSL is a shared line; what other people are doing can adversely impact you regardless of the networks theoretical capability.


As someone who has studied P2P, none of this make sense to me. If I remember correctly, the Bittorrent protocol tries to maintain only a handful of connections at any given time. Parallel browser downloaders are capable of opening more connections.

Also, I don't see how the discovery process would stress a network. I would expect the actual download to place much more load on the server. For instance, I could be wrong, but I think a bittorrent client only needs to contact a tracker to discover other peers. Every iteration after, the client will try exactly one new peer. That hardly sounds stressful at all!

The last point you make is the only one I agree with. You've offered your users more theoretical bandwidth than you can actually deliver, which is common practice. Whether they are trying to use that bandwidth watching youtube videos or downloading with a P2P client, they will be using more bandwidth than you can handle.


Yeh, I probably didnt explain myself well..

> Parallel browser downloaders are capable of opening more connections

This is mostly what I was referring to. Light P2P users are not a problem - it's the heavy users that cause impact. We had a guy who was torrenting 1000's of files; essentially flooding the network with connections.


Oh, well, that's a different problem entirely :). Although I guess it's much harder to start 1000 downloads in a browser, theoretically it's possible!


That makes no sense. If you sold a service, you should have the capacity to provide it.


That actually make sense. What you say is like suggesting that, back in the modem era, an ISP should keep matching number of modems on it's end equal to the number of users it has.

If there's 10.000 users, there should be 10.000 modems to dial into? Business can't survive like this.


I'm not saying there needs to be a 1:1 relation. I'm saying that, if 40% of your users are connected on peak, you should have some number greater than 40% to supply them. (Obviously, you can't account for abnormal spikes in usage). In a normal day, I shouldn't get a busy tone!

In the same way, if you sell me an "unlimited" service, it had better be unlimited. I should be able to saturate my connection (with legitimate traffic; malicious users can (should?) be nuked from orbit) without being disconnected for "excessive" usage. Otherwise, It's not unlimited.


Actually AOL lost a massive class action suit because of its busy signals when they moved from an hourly rate to a flat monthly rate, and then couldn't deliver.

Does Google really have 7.5 GB set aside for every mailbox that exists? No. But people aren't being capped at 5 GB, either.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: