idnits 2.17.1 draft-deng-alto-p2pcache-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 13, 2014) is 3724 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 433, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 436, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) == Outdated reference: A later version (-07) exists of draft-deng-alto-p2p-ext-00 == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-08 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-25 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO L. Deng 3 Internet-Draft W. Chen 4 Intended status: Informational Q. Yi 5 Expires: August 17, 2014 China Mobile 6 Y. Zhang 7 Chinese Academy of Sciences 8 February 13, 2014 10 Considerations for ALTO with network-deployed P2P caches 11 draft-deng-alto-p2pcache-03.txt 13 Abstract 15 Uploading from peers located in a public WLAN hotspot has been 16 reported to severely impact other current users' experiences, and 17 raised caution from the operator's side who are willing to 18 increasingly participate in building public WLAN facilities to 19 offload the explosive mobile data traffic from cellular networks. 20 Cooperation between the network operator and the P2P service 21 providers in form of intra-domain P2P caches is expected to be an 22 effective mechanism to solve the problem. This draft introduces 23 considerations on ALTO deployment in terms of P2P caches and 24 discusses potential extensions to the ALTO protocol to standardize 25 this mutual cooperation. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 17, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. Forwarding Cache for Wired subscribers . . . . . . . . . 5 66 4.2. Bidirectional Cache for WLAN subscribers . . . . . . . . 6 67 4.3. Generalized cache architecture for intra-ISP networks . . 7 68 5. Considerations for ALTO deployment with P2P Caches . . . . . 8 69 5.1. Forwarding Cache: vertical separator from outsiders . . . 9 70 5.2. Bidirectional Cache: horizontal division within insiders 9 71 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Question: selective caching . . . . . . . . . . . . . . . 9 73 6.2. Discussion: cooperative caching and ALTO extension . . . 10 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 9.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 P2P applications like file sharing and multimedia streaming are so 84 popular that lots of P2P technologies have been increasingly utilized 85 throughout the world. The goal of Application-Layer Traffic 86 Optimization (ALTO) [I-D.ietf-alto-protocol] is to provide guidance 87 to these applications, which have to select one or several hosts from 88 a set of candidates that are able to provide a desired resource. 90 Meanwhile, since wireless accesses to Internet have become pervasive 91 with widely deployed WLANs, more and more people access Internet 92 services via WLAN and the amount of P2P traffic in WLAN is 93 explosively growing. In addition to a huge number of individually 94 setup WLANs at homes, there has been an increasing trend for the 95 government, organizations, and even traditional network operators to 96 set up publicly accessible WLAN facilities. Even though the service 97 may be free of charge, to use the resources effectively in a fair 98 way, and to avoid congestion for the purpose of service availability 99 are vital for these public WLANs. 101 However, recent statistics reveal that P2P traffic accounts for 80% 102 in part of China Mobile's WLANs, and traffic congestion at APs 103 (access points) frequently occurs because of P2P applications. P2P 104 traffic in WLANs not only causes problems on their own delivery 105 quality, but also degrades the performance of other Internet 106 applications in WLANs. 108 2. Terminology 110 ALTO: application layer traffic optimization. For ALTO protocol, 111 please refer to [I-D.ietf-alto-protocol]. 113 AP: a wireless access point (or WAP) is a device that allows wireless 114 devices to connect to a wired network using WLAN. The AP usually 115 connects to a AC as a standalone device, but it can also be an 116 integral component of the router itself. 118 AC: a wireless access controller (or WAC) is the network entity that 119 provides wire access via APs to the network infrastructure in the 120 data plane, control plane, management plane, or a combination 121 therein. 123 DCP: Distributed coordination function (or DCF) is the fundamental 124 MAC technique of the IEEE 802.11 based WLAN standard. DCF employs a 125 CSMA/CA with binary exponential backoff algorithm. 127 Forwarding Cache: is a traditional content cache, which caches 128 content flows from outside its coverage and serves subsequent 129 requestors under its coverage for the content. 131 Reverse Cache: is a special content cache proposed for WLAN peers, 132 which caches content flows from inside its coverage and serves 133 subsequent requestor from outside its coverage for the content on 134 behalf of the peers within its coverage. 136 Bidirectional Cache: is a combination of a forwarding cache and a 137 reverse cache. 139 Transparent Cache: is a content cache deployed by network operators 140 for third party SPs (e.g. P2P streaming services), which participates 141 in the overlay's service provision implicitly via request 142 redirection. 144 Cooperative Cache: is a content cache deployed by network operators 145 in cooperation with specific content delivering SPs (e.g. P2P 146 streaming services), which participates in the overlay's service 147 provision explicitly. 149 3. Motivation 151 On one hand, it is well accepted that compared to fixed networks, 152 mobile networks have some special characters, including small link 153 bandwidth, high cost, limited radio frequency resource, and terminal 154 battery. Therefore, it is recommended by [I-D.ietf-alto-deployments] 155 that in mobile network, the usage of wireless link should be 156 decreased as far as possible and be high-efficient. For example, in 157 the case of a P2P service, the clients in the fixed network should 158 decrease the data transport from the clients in the mobile networks, 159 as well as the clients in the mobile networks should prefer the data 160 transmission from the clients in the fixed networks. 162 On the other hand, efforts have been put on using forwarding caches 163 to optimize traffic pattern in such scenarios, which demonstrates 164 great improvement in user experience and considerable traffic 165 reduction at interworking points. What's more, owing to the 166 characteristics of the DCF model in 802.11, there is an constant 167 unfairness between uplink and downlink traffic in competing wireless 168 channel resources, which leads to downlink congestion in WLAN 169 resultant from P2P traffic (which constitutes the major part of 170 uploading traffic). In particular, There is basic indication under 171 the current DCF model, that in order to achieve fairness among mobile 172 stations, in the long run, each stations has a equal chance of 173 getting the wireless slot given they all have a sustainable long 174 traffic to send. In other words, there is an implicit unfairness 175 between uplink and downlink traffic under the BSS model, where the AP 176 holds the throat of all the downlink traffic and competing with the 177 uplink traffic from potentially a large group of other user mobile 178 devices. However, traditional P2P cache (as a forward cache) cannot 179 help here, since it does nothing to stop a WLAN peer from uploading. 180 Hence, bidirectional caches are proposed, which contains a reverse 181 cache as well as a forward cache can be deployed at the AC (Access 182 Controller). The reverse cache can provide uploading service instead 183 of the WLAN peers under the AC's coverage. As a result, the uplink 184 bandwidth consumption at each AP can be reduced and the uplink 185 congestion can be alleviated effectively. Simulation results in 186 file-sharing scenarios show that, employing cache instead of WLAN 187 peers accelerates file transfer by 42% while improving the throughput 188 of other Internet applications under the same AP by 28%. 190 With deployed P2P caches on the internal network, especially at a 191 position as low as the AC-level, it could be sub-optimal to simply 192 use the accessing network type as the divider for different PIDs and 193 assign sufficient high cost within the wireless PID to prefer 194 accessing remote peers over local peers blindly. 196 To this end, this draft discusses the optimal ALTO deployment 197 recommendations for a P2P application in terms of a wireless 198 accessing network with network-deployed application-agnostic caches. 200 In summary, the goal here is to illuminate applications through ALTO 201 about these existing network capabilities to make full use of them in 202 achieving application performance improvement and network cost 203 reduction. 205 4. Architecture 207 4.1. Forwarding Cache for Wired subscribers 209 Fig. 1 illustrates the proposed architecture of a traditional uni- 210 directional P2P cache (or Forwarding Cache for short) system for 211 wired subscribers, deployed mainly for the purpose of reducing 212 interworking P2P traffic. Forwarding Caches are assumed to be 213 deployed at the interworking gateways to maximize their coverage for 214 local subscribers. In transparent mode, they buffer downloading 215 content from outside ISP networks, intercept the upcoming outgoing 216 P2P requests from local subscribers and serve them with cached 217 content instead. In cooperative mode, they register to the tracker 218 as a super peer and are under the regulation of the tracker's private 219 protocol. 221 +--------------+ +------+ 222 | ISP 1 network+----------------+Peer 1| 223 +-----+--------+ +------+ 224 | 225 +--------+------------------------------------------------------+ 226 | ISP 2 network | 227 | +----------------+ +------------------+ | 228 | |Interworking GW |----------------| Forwarding Cache | | 229 | +-----+----------+ +------------------+ | 230 | | | 231 +--------+------------------------------------------------------+ 232 +---------------------------+ 233 | | 234 +-----+-+ +--+---+ 235 |Peer 2 | |Peer 3| 236 +-------+ +------+ 238 Figure 1: Architecture of Forwarding Cache at interworking gateway 240 4.2. Bidirectional Cache for WLAN subscribers 242 Fig. 2 illustrates the proposed architecture of a bidirectional cache 243 system in WLAN. In a WLAN, all AP will connect to a device named AC, 244 and the AC can be seen as the gateway to Internet of the WLAN. For 245 most settings, both the traffic flowing into the WLAN and the traffic 246 flowing out of the WLAN pass through the AC, hence Bidirectional 247 Caches are assumed to be deployed at AC to exploit the traffic 248 locality. Besides the normal functions of a Forwarding Cache, A 249 Bidirectional Cache in transparent mode buffers uploading content 250 from inside the WLAN network, intercepts the upcoming outgoing P2P 251 responses from local WLAN subscribers and serve the correspondent 252 requester (be it another local WLAN subscriber or an outsider) with 253 cached content instead. In cooperative mode, they register to the 254 tracker as a super peer and are under the regulation of the tracker's 255 private protocol. 257 +--------------+ +------+ 258 | ISP 1 network+----------------+Peer 1| 259 +-----+--------+ +------+ 260 | 261 +--------+------------------------------------------------------+ 262 | | ISP 2 network | 263 | +----------------+ +------------------+ | 264 | |Interworking GW |----------------| Forwarding Cache | | 265 | +-----+----------+ +------------------+ | 266 | | | 267 | | | 268 | +-----+------+ +---------------------+ | 269 | | AC +----------------+ Bidirectional Cache | | 270 | +-----+------+ +---------------------+ | 271 | | | 272 | +-------------------------------+ | 273 | +----+------+ +-----+-----+ | 274 | | AP_1 | . . . . | AP_n | | 275 | +----+------+ +-----+-----+ | 276 | | | | 277 +--------+-------------------------------+----------------------+ 278 | | 279 +--+----------+ | 280 | | | 281 +--+--+ +--+--+ +--+--+ 282 |Peer2| |Peer3| |Peer4| 283 +-----+ +-----+ +-----+ 285 Figure 2: Architecture of Bidirectional Cache in WLAN 287 4.3. Generalized cache architecture for intra-ISP networks 289 Fig. 3 generalized the overall architecture of the potential P2P 290 cache deployments inside an ISP with various access network types. 291 As it shows, P2P caches may be deployed at various levels, including: 292 the interworking gateway linking with other ISPs, internal access 293 network gateways linking with different types of accessing networks 294 (e.g. WLAN, cellular and wired), and even within an accessing network 295 at the entries of individual WLAN sub-networks. Moreover, depending 296 on the network context and the operator's policy, each cache can be a 297 Forwarding Cache or a Bidirectional Cache. 299 +--------------+ +------+ 300 | ISP 1 network+----------------+Peer 1| 301 +-----+--------+ +------+ 302 | 303 +--------+------------------------------------------------------+ 304 | | ISP 2 network | 305 | +---------+ | 306 | |L1 Cache | | 307 | +-----+---+ | 308 | +--------------------+----------------------+ | 309 | | | | | 310 | +------+------+ +------+-------+ +------+-------+ | 311 | | AN1 | | AN2 | | AN3 | | 312 | | +---------+ | | +----------+ | | | | 313 | | |L2 Cache | | | |L2 Cache | | | | | 314 | | +---------+ | | +----------+ | | | | 315 | +------+------+ +------+-------+ +------+-------+ | 316 | | | | 317 | +--------------------+ | | 318 | | | | | 319 | +------+------+ +------+-------+ +------+-------+ | 320 | | SUB-AN11 | | SUB-AN12 | | SUB-AN31 | | 321 | | +---------+ | | | | | | 322 | | |L3 Cache | | | | | | | 323 | | +---------+ | | | | | | 324 | +------+------+ +------+-------+ +------+-------+ | 325 | | | | | 326 +--------+--------------------+----------------------+----------+ 327 | | | 328 +---+---+ +---+---+ | 329 | | | | | 330 +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ 331 |Peer2| |Peer3| |Peer4| |Peer5| |Peer6| 332 +-----+ +-----+ +-----+ +-----+ +-----+ 334 Figure 3: Generalized Architecture of intra-ISP Caches 336 5. Considerations for ALTO deployment with P2P Caches 338 For wired network operator, forwarding caching effectively localizes 339 the downloading P2P traffic within the sub-net under its coverage 340 resulting in reduction of network cost for cross-boundary peer 341 selection, whereas reverse caching blocks the uploading traffic 342 outside a wireless sub-net leading to elimination of network cost for 343 wireless uploading peer selection. In other words, caching between 344 pairs of endpoints changes the traffic cost along the way. 346 Therefore, it is expected that by cooperation between the network 347 operator and the P2P SP in building up various caching system and 348 sharing information through ALTO protocol about these facilities 349 brings benefits to both party. 351 In order to do that, it is proposed to use locations of caches as 352 dividers of different PIDs to guide intra-ISP network abstraction and 353 mark costs among them according to the location and type of relevant 354 caches. Otherwise, if we stick to using network types as dividers 355 for PIDs, there is no chance that a cost map would ever grasp this 356 kind of information about node pairs within the same PID. 358 5.1. Forwarding Cache: vertical separator from outsiders 360 It is reasonable to use Forwarding Caches as separators for different 361 PIDs, since it accelerates P2P traffic in a particular direction, 362 indicating varied costs among these adjacent partitions. For 363 instance as shown in Fig.3, assuming the L2 Cache in AN1 of ISP 2 364 network is a Forwarding Cache, the downloading traffic from other 365 peers outside to AN1 but within the same ISP2 can be buffered once 366 and served AN1 network subsequently. The cost from AN2 or AN3 to AN1 367 is reduced as result, but not vise visa. In other words, the ISP 2 368 network should be sub-divided into {AN1} and {AN2, AN3}, and the 369 incoming P2P cost for {AN1} is reduced, for the sake of the L2 370 Forwarding Cache located at the entry of AN1. 372 5.2. Bidirectional Cache: horizontal division within insiders 374 Since Bidirectional Cache are deployed in wireless accessing networks 375 to further reduce the outgoing and local-in-local-out traffic costs 376 in both directions, it seems straightforward to join the adjacent 377 partitions together and modify the cost between insiders to zero. 378 However, there is hidden layering within the Bidirectional Cache 379 coverage, as the blocking of uploading traffic only works for traffic 380 traverse pass the Bidirectional Cache. If the cache is located too 381 high as to be outside a local routing subnet, the local traffic flows 382 within the subnet cannot benefit from the Bidirectional Cache. 384 6. Open issues 386 6.1. Question: selective caching 388 As there is both CAPEX and OPEX expenditures for dedicated P2P Cache 389 devices, it may be cost-efficient for caches to make buffering/ 390 serving decisions based on the popularity of the specific content. 391 How to expose this application-relevant information to ALTO under 392 such context is an open issue. 394 6.2. Discussion: cooperative caching and ALTO extension 396 Luckily, in the cooperative-mode, a cache is playing as a normal peer 397 under the tracker, and the latter can make the "right" decision in 398 choosing in favor of the former under the guidance of the ALTO 399 response while the tracker itself would take care of the content 400 availability problem. If the cache doesn't have the content in 401 question, it would no appear in the peer list handed in to ALTO 402 server by the tracker. 404 In this case, the ALTO server can collect the information about 405 caching sub-system in the network, identify those "caching" peers in 406 the peer list of an cost request from an ALTO client, and arrange the 407 returned rank list accordingly. For example, a simple candidate- 408 ranking policy for a cost query to a WLAN peer, could be caching 409 peers at the beginning, then inside wired peers, and lastly outside 410 wired peers. 412 Moreover, the P2P SP and WLAN network operator may benefit even more 413 by group popular files according to peers' geographic location or 414 access types, and adapt its internal caching scheduling decisions 415 about which files to be cached on which spot. In order to do that, 416 it would be helpful that the ALTO server could provide to the client 417 with the requesting peer's subscription types (i.e. wired/WLAN/ 418 cellular/...) as well as geographic locations. Specific definitions 419 are specified separately in [I-D.draft-deng-alto-p2p-ext] 421 7. Security Considerations 423 TBA 425 8. IANA Considerations 427 None. 429 9. References 431 9.1. Normative References 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, March 1997. 436 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 437 Specifications: ABNF", RFC 2234, November 1997. 439 9.2. Informative References 441 [I-D.draft-deng-alto-p2p-ext] 442 Deng, L. and H. Song, "End Point Properties for Peer 443 Selection", draft-deng-alto-p2p-ext-00 (work in progress), 444 February 2014. 446 [I-D.ietf-alto-deployments] 447 Stimerling, M., Kiesel, S., Previdi, S., and M. Scharf, 448 "ALTO Deployment Considerations", draft-ietf-alto- 449 deployments-08 (work in progress), October 2013. 451 [I-D.ietf-alto-protocol] 452 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- 453 ietf-alto-protocol-25 (work in progress), January 2014. 455 Authors' Addresses 457 Lingli Deng 458 China Mobile 460 Email: denglingli@chinamobile.com 462 Wei Chen 463 China Mobile 465 Email: chenwei@chinamobile.com 467 Qiuchao Yi 468 China Mobile 470 Email: yiqiuchao@chinamobile.com 472 Yan Zhang 473 Chinese Academy of Sciences 475 Email: zhangy@hpnl.ac.cn