P4P Missing the Bandwidth Utilization Boat

Verizon recently made public research data on reducing the amount of P2P traffic flowing over an ISP’s network, thereby reducing costs to ISPs and in theory Verizon’s costs.The basic premise is to add routing and topology awareness to P2P protocols, keeping traffic localized and reducing an ISP’s costs.

The researchers measured the average per-hop count and the average completion time of downloading a 12M file, with a module for simulating BitTorrent traffic. The findings are a result of the P4P Working Group, a partnership among ISPs and P2P networks. The stated goals of P4P are:

  • Improve throughput to P2P users
  • Allow ISPs to manage link utilization
  • Reduce number of links transited by content
  • Push traffic from undesirable (expensive/limited capacity) links to more desirable (inexpensive/available capacity) links

It seems as though the P4P Working Group has fallen victim to the law of unintended consequences. If P2P file sharing is localized, that means files being downloaded by one subscriber are being served (uploaded) from other local subscribers. Bottom line is that P4P will force more upstream traffic on the local access links then otherwise used by “traditional” P2P techniques. Sure, in a world of “infinite bandwidth” then the P4P concept works wonders. The problem is that bandwidth is not infinite, and in the case of wireless access networks, the radio bandwidth is typically the most expensive and the most limited of the bandwidth resources in the network. Even though the goal of P4P is to push traffic from expensive/limited capacity links to more inexpensive available capacity links, a P4P architecture will actually have the affect of drastically increasing the amount of concurrent upstream bandwidth used for sharing files over the access network.

The current study only measured ISP hop counts and download time as a cost factor. When considering the cost reduction advantages of P4P, the key measurement should be bandwidth utilization on the access network, rather than the ISP hop count. At Arbor, we’ve had customers that have actually had to double their access capacity every 6 weeks prior to deploying intelligent bandwidth management techniques to upstream P2P file sharing. And this was with traditional P2P topologies. Consider the extreme service and economic impact of localized file sharing with P4P, where the majority of downloads would be purposely serviced by the local access links.

The bottom line is that the findings of the P4P Working Group should be considered preliminary, as they need to take into consideration all aspects of today’s network architectures.

2 Responses to “P4P Missing the Bandwidth Utilization Boat”

April 17, 2008 at 2:20 pm, dirtywerx said:

One must also consider that in the residential/consumer market there are 2 basic media sets in use:

1) shared local access (cable/wireless)
2) dedicated local access (dsl/fios)

In a world where competition (and survival) may depend on CAPEX differences between competitors pushing upgrades and costs to the competitors makes infinite sense.

VZ has, essentially everywhere, dedicated local access (fios/dsl). The competition to VZ has mostly shared access media. For the competitors to match the rates/costs of VZ they will be, in a world of more localized p2p access/delivery, forced into more upgrades and higher infrastructure costs (more CAPEX expenditures).

In the long run this p4p initiative only benefits providers with dedicated access media… it only benefits VZ.

April 18, 2008 at 2:01 pm, Danny McPherson said:

Good point dirtywerx.. I agree. I suspect that content management by ISPs with a P4P model (i.e., copyright, DRM, etc.. and illegal content – e.g., child exploitation) will be an issue as well, in particular given MPAA, IFPI and similarly remarks. As such, users will be reluctant to employ such systems without some economic incentive. Furthermore, I believe that peak transfer rates will increase, as client/server RTTs will be less, and this will only exacerbate the multi-access local loop contention problem.

Comments are closed.