I’m positive you all know that. I also hope that you’re making sure it’s not hogging your enterprise network (if you’re managing one); in case you have to detect P2P traffic in your enterprise network, read the Catching the torrent guy post (or get in touch with our NIL Monitor guys if you need remote monitoring help ... the e-mail address is hidden at the bottom of a long marketese document).
Service Providers are not so fortunate – some Internet users claim using unlimited amounts of P2P traffic is their birthright. I don’t really care what kind of content these users transfer, they are consuming enormous amounts of network resources due to a combination of P2P client behavior (which is clearly “optimized” to grab as much as possible) and the default TCP/QoS interaction.
Let’s start with the P2P behavior:
- P2P implementations (for example, BitTorrent clients) open a large amount of simultaneous TCP sessions. 200 concurrent sessions is a very “reasonable” number and some people claim that the 10 new sessions per second limit imposed by Windows XP SP2 is reducing their speed ... now you know how many sessions they tend to open.
- P2P client can saturate any link for a very long time. I’m a heavy Internet user, but I still use around 1% of my access speed (long-term average). A P2P client can bring the long-term average close to 100%.
I wouldn’t mind the reckless implementations of P2P clients if the Internet would be an infrastructure where every user gets its fair share of bandwidth. Unfortunately, the idealistic design of the early Internet ensures that (using default router settings) every TCP session gets the same amount of bandwidth. A P2P user with 200 concurrent sessions thus gets 200 times the bandwidth of another user downloading her e-mail with a POP3 session. Clearly not a win-win situation (for anyone but the P2P guy) that could easily result in “a few” annoyed calls to the SP helpdesk.
What we would need to cope with the P2P users is per-user (per-IP-address) queuing, which is not available on any router that I’m familiar with (let alone on any high-speed platform). If you have other information, please share it in the comments.
The best solution I’m aware of is a dedicated box like Cisco’s SCE that can perform per-user measuring with real-time actions. Unfortunately, we cannot deploy SCE at every bottleneck in the network; it’s usually deployed somewhere between the access and core network with plenty of bandwidth surrounding it.
To address the P2P challenge with SCE, you could define very smart bandwidth groups or you could use SCE to track per-user quotas (actually per-IP-address quotas) and to act once a user exceeds her quota – for example, by hard-limiting the user’s bandwidth or remarking her packets with a low-priority DSCP value which can then be used to select a different (low-priority) queue on congested links.
Are you curious whether SCE can help you solve your problems? Why don’t you get in touch with our Professional Services team; these guys have deployed SCE-based solutions in over 20 large SP networks worldwide. Alternatively, you might want to attend our SCE training.