ISPs slowing P2P traffic...

Marshall Eubanks tme at multicasttech.com
Sun Jan 13 22:24:57 UTC 2008



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.




More information about the NANOG mailing list