idnits 2.17.1 draft-madhavan-alto-caching-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 21 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 1, 2013) is 4102 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TODO' is mentioned on line 321, but not defined == Unused Reference: 'RFC2119' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-deployments' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-alto-reqs' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'I-D.seedorf-i2aex-alto-cdni-perpective' is defined on line 378, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-alto-deployments-04 == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-11 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Madhavan 3 Internet-Draft R. Nandiraju 4 Intended status: Informational Huawei Technologies 5 Expires: August 1, 2013 February 1, 2013 7 ALTO Caching 8 draft-madhavan-alto-caching-01 10 Abstract 12 The specification of the ALTO protocol uses map based approaches 13 assuming that the information provided is static for a longer period 14 of time. The purpose of this memo is to provide a mechanism where 15 ALTO clients cache the map information and the servers provide the 16 expiration time for invalidation. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on February 2, 2013. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Protocol Structure . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. ALTO Types . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 6.1. EndpointAddrGroup . . . . . . . . . . . . . . . . . . . . 5 59 6.2. NetworkMapData . . . . . . . . . . . . . . . . . . . . . . 5 60 7. ALTO caching and Consistency . . . . . . . . . . . . . . . . . 5 61 7.1. Server behavior . . . . . . . . . . . . . . . . . . . . . 5 62 7.2. Client behavior . . . . . . . . . . . . . . . . . . . . . 6 63 7.3. Cache Consistency Approaches . . . . . . . . . . . . . . . 6 64 7.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.4.1. Network Map with Expiry Example . . . . . . . . . . . 8 66 7.4.2. Filtered Network Map with Expiry Example . . . . . . . 9 67 8. Transport Considerations . . . . . . . . . . . . . . . . . . . 9 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 11.2. Informative References . . . . . . . . . . . . . . . . . . 10 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 The goal of Application-Layer Traffic Optimization (ALTO) is to 78 provide guidance to applications, which have to select one or several 79 hosts from a set of candidates, that are able to provide a desired 80 resource [RFC5693]. The requirements for ALTO are itemized in 81 I-D.ietf-alto-reqs. ALTO is realized by a client-server 82 protocol.ALTO clients send queries to ALTO servers, in order to 83 solicit guidance. 85 This memo defines a mechanism for ALTO clients to cache the map 86 information and for the servers to provide the expiration time for 87 invalidation at subset level or map level. 89 2. Problem Statement 91 The ALTO protocol uses HTTP for discovering available Information 92 resources at an ALTO server and retrieving information resources. 93 The protocol defines Map-based and Non-map based approaches for 94 retrieving information resources.Map-based approaches are chosen as 95 they lower the signaling load on the server, as the maps have only to 96 be retrieved if they are changed. 98 HTTP protocol already defines mechanisms for caching the content. 99 There are many limitations in using those mechanisms. HTTP based 100 caches store the responses only for HTTP GET requests. ALTO queries 101 can be GET or POST(in case of filtered map) requests. In the case of 102 POST requests, HTTP caching mechanism cannot be used because 103 responses for POST are generally not cached. 105 The validity of the information in the map need not be same for all 106 the elements in the map and there is currently no mechanism(in HTTP 107 also) to convey this information. This mechanism has to be 108 incorporated into the protocol itself. 110 3. Protocol Structure 112 The ALTO Protocol uses a simple extensible framework to convey 113 network information. In the general framework, the ALTO protocol 114 will convey properties on both Network Locations and the paths 115 between Network Locations.[I-D.ietf-alto-protocol]. 117 The Map filtering and endpoint property services can be extended to 118 include the map level and subset level expiration time. 120 .--------------------------------------------------------. 121 | | 122 |.--------..--------------------------------------------.| 123 || || ALTO Info Services || 124 || || .-----------. .----------. .----------. || 125 || || | Map | | Endpoint | | Endpoint | || 126 || || | Filtering | | Property | | Cost | || 127 || || | | | | | | || 128 || || | | | | | | || 129 || || | Service | | Service | | Service | || 130 || Server || `-----------' `----------' `----------' || 131 || Info. || .-------------------------------------. || 132 || Service|| | Map Service | || 133 || || | .-------------. .--------------. | || 134 || || | | Network Map | | Cost Map | | || 135 || || | `-------------' `--------------' | || 136 || || `-------------------------------------' || 137 |`--------'`--------------------------------------------'| 138 | | 139 `--------------------------------------------------------' 141 Figure 1: ALTO Protocol Structure 143 4. Overall Operation 145 The overall operation is based on the ALTO client caching the map 146 information. The ALTO server sends the map information providing 147 details of full or subset level expiration. 149 ALTO server can choose to use HTTP based caching mechanisms or ALTO 150 caching mechanism (defined in this document) based on the request. 152 A typical message flow would be: 154 ALTO Client ALTO Server 155 |-----ALTO Query--->| ALTO Query for complete map information 156 |<---ALTO Response--| ALTO Response with caching related information 157 | | 158 Subset level |------ALTO Query-->| ALTO Query for expired maps 159 validity expires |<-------200--------| ALTO response 160 | | 162 Figure 2: Message flow 164 5. Definitions 166 ALTO cache: Any logical entity which caches the ALTO responses for 167 the purpose of reducing repeated requests by the alto client to the 168 alto server. The ALTO cache MAY be co-located with the ALTO client 169 or it can be a separate node 171 6. ALTO Types 173 This section details the format for particular data values used for 174 ALTO caching framework. Base types defined by I-D.ietf-alto-protocol 175 are used by this memo with some extensions listed below. 177 6.1. EndpointAddrGroup 179 EndpointAddrGroup JSON object is extended as below 181 object { 182 JSONString expires; 183 EndpointPrefix [AddressType]<0..*>; 184 ... 185 } EndpointAddrGroup; 187 6.2. NetworkMapData 189 NetworkMapData JSON object is extended as below 191 object { 192 JSONString expires; 193 EndpointAddrGroup [pidname]<0..*>; 194 ... 195 } NetworkMapData; 197 7. ALTO caching and Consistency 199 ALTO servers specify the expiration time of the complete map or the 200 subset level maps in the response. Expiration time format is an 201 absolute date and time with GMT as reference. ISPs MAY use any 202 mechanism to determine the expiration time. This is out of the scope 203 of this specification. 205 7.1. Server behavior 207 ALTO server MAY use HTTP based or ALTO caching mechanism to convey 208 the expiration time. When the request is HTTP GET,then the ALTO 209 server MAY use HTTP based caching mechanism. In the case of request 210 being POST, ALTO server SHOULD use ALTO caching mechanism. To ensure 211 consistent behaviour and reduce implementation complexity it is 212 recommended that the mechanism defined by this memo is used for all 213 caching scenarios. 215 7.2. Client behavior 217 ALTO cache MUST be able to identify expiration of map level or subset 218 level information. On expiry, cache SHOULD trigger a new request to 219 the server to refresh the expiration. 221 7.3. Cache Consistency Approaches 223 ALTO caches are useful when cache consistency is maintained,that is, 224 cached copies should be updated when the originals change.There are 225 two different types of consistency approaches - weak consistency and 226 strong consistency. Weak consistency is an approach in which stale 227 documents may be returned to user , while the latter approach ensures 228 that stale documents are never returned to user. 230 ALTO caches SHOULD have strong invalidation mechanisms. In the case 231 of P2P, the stale data can result in the unoptimized peer selection 232 and resulting in selecting the longest PATH which will defeat the 233 purpose of ALTO. In the case of cdni(see [I-D.seedorf-i2aex-alto- 234 cdni-perpective] for details)) there can be service failures as 235 requests are redirected to wrong/invalid dCDN. 237 The below table shows comparison of different validation approaches. 238 Assume that interleave of requests and file modifications happens in 239 the order RRRMMMRRMRRRMMRM.Let R be the number of times a node views 240 a resource and RI be the number of intervals during which client 241 repeatedly asks for resource while resource is changed. It is 242 evident that notification based mechanisms takes few control messages 243 and ensures that there is no stale data returned. 245 The mechanism of notification is proposed in 246 [draft-madhavan-alto-subscription] 247 +-------------------+-----------+--------------+--------------------+ 248 | Messages | Polling | Notification | TTL based approach | 249 | | everytime | approach | | 250 | | approach | | | 251 +-------------------+-----------+--------------+--------------------+ 252 | GET requests | 1 | 1 | 1 | 253 | If-Modified-Since | R-1 | 0 | TTLmissed - 1 | 254 | 304 response | R-RI | 0 | TTLmissed - | 255 | | | | TTLmissedreschange | 256 | Notification Msg | 0 | 1 Sub + RI * | 0 | 257 | | | Not | | 258 | File Transfers | RI | RI | RI - | 259 | | | | Stalehitintervals | 260 | Stale document | No | No | Yes | 261 +-------------------+-----------+--------------+--------------------+ 263 Message contents for consistency approaches 265 Table 1: Cache consistency tradeoff 267 7.4. Examples 268 7.4.1. Network Map with Expiry Example 270 GET /networkmap HTTP/1.1 271 Host: alto.example.com 272 Accept: application/alto-networkmap+json,application/alto-error+json 274 HTTP/1.1 200 OK 275 Content-Length: [TODO] 276 Content-Type: application/alto-networkmap+json 277 Cache-Control: no-cache 279 { 280 "meta" : {}, 281 "data" : { 282 "map-vtag" : "1266506139", 283 "map" : { 284 "expires": "Wed, 14 Sep 2011 16:00:00 GMT", 285 "PID1" : { 286 "ipv4" : [ 287 "192.0.2.0/24", 288 "198.51.100.0/25" 289 ] 290 }, 291 "PID2" : { 292 "ipv4" : [ 293 "198.51.100.128/25" 294 ] 295 }, 296 "PID3" : { 297 "ipv4" : [ 298 "0.0.0.0/0" 299 ], 300 "ipv6" : [ 301 "::/0" 302 ] 303 } 304 } 305 } 306 } 308 7.4.2. Filtered Network Map with Expiry Example 310 POST /networkmap/filtered HTTP/1.1 311 Host: custom.alto.example.com 312 Content-Length: [TODO] 313 Content-Type: application/alto-networkmapfilter+json 314 Accept: application/alto-networkmap+json,application/alto-error+json 316 { 317 "pids": [ "PID1", "PID2" ] 318 } 320 HTTP/1.1 200 OK 321 Content-Length: [TODO] 322 Content-Type: application/alto-networkmap+json 324 { 325 "meta" : {}, 326 "data" : { 327 "map-vtag" : "1266506139", 328 "map" : { 329 "PID1" : { 330 "expires": "Wed, 14 Sep 2011 16:00:00 GMT", 331 "ipv4" : [ 332 "192.0.2.0/24", 333 "198.51.100.0/24" 334 ] 335 }, 336 "PID2" : { 337 "expires": "Wed, 14 Dec 2011 16:00:00 GMT", 338 "ipv4": [ 339 "198.51.100.128/24" 340 ] 341 } 342 } 343 } 344 } 346 8. Transport Considerations 348 9. Acknowledgements 349 10. Security Considerations 351 TBD 353 11. References 355 11.1. Normative References 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 11.2. Informative References 362 [I-D.ietf-alto-deployments] 363 Stiemerling, M., Kiesel, S., and S. Previdi, "ALTO 364 Deployment Considerations", draft-ietf-alto-deployments-04 365 (work in progress), March 2012. 367 [I-D.ietf-alto-protocol] 368 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 369 draft-ietf-alto-protocol-11 (work in progress), 370 March 2012. 372 [I-D.ietf-alto-reqs] 373 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 374 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 375 Requirements", draft-ietf-alto-reqs-16 (work in progress), 376 June 2012. 378 [I-D.seedorf-i2aex-alto-cdni-perpective] 379 Seedorf, J., "Infrastructure-to-application information 380 exposure from an ALTO-CDNI Perspective", 381 draft-seedorf-i2aex-alto-cdni-perpective-00 (work in 382 progress), March 2012. 384 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 385 Optimization (ALTO) Problem Statement", RFC 5693, 386 October 2009. 388 Authors' Addresses 390 Sreekanth Madhavan 391 Huawei Technologies 392 Bangalore, 393 India 395 Phone: 396 Email: sreekanth.madhavan@huawei.com 398 Nandiraju Ravishankar 399 Huawei Technologies 400 Bangalore, 401 India 403 Phone: 404 Email: ravi.nandiraju@huawei.com