P2P is emerging as a major paradigm for developing networked applications. However, the wide spread of P2P applications also exposes a fundamental issue in current network management and control.
In particular, the P4P project argues that there is a fundamental issue in traditional network management and control: emerging applications can have tremendous flexibility in how the data is communicated, and thus, they should be an integral part of network management and control.
However, if end hosts are to participate in network resource optimizations, then the networks cannot continue to be opaque but need to export their status and policy information. As a result, P4P, which stands for provider portal for P2P, allows explicit communications between network providers and applications.
P4P Design Overview
The P4P framework consists of a control-plane component and a data-plane component.
In the control plane, P4P introduces iTrackers to provide portals for P2P to communicate with network providers. The introduction of iTrackers allows P4P to divide traffic control responsibilities between P2P and providers, and also makes P4P incrementally deployable and extensible.
Specifically, each network provider, be it a conventional commercial network provider (e.g., AT&T), a university campus network, or a virtual service provider (e.g., Akamai), maintains an iTracker for its network. A P2P client obtains the IP address of the iTracker of its local provider through DNS query (with a new DNS record type P4P). Standard techniques can be applied to allow for multiple iTrackers in a given domain, especially for fault tolerance and scalability. An iTracker provides a portal for three kinds of information regarding the network provider: network status/topology; provider guidelines/policies; and network capabilities.
In the data plane, P4P allows routers on the data plane to give fine-grained feedback to P2P and enable more efficient usage of network resources. Specifically, routers can mark the ECN bits of TCP packets (or a field in a P2P header), or explicitly designate flow rates using XCP-like approaches; end hosts then adjust their flow rates accordingly. For instance, a multihomed network can optimize financial cost and improve performance through virtual capacity computed based on 95-percentiles. When the virtual capacity is approached, routers mark TCP packets and end hosts reduce their flow rates accordingly; thus the network provider can both optimize its cost and performance and allocate more bandwidth to P2P flows. We emphasize that the data plane component is optional and can be incrementally deployed. <-->
Control Plane Overview: iTrackers Interfaces and Functions
Here is a picture showing the potential entities in the P4P framework: iTrackers owned by individual network providers, appTrackers in P2P systems, and P2P clients (or peers for short). Not all entities might interact in a given setting. For example, trackerless systems do not have appTrackers. P4P does not dictate the exact information flow, but rather provides only a common messaging framework, with control messages encoded in XML for extensibility.
Entities and interactions between P4P components
A network provider may choose to implement a subset of the interfaces. The richness of information conveyed is also determined by the network provider. Note that a network provider may also enforce some access control to the interfaces to preserve security and privacy.
The info interface allows others, typically peers inside the provider network, to obtain network topology and status. Specifically, given a query for an IP address inside the network, the interface maps the IP address to a (ASID, PID, LOC) tuple, where ASID is the ID of the network provider (e.g., its AS number), PID is an opaque ID assigned to a group of network nodes, and LOC is a virtual or geographical coordinate of the node. Note that the opaque PID is used to preserve provider privacy at a coarse grain (e.g., a network provider can assign two PIDs to nodes at the same point of presence or PoP). Note also that LOC can be used to compute network proximity, which can be helpful in choosing peers. When sending an info query, a peer may optionally include its swarm ID (e.g., info hash of a torrent). The iTracker may keep track of peers participating in a swarm.
The policy interface allows others, for example peers or appTrackers, to obtain policies and guidelines of the network. Policies specify how a network provider would like its networks to be utilized at a high level, typically regardless of P2P applications; while guidelines are specific suggestions for P2P to use the network resources. To name a few examples of network policies: (1) traffic ratio balance policy, defining the ratio between inbound and outbound traffic volumes, for interdomain peering links; (2) coarse-grain time-of-day link usage policy, defining the desired usage pattern of specific links (e.g., avoid using links that are congested during peak times); and (3) fine-grain link usage policy. An example of network guidelines is that a network provider computes peering relationships for clusters of peers (e.g., clustered by PID). The policy interface can also return a set of normalized inter-PID costs, which indicate costs incurred to the provider when peers in two PIDs communicate.
The capability interface allows others, for example peers or content providers (through appTrackers), to request network providers' capabilities. For example, a network provider may provide different classes of services or on-demand servers in its network. Then an appTracker may ask iTrackers in popular domains to provide such servers and then use them as peers to accelerate P2P content distribution.