Considerations for ALTO with network-deployed P2P caches

P2P applications like file sharing and multimedia streaming are so popular that lots of P2P technologies have been increasingly utilized throughout the world. The goal of Application-Layer Traffic Optimization (ALTO) [I-D.ietf-alto-protocol] is to provide guidance to these applications, which have to select one or several hosts from a set of candidates that are able to provide a desired resource. Meanwhile, since wireless accesses to Internet have become pervasive with widely deployed WLANs, more and more people access Internet services via WLAN and the amount of P2P traffic in WLAN is explosively growing. In addition to a huge number of individually setup WLANs at homes, there has been an increasing trend for the government, organizations, and even traditional network operators to set up publicly accessible WLAN facilities. Even though the service may be free of charge, to use the resources effectively in a fair way, and to avoid congestion for the purpose of service availability are vital for these public WLANs. However, recent statistics reveal that P2P traffic accounts for 80% in part of China Mobile's WLANs, and traffic congestion at APs (access points) frequently occurs because of P2P applications. P2P traffic in WLANs not only causes problems on their own delivery quality, but also degrades the performance of other Internet applications in WLANs.

ALTO: application layer traffic optimization. For ALTO protocol, please refer to . AP: a wireless access point (or WAP) is a device that allows wireless devices to connect to a wired network using WLAN. The AP usually connects to a AC as a standalone device, but it can also be an integral component of the router itself. AC: a wireless access controller (or WAC) is the network entity that provides wire access via APs to the network infrastructure in the data plane, control plane, management plane, or a combination therein. DCP: Distributed coordination function (or DCF) is the fundamental MAC technique of the IEEE 802.11 based WLAN standard. DCF employs a CSMA/CA with binary exponential backoff algorithm. Forwarding Cache: is a traditional content cache, which caches content flows from outside its coverage and serves subsequent requestors under its coverage for the content. Reverse Cache: is a special content cache proposed for WLAN peers, which caches content flows from inside its coverage and serves subsequent requestor from outside its coverage for the content on behalf of the peers within its coverage. Bidirectional Cache: is a combination of a forwarding cache and a reverse cache. Transparent Cache: is a content cache deployed by network operators for third party SPs (e.g. P2P streaming services), which participates in the overlay's service provision implicitly via request redirection. Cooperative Cache: is a content cache deployed by network operators in cooperation with specific content delivering SPs (e.g. P2P streaming services), which participates in the overlay's service provision explicitly.

On one hand, it is well accepted that compared to fixed networks, mobile networks have some special characters, including small link bandwidth, high cost, limited radio frequency resource, and terminal battery. Therefore, it is recommended by [I-D.ietf-alto-deployments] that in mobile network, the usage of wireless link should be decreased as far as possible and be high-efficient. For example, in the case of a P2P service, the clients in the fixed network should decrease the data transport from the clients in the mobile networks, as well as the clients in the mobile networks should prefer the data transmission from the clients in the fixed networks. On the other hand, efforts have been put on using forwarding caches to optimize traffic pattern in such scenarios, which demonstrates great improvement in user experience and considerable traffic reduction at interworking points. What's more, owing to the characteristics of the DCF model in 802.11, there is an constant unfairness between uplink and downlink traffic in competing wireless channel resources, which leads to downlink congestion in WLAN resultant from P2P traffic (which constitutes the major part of uploading traffic). In particular, There is basic indication under the current DCF model, that in order to achieve fairness among mobile stations, in the long run, each stations has a equal chance of getting the wireless slot given they all have a sustainable long traffic to send. In other words, there is an implicit unfairness between uplink and downlink traffic under the BSS model, where the AP holds the throat of all the downlink traffic and competing with the uplink traffic from potentially a large group of other user mobile devices. However, traditional P2P cache (as a forward cache) cannot help here, since it does nothing to stop a WLAN peer from uploading. Hence, bidirectional caches are proposed, which contains a reverse cache as well as a forward cache can be deployed at the AC (Access Controller). The reverse cache can provide uploading service instead of the WLAN peers under the AC's coverage. As a result, the uplink bandwidth consumption at each AP can be reduced and the uplink congestion can be alleviated effectively. Simulation results in file-sharing scenarios show that, employing cache instead of WLAN peers accelerates file transfer by 42% while improving the throughput of other Internet applications under the same AP by 28%. With deployed P2P caches on the internal network, especially at a position as low as the AC-level, it could be sub-optimal to simply use the accessing network type as the divider for different PIDs and assign sufficient high cost within the wireless PID to prefer accessing remote peers over local peers blindly. To this end, this draft discusses the optimal ALTO deployment recommendations for a P2P application in terms of a wireless accessing network with network-deployed application-agnostic caches. In summary, the goal here is to illuminate applications through ALTO about these existing network capabilities to make full use of them in achieving application performance improvement and network cost reduction.

Fig. 1 illustrates the proposed architecture of a traditional uni-directional P2P cache (or Forwarding Cache for short) system for wired subscribers, deployed mainly for the purpose of reducing interworking P2P traffic. Forwarding Caches are assumed to be deployed at the interworking gateways to maximize their coverage for local subscribers. In transparent mode, they buffer downloading content from outside ISP networks, intercept the upcoming outgoing P2P requests from local subscribers and serve them with cached content instead. In cooperative mode, they register to the tracker as a super peer and are under the regulation of the tracker's private protocol.

Fig. 2 illustrates the proposed architecture of a bidirectional cache system in WLAN. In a WLAN, all AP will connect to a device named AC, and the AC can be seen as the gateway to Internet of the WLAN. For most settings, both the traffic flowing into the WLAN and the traffic flowing out of the WLAN pass through the AC, hence Bidirectional Caches are assumed to be deployed at AC to exploit the traffic locality. Besides the normal functions of a Forwarding Cache, A Bidirectional Cache in transparent mode buffers uploading content from inside the WLAN network, intercepts the upcoming outgoing P2P responses from local WLAN subscribers and serve the correspondent requester (be it another local WLAN subscriber or an outsider) with cached content instead. In cooperative mode, they register to the tracker as a super peer and are under the regulation of the tracker's private protocol.

Fig. 3 generalized the overall architecture of the potential P2P cache deployments inside an ISP with various access network types. As it shows, P2P caches may be deployed at various levels, including: the interworking gateway linking with other ISPs, internal access network gateways linking with different types of accessing networks (e.g. WLAN, cellular and wired), and even within an accessing network at the entries of individual WLAN sub-networks. Moreover, depending on the network context and the operator's policy, each cache can be a Forwarding Cache or a Bidirectional Cache.

For wired network operator, forwarding caching effectively localizes the downloading P2P traffic within the sub-net under its coverage resulting in reduction of network cost for cross-boundary peer selection, whereas reverse caching blocks the uploading traffic outside a wireless sub-net leading to elimination of network cost for wireless uploading peer selection. In other words, caching between pairs of endpoints changes the traffic cost along the way. Therefore, it is expected that by cooperation between the network operator and the P2P SP in building up various caching system and sharing information through ALTO protocol about these facilities brings benefits to both party. In order to do that, it is proposed to use locations of caches as dividers of different PIDs to guide intra-ISP network abstraction and mark costs among them according to the location and type of relevant caches. Otherwise, if we stick to using network types as dividers for PIDs, there is no chance that a cost map would ever grasp this kind of information about node pairs within the same PID.

It is reasonable to use Forwarding Caches as separators for different PIDs, since it accelerates P2P traffic in a particular direction, indicating varied costs among these adjacent partitions. For instance as shown in Fig.3, assuming the L2 Cache in AN1 of ISP 2 network is a Forwarding Cache, the downloading traffic from other peers outside to AN1 but within the same ISP2 can be buffered once and served AN1 network subsequently. The cost from AN2 or AN3 to AN1 is reduced as result, but not vise visa. In other words, the ISP 2 network should be sub-divided into {AN1} and {AN2, AN3}, and the incoming P2P cost for {AN1} is reduced, for the sake of the L2 Forwarding Cache located at the entry of AN1.

Since Bidirectional Cache are deployed in wireless accessing networks to further reduce the outgoing and local-in-local-out traffic costs in both directions, it seems straightforward to join the adjacent partitions together and modify the cost between insiders to zero. However, there is hidden layering within the Bidirectional Cache coverage, as the blocking of uploading traffic only works for traffic traverse pass the Bidirectional Cache. If the cache is located too high as to be outside a local routing subnet, the local traffic flows within the subnet cannot benefit from the Bidirectional Cache.

As there is both CAPEX and OPEX expenditures for dedicated P2P Cache devices, it may be cost-efficient for caches to make buffering/serving decisions based on the popularity of the specific content. How to expose this application-relevant information to ALTO under such context is an open issue.

Luckily, in the cooperative-mode, a cache is playing as a normal peer under the tracker, and the latter can make the "right" decision in choosing in favor of the former under the guidance of the ALTO response while the tracker itself would take care of the content availability problem. If the cache doesn't have the content in question, it would no appear in the peer list handed in to ALTO server by the tracker. In this case, the ALTO server can collect the information about caching sub-system in the network, identify those "caching" peers in the peer list of an cost request from an ALTO client, and arrange the returned rank list accordingly. For example, a simple candidate-ranking policy for a cost query to a WLAN peer, could be caching peers at the beginning, then inside wired peers, and lastly outside wired peers. Moreover, the P2P SP and WLAN network operator may benefit even more by group popular files according to peers' geographic location or access types, and adapt its internal caching scheduling decisions about which files to be cached on which spot. In order to do that, it would be helpful that the ALTO server could provide to the client with the requesting peer's subscription types (i.e. wired/WLAN/ cellular/...) as well as geographic locations. Specific definitions are specified separately in

TBA

None.