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