Re: ISPs slowing P2P traffic...
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
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
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.
That is not in evidence. In fact, quite the opposite... given the scenario previously described (1.5M tower backhaul, 256kbps customer CIR), it would definitely be a problem. The data doesn't become smaller simply because it is Web traffic.
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.
That is also not in evidence, as it is well within what the link should be able to handle.
It's not the bandwidth, it's the number of packets being sent out.
Well, PPS can be a problem. Certainly it is possible to come up with hardware that is unable to handle the packets per second, and wifi can be a bit problematic in this department, since there's such a wide variation in the quality of equipment, and even with the best, performance in the PPS arena isn't generally what I'd consider stellar. However, I'm going to guess that there are online gaming and VoIP applications which are just as stressful. Anyone have a graph showing otherwise (preferably packet size and PPS figures on a low speed DSL line, or something like that?)
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
Um, I was under the impression that FastTrack was based on TCP...? I'm not a file-sharer, so I could be horribly wrong. But if it is based on TCP, then one would tend to assume that actual P2P data transfers would appear to be very similar to any other HTTP (or more generally, TCP) traffic - and for transmitted data, the packets would be large. I was actually under the impression that this was one of the reasons that the DPI vendors were successful at selling the D in DPI.
tie up the AP's radio time, and the other nine customers call and complain.
That would seem to be an implementation issue. I don't hear WISP's crying about gaming or VoIP traffic, so apparently those volumes of packets per second are fine. The much larger size of P2P data packets should mean that the rate of possible PPS would be lower, and the number of individual remote hosts should not be of particular significance, unless maybe you're trying to implement your WISP on consumer grade hardware. I'm not sure I see the problem.
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.
Yeah, but "little pieces" still works out to fairly sizeable chunks, when you look at it from the network point of view. It isn't trying to download a 600MB ISO with data packets that are only 64 bytes of content each.
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.
If so, there's also "Internet," "service," and "provider" in ISP. P2P is "nasty" because it represents traffic that wasn't planned for or allowed for in many business models, and because it is easy to perceive that traffic as "unnecessary" or "illegitimate." For now, you can get away with placing such a limit on your broadband service, and you "still have a job," but there may well come a day when some new killer service pops up. Imagine, for example, TiVo deploying a new set of video service offerings that bumped them back up into being THE device of the year (don't think TiVo? Maybe Apple, then... who knows?) Downloads "interesting" content for local storage. Everyone's buzzing about it. The lucky 10% buy it. Now the question that will come back to you is, why can't your network deliver what's been promised? The point here is that there are people promising things they can't be certain of delivering. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Jan 13, 2008, at 3:50 PM, Joe Greco wrote:
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.
That is not in evidence. In fact, quite the opposite... given the scenario previously described (1.5M tower backhaul, 256kbps customer CIR), it would definitely be a problem. The data doesn't become smaller simply because it is Web traffic.
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.
That is also not in evidence, as it is well within what the link should be able to handle.
It's not the bandwidth, it's the number of packets being sent out.
Well, PPS can be a problem. Certainly it is possible to come up with hardware that is unable to handle the packets per second, and wifi can be a bit problematic in this department, since there's such a wide variation in the quality of equipment, and even with the best, performance in the PPS arena isn't generally what I'd consider stellar. However, I'm going to guess that there are online gaming and VoIP applications which are just as stressful. Anyone have a graph showing otherwise (preferably packet size and PPS figures on a low speed DSL line, or something like that?)
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
Um, I was under the impression that FastTrack was based on TCP...? I'm not a file-sharer, so I could be horribly wrong. But if it is based on TCP, then one would tend to assume that actual P2P data transfers would appear to be very similar to any other HTTP (or more generally, TCP) traffic - and for transmitted data, the packets would be large. I was actually under the impression that this was one of the reasons that the DPI vendors were successful at selling the D in DPI.
tie up the AP's radio time, and the other nine customers call and complain.
That would seem to be an implementation issue. I don't hear WISP's crying about gaming or VoIP traffic, so apparently those volumes of packets per second are fine. The much larger size of P2P data packets should mean that the rate of possible PPS would be lower, and the number of individual remote hosts should not be of particular significance, unless maybe you're trying to implement your WISP on consumer grade hardware.
I'm not sure I see the problem.
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.
Yeah, but "little pieces" still works out to fairly sizeable chunks, when you look at it from the network point of view. It isn't trying to download a 600MB ISO with data packets that are only 64 bytes of content each.
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.
If so, there's also "Internet," "service," and "provider" in ISP.
P2P is "nasty" because it represents traffic that wasn't planned for or allowed for in many business models, and because it is easy to perceive that traffic as "unnecessary" or "illegitimate."
For now, you can get away with placing such a limit on your broadband service, and you "still have a job," but there may well come a day when some new killer service pops up. Imagine, for example, TiVo deploying a new set of video service offerings that bumped them back up into being THE device of the year (don't think TiVo? Maybe Apple, then... who knows?) Downloads "interesting" content for local storage. Everyone's buzzing about it. The lucky 10% buy it.
P2P based CDN's are a current buzzword; Verilan even has a white paper on it https://www.verisign.com/cgi-bin/clearsales_cgi/leadgen.htm? form_id=9653&toc=e20050314159653020&ra=72.219.222.192&email= I think we are going to see a lot more of this, and not just from "kids." Regards Marshall
Now the question that will come back to you is, why can't your network deliver what's been promised?
The point here is that there are people promising things they can't be certain of delivering.
... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http:// www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e- mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
P2P based CDN's are a current buzzword; Verilan even has a white paper on it
I think we are going to see a lot more of this, and not just from "kids."
Regards Marshall This should prove to be interesting. The Video CDN model will be a
Password protected link. threat to far more operators than P2P has been to the music industry. Cable companies make significant revenue from video content (ok - that was obvious). Since they are also IP Network operators they have a vested interest in seeing that video CDN's that bypass their primary revenue stream fail. The ILEC's are building out fiber mostly so that they can compete with the cable companies with a triple play solution. I can't see them being particularly supportive of this either. As a wireless network operator I'm not terribly interested in helping 3rd parties that cause issue on my network with upload traffic (rant away about how were getting paid by the end user to carry this traffic...). Mark
P2P based CDN's are a current buzzword;
P2P based CDN's might be a current buzzword, but are nothing more than P2P technology in a different cloak. No new news here.
This should prove to be interesting. The Video CDN model will be a threat to far more operators than P2P has been to the music industry.
Cable companies make significant revenue from video content (ok - that was obvious). Since they are also IP Network operators they have a vested interest in seeing that video CDN's that bypass their primary revenue stream fail. The ILEC's are building out fiber mostly so that they can compete with the cable companies with a triple play solution. I can't see them being particularly supportive of this either. As a wireless network operator I'm not terribly interested in helping 3rd parties that cause issue on my network with upload traffic (rant away about how were getting paid by the end user to carry this traffic...).
At the point where an IP network operator cannot comprehend (or, worse, refuses to comprehend) that every bit received on the Internet must be sourced from somewhere else, then I wish them the best of luck with the legislated version of "network neutrality" that will almost certainly eventually result from their shortsighted behaviour. You do not get a free pass just because you're a wireless network operator. That you've chosen to model your network on something other than a 1:1 ratio isn't anyone else's problem, and if it comes back to haunt you, oh well. It's nice that you can take advantage of the fact that there are currently content-heavy and eyeball-heavy networks, but to assume that it must stay that way is foolish. It's always nice to maintain some particular model for your operations that is beneficial to you. It's clearly ideal to be able to rely on overcommit in order to be able to provide the promises you've made to customers, rather than relying on actual capacity. However, this will assume that there is no fundamental change in the way things work, which is a bad assumption on the Internet. This problem is NOTHING NEW, and in fact, shares some significant parallels with the way Ma Bell used to bill out long distance vs local service, and then cried and whined about how they were being undercut by competitive LD carriers. They ... adapted. Can you? Will you? And yes, I realize that this borders on unfair-to-the-(W)ISP, but if you are incapable of considering and contemplating these sorts of questions, then that's a bad thing. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
On Sun, 13 Jan 2008, David E. Smith wrote:
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.
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
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
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of David E. Smith Sent: Sunday, January 13, 2008 12:03 PM To: nanog@merit.edu Subject: Re: ISPs slowing P2P traffic... 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.
participants (7)
-
David E. Smith -
Joe Greco -
Lasher, Donn -
Mark Radabaugh -
Marshall Eubanks -
Mikael Abrahamsson -
Rubens Kuhl Jr.