[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03

Application-Layer Traffic Optimization Group                     L. Deng
Internet-Draft                                              China Mobile
Intended status: Informational                                  Y. Zhang
Expires: January 05, 2014                    Chinese Academy of Sciences
                                                           July 04, 2013


      Considerations for ALTO with network-deployed P2P caches-00
                    draft-deng-alto-p2pcache-00.txt

Abstract

   Transparent 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
   transparent 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 proposed to use locations of caches as dividers of
   different DIPs to guide intra-ISP network abstraction and mark costs
   among them according to the location and type of relevant caches.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 05, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Deng & Zhang            Expires January 05, 2014                [Page 1]


Internet-DraConsiderations for ALTO with network-deployed P2P  July 2013


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Architecture . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.   T-Cache for Wired subscribers  . . . . . . . . . . . . .   4
     3.2.   B-Cache for WLAN subscribers . . . . . . . . . . . . . .   4
     3.3.  Generalized cache architecture for intra-ISP networks . .   5
   4.   Considerations for ALTO deployment with P2P Caches . . . . .   7
     4.1.   T-Cache: vertical separator from outsiders . . . . . . .   7
     4.2.  B-Cache: horizontal division within insiders  . . . . . .   7
   5.   Further Discussions  . . . . . . . . . . . . . . . . . . . .   7
     5.1.  5.1. Selective caching  . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   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.




Deng & Zhang            Expires January 05, 2014                [Page 2]


Internet-DraConsiderations for ALTO with network-deployed P2P  July 2013


   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.

2.  Motivation

   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 transparent 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 (as it requires of both downloading and
   uploading).  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
   of a WLAN.  The reverse cache can cache the P2P traffic flowing out
   of all the associated APs and provide uploading service for peers
   outside the WLAN.  As a result, the uplink bandwidth consumption at
   each AP can be reduced and the uplink congestion can be alleviated
   effectively.  Meanwhile, the forward cache can still act as the
   traditional P2P cache to reduce the cross domain traffic.  Simulation
   results in file-sharing scenarios show that, compared with
   traditional P2P cache, the bidirectional cache 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.



Deng & Zhang            Expires January 05, 2014                [Page 3]


Internet-DraConsiderations for ALTO with network-deployed P2P  July 2013


   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 and full use of them, in
   order to maximize intra-network localization for P2P traffic between
   wireless subscribers for both application performance improvement and
   network cost reduction.

3.  Architecture

3.1.  T-Cache for Wired subscribers

   Fig. 1 illustrates the proposed architecture of a traditional uni-
   directional P2P cache (or T-Cache for short) system for wired
   subscribers, deployed mainly for the purpose of reducing interworking
   P2P traffic.  T-Caches are assumed to be deployed at the interworking
   gateways to maximize their coverage for local subscribers.  They
   buffer downloading content from outside ISP networks, intercept the
   upcoming outgoing P2P requests from local subscribers and serve them
   with cached content instead.


        +--------------+                +------+
        | ISP 1 network+----------------+Peer 1|
        +-----+--------+                +------+
              |
     +--------+------------------------------------------------------+
     |                                               ISP 2 network   |
     |  +----------------+                +----------+               |
     |  |Interworking GW |----------------| T-Cache  |               |
     |  +-----+----------+                +----------+               |
     |        |                                                      |
     +--------+------------------------------------------------------+
              +---------------------------+
              |                           |
        +-----+-+                      +--+---+
        |Peer 2 |                      |Peer 3|
        +-------+                      +------+


         Figure 1: Architecture of T-cache at interworking gateway

3.2.  B-Cache for WLAN subscribers

   Fig. 2 illustrates the proposed architecture of a bidirectional cache
   (or B-Cache for short) system in WLAN.  In a WLAN, all AP will



Deng & Zhang            Expires January 05, 2014                [Page 4]


Internet-DraConsiderations for ALTO with network-deployed P2P  July 2013


   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 B-Caches are assumed to be deployed at AC to exploit
   the traffic locality.  Besides the normal functions of a T-Cache, A
   B-Cache 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.


        +--------------+                +------+
        | ISP 1 network+----------------+Peer 1|
        +-----+--------+                +------+
              |
     +--------+------------------------------------------------------+
     |        |                                      ISP 2 network   |
     |  +----------------+                +----------+               |
     |  |Interworking GW |----------------| T-Cache  |               |
     |  +-----+----------+                +----------+               |
     |        |                                                      |
     |        |                                                      |
     |  +-----+------+                +---------+                    |
     |  |    AC      +----------------+ B-Cache |                    |
     |  +-----+------+                +---------+                    |
     |        |                                                      |
     |        +-------------------------------+                      |
     |   +----+------+                  +-----+-----+                |
     |   |   AP_1    |     . . . .      |   AP_n    |                |
     |   +----+------+                  +-----+-----+                |
     |        |                               |                      |
     +--------+-------------------------------+----------------------+
              |                               |
           +--+----------+                    |
           |             |                    |
        +--+--+       +--+--+              +--+--+
        |Peer2|       |Peer3|              |Peer4|
        +-----+       +-----+              +-----+




                 Figure 2: Architecture of B-cache in WLAN

3.3.  Generalized cache architecture for intra-ISP networks

   Fig. 3 generalized the overall architecture of the potential P2P
   cache deployments inside an ISP with various access network types.



Deng & Zhang            Expires January 05, 2014                [Page 5]


Internet-DraConsiderations for ALTO with network-deployed P2P  July 2013


   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
   T-Cache or a B-Cache.


        +--------------+                +------+
        | ISP 1 network+----------------+Peer 1|
        +-----+--------+                +------+
              |
     +--------+------------------------------------------------------+
     |        |                                      ISP 2 network   |
     |  +---------+                                                  |
     |  |L1 Cache |                                                  |
     |  +-----+---+                                                  |
     |        +--------------------+----------------------+          |
     |        |                    |                      |          |
     | +------+------+      +------+-------+       +------+-------+  |
     | | AN1         |      | AN2          |       | AN3          |  |
     | | +---------+ |      | +----------+ |       |              |  |
     | | |L2 Cache | |      | |L2 Cache  | |       |              |  |
     | | +---------+ |      | +----------+ |       |              |  |
     | +------+------+      +------+-------+       +------+-------+  |
     |        |                                           |          |
     |        +--------------------+                      |          |
     |        |                    |                      |          |
     | +------+------+      +------+-------+       +------+-------+  |
     | | SUB-AN11    |      | SUB-AN12     |       | SUB-AN31     |  |
     | | +---------+ |      |              |       |              |  |
     | | |L3 Cache | |      |              |       |              |  |
     | | +---------+ |      |              |       |              |  |
     | +------+------+      +------+-------+       +------+-------+  |
     |        |                    |                      |          |
     +--------+--------------------+----------------------+----------+
              |                    |                      |
          +---+---+            +---+---+                  |
          |       |            |       |                  |
       +--+--+ +--+--+      +--+--+ +--+--+            +--+--+
       |Peer2| |Peer3|      |Peer4| |Peer5|            |Peer6|
       +-----+ +-----+      +-----+ +-----+            +-----+



          Figure 3: Generalized Architecture of intra-ISP Caches




Deng & Zhang            Expires January 05, 2014                [Page 6]


Internet-DraConsiderations for ALTO with network-deployed P2P  July 2013


4.  Considerations for ALTO deployment with P2P Caches

   All in all, transparent 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 transparent 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 proposed to use locations of caches as dividers of
   different DIPs to guide intra-ISP network abstraction and mark costs
   among them according to the location and type of relevant caches.

4.1.  T-Cache: vertical separator from outsiders

   It is reasonable to use T-Caches as separators for different DIPs,
   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 T-Cache, the downloading traffic from other local peers
   outside to AN1 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 T-Cache located at the entry
   of AN1.

4.2.  B-Cache: horizontal division within insiders

   Since B-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 B-Cache coverage, as the blocking
   of uploading traffic only works for traffic traverse pass the
   B-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 B-Cache.

5.  Further Discussions

5.1.  5.1.  Selective caching








Deng & Zhang            Expires January 05, 2014                [Page 7]


Internet-DraConsiderations for ALTO with network-deployed P2P  July 2013


   As there is both CAPEX and OPEX expenditures for dedicated P2P Cache
   devices, it may be cost-efficient for transparent 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.

6.  Security Considerations

   TBA

7.  IANA Considerations

   None.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

8.2.  Informative References

   [I-D.ietf-alto-deployments]
              Stimerling, M., Kiesel, S., and S. Previdi, "ALTO
              Deployment Considerations", draft-ietf-alto-deployments-06
              (work in progress), February 2013.

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft-
              ietf-alto-protocol-13 (work in progress), September 2012.

Authors' Addresses

   Lingli Deng
   China Mobile

   Email: denglingli@chinamobile.com


   Yan Zhang
   Chinese Academy of Sciences

   Email: zhangy@hpnl.ac.cn




Deng & Zhang            Expires January 05, 2014                [Page 8]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/