ISPs slowing P2P traffic...

Mailman List Mirror (Read Only)
1

It may. Some of those other things will, too. I picked 1) and 2) as
examples where things could actually get busy for long stretches of
time.

The wireless ISP business is a bit of a special case in this regard, where P2P traffic is especially nasty.

If I have ten customers uploading to a Web site (some photo sharing site, or Web-based email, say), each of whom is maxing out their connection, that's not a problem.

If I have one customer running Limewire or Kazaa or whatever P2P software all the cool kids are running these days, even if he's rate-limited himself to half his connection's maximum upload speec, that often IS a problem.

It's not the bandwidth, it's the number of packets being sent out. One customer, talking to twenty or fifty remote hosts at a time, can "kill" a wireless access point in some instances. All those little tiny packets tie up the AP's radio time, and the other nine customers call and complain.

One customer just downloading stuff, disabling all the upload features in their P2P client of choice, often causes exactly the same problem, as the kids tend to queue up 17 CDs worth of music then leave it running for a week. The software tries its darnedest to find each of those hundreds of different files, downloading little pieces of each of 'em from multiple servers.

We go out of our way to explain to every customer that P2P software isn't permitted on our network, and when we see it, we shut the customer off until that software is removed. It's not ideal, but given the limitations of wireless technology, it's a necessary compromise. I still have a job, so we must have a few customers who are alright with this limitation on their broadband service.

There's more to bandwidth than just bandwidth.

David Smith
MVN.net

2

The wireless ISP business is a bit of a special case in this regard, where P2P traffic is especially nasty.

It's not the bandwidth, it's the number of packets being sent out. One customer, talking to twenty or fifty remote hosts at a time, can "kill" a wireless access point in some instances. All those little tiny packets tie up the AP's radio time, and the other nine customers call and complain.

Packets per second performance is specially low with Wi-Fi and Mesh
Wi-Fi, but not with all wireless technologies. WiMAX in the standards
side and some proprietary protocols have much better media access
mechanisms that can better withstand P2P and VoIP.

Rubens

3

If it's concurrent tcp connections per customer you're worried about, then I guess you should aquire something that can actually enforce a limitation you want to impose.

Or if you want to protect yourself from customers going encrypted on you, I guess you can start to limit the concurrent number of servers they can talk to.

I can think of numerous problems with this approach though, so like other people here have suggested, you really need to look into your technical platform you use to produce your service as it's most likely is not going to work very far into the future. P2P isn't going to go away.

4

The wireless ISP business is a bit of a special case in this regard, where

P2P traffic is especially nasty.

It's not the bandwidth, it's the number of packets being sent out....
I still have a job, so we must have a few customers who are alright with

this limitation on their broadband service.

Speaking as a former wifi network operator, I feel for guys who are doing it
now, it's not an easy fence to sit on, between keeping your network
operational, and keeping your customers happy. In our case, we realized two
things very early on.

1. Radio PPS limitations appeared far sooner than BPS limits. A certain
vendor who made 3Mbit SSFH radios, which could carry about 1.7Mbit with big
packets, choked at about 200kbit with small packets. Radio methods of
traffic shaping were completely ineffective, so we needed a better way to
keep service levels up.

2. P2P was already a big challenge (back in the early Kazaa days) so we
found hardware solutions (Allot) with Layer7 awareness to deal with the
issue. Surprise surprise, even back in 2001, we found 60% of our traffic
from any given 'tower' was P2P traffic.

We implemented time-of-day based limits on P2P traffic, both in PPS and in
BPS. Less during the day (we were a business ISP) and more during the night,
and everybody was happy.

Never once in 5+ years of operating that way, did we get a customer
complaining about their speeds for P2P. In fact, more often than not, we'd
see a customer flatline their connection, call their IT guy, explain what
the traffic was, and his reaction was "Those SOB's.. I told them not to use
that stuff.. What port is it on?? (30 seconds later) is it gone? Good!! Any
time you see that, call me directly!"

In the end, regardless of customer complaints, operators need to be able to
provide the service they are committed to selling, in spite of customers
attempts to disrupt that service, intentional or accidental.