One document matched: draft-deng-alto-p2pcache-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-deng-alto-p2pcache-00.txt" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title>Considerations for ALTO with network-deployed P2P caches-00
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Lingli Deng" initials='L.L.'
surname="Deng">
<organization>China Mobile</organization>
<address>
<email> denglingli@chinamobile.com</email>
</address>
</author>
<author fullname="Yan Zhang" initials='Y.'
surname="Zhang">
<organization>Chinese Academy of Sciences</organization>
<address>
<email>zhangy@hpnl.ac.cn </email>
</address>
</author>
<date day="4" month="July" year="2013" />
<!-- Meta-data Declarations -->
<area></area>
<workgroup>Application-Layer Traffic Optimization Group</workgroup>
<keyword></keyword>
<abstract>
<t> 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.
</t>
<t>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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>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.</t>
<t>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.</t>
<t>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. </t>
</section>
<section title="Motivation">
<t> 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. </t>
<t>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%.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t> </t>
</section>
<section title=" Architecture">
<section title=" T-Cache for Wired subscribers">
<t>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.</t>
<figure align="center" anchor="figure_1" title="Architecture of T-cache at interworking gateway">
<artwork align="left">
<![CDATA[
+--------------+ +------+
| ISP 1 network+----------------+Peer 1|
+-----+--------+ +------+
|
+--------+------------------------------------------------------+
| ISP 2 network |
| +----------------+ +----------+ |
| |Interworking GW |----------------| T-Cache | |
| +-----+----------+ +----------+ |
| | |
+--------+------------------------------------------------------+
+---------------------------+
| |
+-----+-+ +--+---+
|Peer 2 | |Peer 3|
+-------+ +------+
]]>
</artwork>
<postamble></postamble>
</figure>
</section>
<section title=" B-Cache for WLAN subscribers">
<t>Fig. 2 illustrates the proposed architecture of a bidirectional cache (or B-Cache for short) 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 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. </t>
<figure align="center" anchor="figure_2" title="Architecture of B-cache in WLAN">
<artwork align="left">
<![CDATA[
+--------------+ +------+
| ISP 1 network+----------------+Peer 1|
+-----+--------+ +------+
|
+--------+------------------------------------------------------+
| | ISP 2 network |
| +----------------+ +----------+ |
| |Interworking GW |----------------| T-Cache | |
| +-----+----------+ +----------+ |
| | |
| | |
| +-----+------+ +---------+ |
| | AC +----------------+ B-Cache | |
| +-----+------+ +---------+ |
| | |
| +-------------------------------+ |
| +----+------+ +-----+-----+ |
| | AP_1 | . . . . | AP_n | |
| +----+------+ +-----+-----+ |
| | | |
+--------+-------------------------------+----------------------+
| |
+--+----------+ |
| | |
+--+--+ +--+--+ +--+--+
|Peer2| |Peer3| |Peer4|
+-----+ +-----+ +-----+
]]>
</artwork>
<postamble></postamble>
</figure>
</section>
<section title="Generalized cache architecture for intra-ISP networks">
<t>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 T-Cache or a B-Cache.</t>
<figure align="center" anchor="figure_3" title="Generalized Architecture of intra-ISP Caches">
<artwork align="left">
<![CDATA[
+--------------+ +------+
| 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|
+-----+ +-----+ +-----+ +-----+ +-----+
]]>
</artwork>
<postamble></postamble>
</figure>
</section>
</section>
<section title=" Considerations for ALTO deployment with P2P Caches">
<t>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. </t>
<t>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. </t>
<section title=" T-Cache: vertical separator from outsiders">
<t> 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.</t>
</section>
<section title="B-Cache: horizontal division within insiders">
<t>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.</t>
</section>
</section>
<section title=" Further Discussions">
<section title="5.1. Selective caching">
<t>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.</t>
</section>
</section>
<section title="Security Considerations">
<t>TBA</t>
</section>
<section title="IANA Considerations">
<t>None.</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC2234;
</references>
<references title="Informative References">
<!-- A reference written by by an organization not a person. -->
<reference anchor="I-D.ietf-alto-protocol">
<front>
<title>ALTO Protocol</title>
<author initials="R." surname="Alimi">
<organization></organization>
</author>
<author initials="R." surname="Penno">
<organization></organization>
</author>
<author initials="Y." surname="Yang">
<organization></organization>
</author>
<date month="September" year="2012" />
</front>
<seriesInfo name="draft-ietf-alto-protocol-13" value="(work in progress)" />
</reference>
<reference anchor="I-D.ietf-alto-deployments">
<front>
<title>ALTO Deployment Considerations</title>
<author initials="M." surname="Stimerling">
<organization></organization>
</author>
<author initials="S." surname="Kiesel">
<organization></organization>
</author>
<author initials="S." surname="Previdi">
<organization></organization>
</author>
<date month="February" year="2013" />
</front>
<seriesInfo name="draft-ietf-alto-deployments-06 " value="(work in progress)" />
</reference>
</references>
</back>
<!-- Here we use entities that we defined at the beginning. -->
<!-- Change Log
v00 2006-03-15 EBD Initial version
v01 2006-04-03 EBD Moved PI location back to position 1 -
v3.1 of XMLmind is better with them at this location.
v02 2007-03-07 AH removed extraneous nested_list attribute,
other minor corrections
v03 2007-03-09 EBD Added comments on null IANA sections and fixed heading capitalization.
Modified comments around figure to reflect non-implementation of
figure indent control. Put in reference using anchor="DOMINATION".
Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH Major changes: shortened discussion of PIs,
added discussion of rfc include.
v05 2007-03-10 EBD Added preamble to C program example to tell about ABNF and alternative
images. Removed meta-characters from comments (causes problems). -->
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:43:36 |