ISPs slowing P2P traffic...

Joe Greco jgreco at ns.sol.net
Sun Jan 13 20:50:23 UTC 2008


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



More information about the NANOG mailing list