ISPs slowing P2P traffic...

The vast majority of our last-mile connections are fixed wireless. The
design of the system is essentially half-duplex with an adjustable ratio
between download/upload traffic. PTP heavily stresses the upload
channel and left unchecked results in poor performance for other
customers.

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.

Bandwidth quotas don't help much since it just moves the problem to the
'start' of the quota time.

Hard limits on upload bandwidth help considerably but do not solve the
problem since only a few dozen customers running a steady 256k upload
stream can saturate the channel. We still need a way to shape the
upload traffic.

It's easy to say "put up more access points, sectors, etc.) but there
are constraints due to RF spectrum, tower space, etc.

Sure, okay, and you know, there's certainly some truth to that. We know
that the cellular carriers and the wireless carriers have some significant
challenges in this department, and even the traditional DSL/cable providers
do too.

However, as a consumer, I expect that I'm buying an Internet connection.
What I'm buying that Internet connection for is, quite frankly, none of
your darn business. I may want to use it for any of the items above. I
may want to use my GPRS radio as emergency access to KVM-over-IP-reachable
servers. I may want to use it to push videoconferencing from my desktop.
There are all these wonderful and wildly differing things that one can do
with IP connectivity.

Unfortunately there are no easy answers here. The network (at least
ours) is designed to provide broadband download speeds to rural
customers. It's not designed and is not capable of being a CDN for the
rest of the world.

I'd consider that a bad attitude, however. Your network isn't being used
as "a CDN for the rest of the world," even if that's where the content
might happen to be going. That's an Ed Whitacre type attitude. You have
a paying customer who has paid you to move packets for them. Your network
is being used for heavy data transmission by one of your customers. You
do not have a contract with "the rest of the world." Unless you are
providing access to a walled garden, you have got to expect that your
customers are going to be sending and receiving data from "the rest of
the world." Your issue is mainly with the volume at which that is
happening, and shouldn't be with the destination or purpose of that
traffic.

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?

2) Are there any design flaws within your network that are making the
   overall problem worse?

3) What have you promised customers?

I would be much happier creating a torrent server at the data center
level that customers could seed/upload from rather than doing it over
the last mile. I don't see this working from a legal standpoint though.

Why not? There's plenty of perfectly legal P2P content out there.

Anyways, let's look at a typical example. There's a little wireless ISP
called Amplex down in Ohio, and looking at

http://www.amplex.net/wireless/wireless.htm

they say:

Connection Speeds

Our residential service is rated at 384kbps download and 256kbps up,
business service is 768kbps (equal down and up). The network normally
provides speeds well over those listed (up to 10 Mbps) but speed is
dependant on network load and the quality of the wireless connection.

Connection speed is nearly always faster than most DSL connections and
equivalent (or faster) than many cable modems.

Our competitors list maximum burst speeds with no guaranteed minimum speed.
We guarantee our speeds will be as good or better than we specify in the
service package you choose..

And then much further down:

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. 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.

You might want to check to see if you've made any guarantees about the
level of service that you'll provide to your customers. If you've made
promises, then you're simply in the unenviable position of needing to
make good on those. Operating an IP network with a basic SLA like this
can be a bit of a challenge. You have to be prepared to actually make
good on it. If you are unable to provide the service, then either there
is a failure at the network design level or at the business plan level.

One solution is to stop accepting new customers where a tower is already
operating at a level which is effectively rendering it "full."

... JG

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

I would be much happier creating a torrent server at the data center level that customers could seed/upload from rather than doing it over the last mile. I don't see this working from a legal standpoint though.
    
Why not? There's plenty of perfectly legal P2P content out there.

Hum... maybe there is an idea here.

I believe the bittorrent protocol rewards uploading users with faster downloading. Moving the upload content to a more appropriate point on the network (a central torrent server) breaks this model. How would a client get faster download speeds based on the uploads they made to a central server? To solve the inevitable legal issues there would also need to be a way to track how content ended up on the server as well. Are there any torrent clients that do this?

Mark