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.

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

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

I think we are going to see a lot more of this, and not just from "kids."

Regards
Marshall

P2P based CDN's are a current buzzword; Verilan even has a white paper on it

Verisign is a global provider of domain name registry services and internet infrastructure - Verisign

Password protected link.

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