Joe Greco wrote,
There are lots of things that could heavily stress your upload channel. Things I've seen would include:
1) Sending a bunch of full-size pictures to all your friends and family, which might not seem too bad until it's a gig worth of 8-megapixel photos and 30 recipients, and you send to each recipient separately, 2) Having your corporate laptop get backed up to the company's backup server, 3) Many general-purpose VPN tasks (file copying, etc), 4) Online gaming (capable of creating a vast PPS load, along with fairly steady but low volumetraffic),
etc. P2P is only one example of things that could be stressful.
These things all happen - but they simply don't happen 24 hours a day, 7 days a week. A P2P client often does. <snip for brevity>
The questions boil down to things like:
1) Given that you unable to provide unlimited upstream bandwidth to your end users, what amount of upstream bandwidth /can/ you afford to provide?
Again - it depends. I could tell everyone they can have 56k upload continuous and there would be no problem from a network standpoint - but it would suck to be a customer with that restriction. It's a balance between providing good service to most customers while leaving us options.
What Amplex won't do...
Provide high burst speed if you insist on running peer-to-peer file sharing on a regular basis. Occasional use is not a problem. Peer-to-peer networks generate large amounts of upload traffic. This continuous traffic reduces the bandwidth available to other customers - and Amplex will rate limit your connection to the minimum rated speed if we feel there is a problem.
So, the way I would read this, as a customer, is that my P2P traffic would most likely eventually wind up being limited to 256kbps up, unless I am on the business service, where it'd be 768kbps up. Depends on your catching our attention. As a 'smart' consumer you might choose to set the upload limit on your torrent client to 200k and the odds are pretty high we would never notice you.
For those who play nicely we don't restrict upload bandwidth but leave it at the capacity of the equipment (somewhere between 768k and 1.5M). Yep - that's a rather subjective criteria. Sorry.
This seems quite fair and equitable. It's clearly and unambiguously disclosed, it's still guaranteeing delivery of the minimum class of service being purchased, etc.
If such an ISP were unable to meet the commitment that it's made to customers, then there's a problem - and it isn't the customer's problem, it's the ISP's. This ISP has said "We guarantee our speeds will be as good or better than we specify" - which is fairly clear.
We try to do the right thing - but taking the high road costs us when our competitors don't. I would like to think that consumers are smart enough to see the difference but I'm becoming more and more jaded as time goes on....
One solution is to stop accepting new customers where a tower is already operating at a level which is effectively rendering it "full."
Unfortunately "full" is an ambiguous definition. Is it when: a) Number of Customers * 256k up = access point limit? b) Number of Customers * 768k down = access point limit? c) Peak upload traffic = access point limit? d) Peak download traffic = access point limit? (e) Average ping times start to increase? History shows (a) and (b) occur well before the AP is particularly loaded and would be wasteful of resources. (c) occurs quickly with a relatively small number of P2P clients. (e) Ping time variations occur slightly before (d) and is our usual signal to add capacity to a tower. We have not yet run into the situation where we can not either reduce sector size (beamwidth, change polarity, add frequencies, etc.) but that day will come and P2P accelerates that process without contributing the revenue to pay for additional capacity. As a small provider there is a much closer connect between revenue and cost. 100 'regular' customers pay the bills. 10 customers running P2P unchecked doesn't (and makes 90 others unhappy). Were upload costs insignificant I wouldn't have a problem with P2P - but that unfortunately is not the case. Mark