idnits 2.17.1 draft-schwan-alto-incr-updates-00.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 199: '...uest, the server SHOULD reply with a 3...' RFC 2119 keyword, line 250: '... Map the server MAY choose not to sen...' RFC 2119 keyword, line 427: '...cost map. Thus the response MUST have...' RFC 2119 keyword, line 428: '... specified version, but MAY have other...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 306 has weird spacing: '...ostMode cos...' == Line 307 has weird spacing: '...ostType cos...' == Line 308 has weird spacing: '...sionTag map-v...' == Line 309 has weird spacing: '...sionTag cost-...' == Line 310 has weird spacing: '...NNumber updat...' -- The document date (December 1, 2011) is 4520 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TODO' is mentioned on line 397, but not defined == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-10 == Outdated reference: A later version (-03) exists of draft-jenkins-alto-cdn-use-cases-01 ** Downref: Normative reference to an Informational draft: draft-jenkins-alto-cdn-use-cases (ref. 'I-D.jenkins-alto-cdn-use-cases') == Outdated reference: A later version (-04) exists of draft-pbryan-json-patch-02 ** Downref: Normative reference to an Informational draft: draft-pbryan-json-patch (ref. 'I-D.pbryan-json-patch') ** Downref: Normative reference to an Informational draft: draft-pbryan-zyp-json-pointer (ref. 'I-D.pbryan-zyp-json-pointer') ** Downref: Normative reference to an Informational RFC: RFC 5693 Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO N. Schwan 3 Internet-Draft B. Roome 4 Intended status: Standards Track Alcatel-Lucent Bell Labs 5 Expires: June 3, 2012 December 1, 2011 7 ALTO Incremental Updates 8 draft-schwan-alto-incr-updates-00 10 Abstract 12 The goal of Application-Layer Traffic Optimization (ALTO) is to 13 bridge the gap between network and applications by provisioning 14 network related information. This allows applications to make 15 informed decisions, for example when selecting a target host from a 16 set of candidates. 18 Therefore an ALTO server provides network and cost maps to its 19 clients. This draft discusses options on how to provide incremental 20 updates for these maps, with the goal of reducing the amount of data 21 needed for transmitting the maps. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 3, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Determine Client Map Version . . . . . . . . . . . . . . . . . 6 60 3.1. If-Modified-Since HTTP Header . . . . . . . . . . . . . . 6 61 3.2. Version-based incremental updates . . . . . . . . . . . . 7 62 3.2.1. CURRENT NETWORK MAP vtag . . . . . . . . . . . . . . . 8 63 3.2.2. Extensions to full cost-map response: . . . . . . . . 8 64 4. Incremental Update Options . . . . . . . . . . . . . . . . . . 10 65 4.1. Send entire map . . . . . . . . . . . . . . . . . . . . . 10 66 4.2. Patch map . . . . . . . . . . . . . . . . . . . . . . . . 10 67 4.3. Encode map . . . . . . . . . . . . . . . . . . . . . . . . 10 68 4.4. JSON patch . . . . . . . . . . . . . . . . . . . . . . . . 10 69 4.5. Send only changed values . . . . . . . . . . . . . . . . . 11 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 77 1. Introduction 79 The goal of Application-Layer Traffic Optimization (ALTO) is to 80 bridge the gap between network and applications by provisioning 81 network related information. This allows applications to make 82 informed decisions, for example when selecting a target host from a 83 set of candidates. Typical applications are file sharing, real-time 84 communication and live streaming peer-to-peer networks [RFC5693] as 85 well as Content Distribution Networks 86 [I-D.jenkins-alto-cdn-use-cases]. 88 The ALTO protocol [I-D.ietf-alto-protocol] is specified as a client- 89 server protocol based on the HyperText Transfer Protocol (HTTP) and 90 encoded in JavaScript Object Notation (JSON). An ALTO server 91 provides services that guide ALTO clients in their decisions. The 92 Endpoint Property Service allows ALTO clients to look up properties 93 of endpoints, for example its Netwok Location. The Endpoint Cost 94 Service allows ALTO server to rank endpoints amongst each other with 95 respect to numerical or ordinal costs. The Map Service and the Map 96 Filtering Service allows ALTO client to retrieve full or partial 97 Network Maps and the associated Cost Maps that are provisioned by an 98 ALTO server. 100 The ALTO Network Map contains groupings of endpoints as defined by 101 the ALTO server. By aggregating multiple endpoints that are close to 102 one another with respect to their network connectivity a greater 103 scalability is achieved. Each group of endpoints is associated to a 104 Network Location identifier called a PID, for example by a list of IP 105 prefixes that belong to the PID. The ALTO Server then indicates 106 preferences amongst the PIDs in the Cost Map by defining Path Costs 107 amongst sets of Netwok Locations. 109 The size of the Network and Cost Maps depend on the granularity of 110 the map an ALTO server provides for its clients. While some use 111 cases allow operators to configure their servers to support only a 112 small numbers of PIDs, other use cases are expected to require a much 113 greater accuracy in terms of network locations. In order to avoid 114 the transmission of the same information in each client request, a 115 mechanism that allows a server to send incremental updates, in 116 particular for large Network and Cost Maps, is needed. 118 The goal of this draft is to list and discuss the different options 119 that allow such incremental updates of Network and Cost Maps. We 120 divide the discussion in two larger parts. The first part lists 121 options that allow a server to anticipate the map a client has 122 without the transmission of the whole map. The second part then 123 disusses the options a server has to send incremental updates. 125 Comments and discussions about this memo should be directed to the 126 ALTO working group: alto@ietf.org. 128 2. Problem Statement 130 The ALTO protocol uses Network and Cost Maps to allow ALTO servers 131 the specification of its own aggregated network view. Essentially 132 the Network Map contains information on how the endpoints are grouped 133 together, which is typically done according to their proximity. The 134 Cost Map contains Path Costs between the network regions defined in 135 the Network Map. The size of these maps strongly depends on the 136 scenario an ALTO server is configured for by its operator. While in 137 some scenarios both maps might only comprise s small number of PIDs, 138 others need much greater accuracy. For large maps partial updates 139 might become necessary. 141 Both map types have slightly different characteristics. Network Maps 142 in general are expected to be smaller than Cost Maps. As an example, 143 a Network Map with 5,000 PIDs, each having 10 cidrs will result in a 144 map with the size of roughly 1.25 megabytes. A Cost Map in contrast 145 contains a m*n matrix for cost entries. Even for short PID names a 146 full cost map for 5,000 PIDs takes up to 417 megabytes. Network Maps 147 are also seen to be less dynamic than Cost Maps. This is due to the 148 fact that the topology an ALTO server sees changes slower than the 149 path costs of the network. Another characteristic is that changes to 150 the Network Map will impact the Cost Map, whereas vice versa this is 151 presumably not the case. A final discussion on whether partial 152 updates are useful for both map types is out of the scope of this 153 document. 155 The remainder of this document discusses options to allow partial 156 updates of Network and Cost Maps. Therefore two sections focus on 157 two seperate problems that need a solution. The first part 158 (Section 3) discusses how an ALTO client and an ALTO server can 159 synchronize their map state without transmitting the whole map. This 160 is needed to identify whether a partial update can be applied and 161 also to calculate the partial update itself. The second part 162 (Section 4) of the document discusses how partial updates can be 163 encoded and sent to the client. 165 3. Determine Client Map Version 167 To allow a server sending incremental updates to a client it first 168 needs to know what version of the map a client already has. In this 169 section we discuss options that allow a server to do so without 170 having a client to send the whole map to the server. 172 3.1. If-Modified-Since HTTP Header 174 One possible option is to use the HTTP If-Modified-Since header in 175 the request if the client has previously contacted the ALTO service 176 and thus already has a version of the map. Therefore it caches both, 177 the map as well as the value of the Date header field of the HTTP 178 response that contained the map. A server can then use the value of 179 the If-Modified-Since header to compare if the clients current map is 180 still up-to-date. 182 The following figure illustrates a GET request for a Network Map 183 Information Resource. Additionally the client indicates the time 184 when it retrieved the Network Map the last time in the If-Modified- 185 Since header field. 187 GET /networkmap HTTP/1.1 188 Host: alto.example.com 189 Accept: application/alto-networkmap+json,application/alto-error+json 190 If-Modified-Since: Sat, 24 Dec 2011 19:43:31 GMT 192 Figure 1: If-Modified-Since HTTP Header 194 A server retrieving this request uses the timestamp provided by the 195 client to decide whether to send a full map, only partial updates of 196 the map or no map at all in case there were no changes. 198 In case the Network Map has not been modified since the time provided 199 by the client in the request, the server SHOULD reply with a 304 HTTP 200 response. The client can then cache the updated value of the Date 201 header field for future requests. 203 304 Not Modified 204 Date: Sun, 25 Dec 2011 09:33:31 GMT 206 Figure 2: HTTP Response 304 208 In case the server determines that the timestamp provided by the 209 client is out-of-date and cannot be reused for a partial update it 210 returns the full Network Map, as defined in the ALTO core protocol 211 specification. The following figure shows the mandatory Date header 212 field in the HTTP response that is used as a timestamp for the map. 214 HTTP/1.1 200 OK 215 Content-Length: [TODO] 216 Content-Type: application/alto-networkmap+json 217 Date: Sun, 25 Dec 2011 09:33:31 GMT 219 { 220 "meta" : {}, 221 "data" : { 222 "map-vtag" : "1266506139", 223 "map" : { 224 "PID1" : { 225 "ipv4" : [ 226 "192.0.2.0/24", 227 "198.51.100.0/25" 228 ] 229 }, 230 "PID2" : { 231 "ipv4" : [ 232 "198.51.100.128/25" 233 ] 234 }, 235 "PID3" : { 236 "ipv4" : [ 237 "0.0.0.0/0" 238 ], 239 "ipv6" : [ 240 "::/0" 241 ] 242 } 243 } 244 } 245 } 247 Figure 3: Full Network Map HTTP Response 249 In case the server determines that there was a change to the Network 250 Map the server MAY choose not to send the full map, but a partial 251 update only. Options for sending these partial updates are discussed 252 in Section 4. 254 3.2. Version-based incremental updates 256 With this approach, clients poll the ALTO server for changes. The 257 server provides hints as to the polling frequency. We propose two 258 different mechanisms in the ALTO message format, one for network-map 259 changes, the other for cost-map changes. 261 For network-map changes, add a new GET-mode request, "CURRENT NETWORK 262 MAP VTAG." The response is short and simple: just the current map- 263 vtag and a hint about how often the network-map might change. Once a 264 client has the full network map, the client periodically sends that 265 CURRENT VTAG request to the server. If the map-vtag changes, the 266 client re-gets the network map. For cost-map changes, add two new 267 fields to the full cost-map response: a "cost-map-vtag" and a hint 268 about the how often the server updates the cost map. 270 Using these vtags both client and server can determine if it is 271 necessary to request or to send an updated map, a full map, or if the 272 current version is still up-to-date. 274 3.2.1. CURRENT NETWORK MAP vtag 276 This is a GET-mode request. The response is a simple json structure 277 with 279 o The current map-vtag for the network map. 281 o The average number of seconds between changes to the network map. 283 It needs a new media type, say application/alto-currentmapvtag+json 285 For example, 287 HTTP/1.1 200 OK 288 Content-Length: [TODO] 289 Content-Type: application/alto-currentmapvtag+json 291 { 292 "meta" : {}, 293 "data" : { 294 "map-vtag" : "123456", 295 update-interval: 86400 296 } 297 } 299 Figure 4: CURRENT NETWORK MAP vtag 301 3.2.2. Extensions to full cost-map response: 303 Add two new fields to the costmap response, as in: 305 object { 306 CostMode cost-mode; 307 CostType cost-type; 308 VersionTag map-vtag; 309 VersionTag cost-map-vtag; // Optional 310 JSONNumber update-interval; // Optional 311 CostMapData map; 312 } InfoResourceCostMap; 314 Figure 5: Extensions to full cost-map response 316 cost-map-vtag: A string that (together with the network map-vtag) 317 uniquely identifies this version of the cost map. 319 update-interval: Average time between cost-map updates, in seconds. 320 (A hint, not a guarantee). Perhaps required if cost-map-vtag is 321 present 323 These fields would only be in the full cost map response, not in a 324 filtered cost map response. 326 4. Incremental Update Options 328 Once a server has decided to send a partial update only there are 329 several ways to do so. These section discusses these response 330 options. 332 4.1. Send entire map 334 One trivial option is always to send the entire map anyways. The 335 advantage of sending the whole map typically is that there is no 336 computational effort needed on the server side. Thus this can always 337 be a fallback in case the server is under load, or in case a partial 338 update appears to be not inefficient. 340 4.2. Patch map 342 A server that knows the version of the map a client currently has can 343 use this information to calculate the contextual diff to the newest 344 version of the map. This can also be done in a batch process for all 345 previous versions once a new map is loaded on the server to avoid a 346 per request calculation. The diff output can then be sent in a 347 response to the client, which in turn can use it to patch its version 348 of the map. By doing this the newest version of the map can be 349 recreated. 351 4.3. Encode map 353 One major goal of applying partial updates is to reduce transmission 354 time by reducing the amount of data which is to be transferred to the 355 client. This goal can be achieved by applying compression 356 techniques, such as gzip, to the message content, both for partial 357 updates as well as for entire maps. 359 HTTP supports this by the Content-Encoding entity header field. The 360 advantage of using compression is that there is no need to change the 361 underlying media-type of the reponse. Typically not all ALTO clients 362 will support this optimization from the beginning, thus the server 363 will need to store two representations of the maps: One which is 364 compressed and one uncompressed. 366 4.4. JSON patch 368 JSON Patch [I-D.pbryan-json-patch] defines a JSON document structure 369 that allows partial modifications to a JSON document and defines the 370 associated media type "application/json-patch". Therefore JSON Patch 371 is a suitable option for incremental udates of the Network and Cost 372 Maps. JSON patch supports add, remove and replace operations that 373 can be used in combination with JSON Pointers 375 [I-D.pbryan-zyp-json-pointer] to modify values and arrays of the JSON 376 document members. 378 Typically JSON Patch is used in combination with the HTTP PATCH 379 method [RFC5789] to partially modify existing resources on a server. 380 As an ALTO client is not modifying a resource, but wants to be 381 updated if the resource has changed it needs to signal to the server 382 that it is able to receive and understand JSON Patch updates. This 383 can be done by including the media type "application/json-patch" in 384 the Accept header field of the HTTP request. 386 The following figure illustrates one example where the server decides 387 to send a partial update to the client using JSON Patch. The server 388 indicates this in the reponse Content-Type header. In the following 389 example the Network Map from the example in Figure 3 above has 390 changed. The map-vtag element has been incremented by 1, which 391 results in a replace operation for the respective element containing 392 the new value. Also two new subnets are added to the Network Map in 393 PID1 and PID2 by two add operations at the indexes 1 and 0 of the 394 ipv4 arrays. 396 HTTP/1.1 200 OK 397 Content-Length: [TODO] 398 Content-Type: application/json-patch 399 Date: Sun, 25 Dec 2011 09:33:31 GMT 401 { "replace": "/data/map-vtag", "value": "1266506140" }, 402 { "add": "/data/map/PID1/ipv4/1", "value": "198.51.200.0/25" }, 403 { "add": "/data/map/PID2/ipv4/0", "value": "198.51.200.128/25" } 405 Figure 6: Partial update with JSON Patch 407 4.5. Send only changed values 409 Another option is to offer a dedicated ALTO service for partial 410 updates. A client that detemines that its current map is out-of- 411 date, for example by comparing cost-map-vtag values can then query 412 this service to retrieve the partial update. 414 This service can be implemented in a new POST-mode request, "GET 415 COST-MAP CHANGES". The POST data would have a cost-map-vtag from a 416 previous cost-map response. The response would be the same as for a 417 full costmap request, except that it only has costs that have changed 418 since the specified cost-map-vtag. The response would contain the 419 current cost-map-vtag and update-interval. 421 If the current cost-map-vtag is the same as the specified one -- that 422 is, if there are no changes -- the "map" entry in the response has no 423 cost entries. 425 If the specified cost-map-vtag is invalid, or if it's sufficiently 426 old that the server no longer knows what changed since that version, 427 the server returns a complete cost map. Thus the response MUST have 428 costs that changed since the specified version, but MAY have other 429 costs as well. 431 A possible implementation strategy for this service is to maintain at 432 the server for each cost type an "instantaneous" cost map and the 433 last N "numbered versions" of those costs. For a full-map requests 434 without a version number, the server returns the most recent 435 numbered-version map. For a COST-MAP CHANGES request, the server 436 finds the client's version number in its stack of saved versions, and 437 returns the diffs between that version and the most recent numbered 438 version. If the server doesn't have the old version any more, the 439 server returns the full latest version. 441 Then periodically the server copies the instantaneous map to the 442 last-stable map, assigns it a new version number, shuffles the list 443 down, and discards the oldest version. The server could cache diffs 444 and discard old ones. 446 For filtered cost-map requests, the server could use either the 447 "instantaneous" cost map or the most recent "versioned" cost map. 449 5. IANA Considerations 451 None. 453 6. Security Considerations 455 To be done in later versions of this document. 457 7. Conclusion 459 This document describes different options that can be applied to 460 support incremental updates of ALTO Network and Cost maps. In 461 particular it comprises option for client and server to synchronize 462 themselves about their current map state, and further includes 463 options on how to encode partial updates. 465 8. References 467 [I-D.ietf-alto-protocol] 468 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 469 draft-ietf-alto-protocol-10 (work in progress), 470 October 2011. 472 [I-D.jenkins-alto-cdn-use-cases] 473 Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and 474 S. Previdi, "Use Cases for ALTO within CDNs", 475 draft-jenkins-alto-cdn-use-cases-01 (work in progress), 476 June 2011. 478 [I-D.pbryan-json-patch] 479 Bryan, P., "JSON Patch", draft-pbryan-json-patch-02 (work 480 in progress), October 2011. 482 [I-D.pbryan-zyp-json-pointer] 483 Bryan, P. and K. Zyp, "JSON Pointer", 484 draft-pbryan-zyp-json-pointer-02 (work in progress), 485 October 2011. 487 [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic 488 Optimization (ALTO) Problem Statement", RFC 5693, 489 October 2009. 491 [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", 492 RFC 5789, March 2010. 494 Appendix A. Acknowledgments 496 The authors would like to thank Vijay Gurbani for his valuable input 497 and excellent feedback to this document. 499 Nico Schwan is partially supported by the ENVISION project 500 (http://www.envision-project.org), a research project supported by 501 the European Commission under its 7th Framework Program (contract no. 502 248565). The views and conclusions contained herein are those of the 503 authors and should not be interpreted as necessarily representing the 504 official policies or endorsements, either expressed or implied, of 505 the ENVISION project or the European Commission. 507 Authors' Addresses 509 Nico Schwan 510 Alcatel-Lucent Bell Labs 511 Lorenzstrasse 10 512 Stuttgart 70435 513 Germany 515 Email: nico.schwan@alcatel-lucent.com 516 URI: www.alcatel-lucent.com/bell-labs 518 Bill Roome 519 Alcatel-Lucent Bell Labs 521 Email: w.roome@alcatel-lucent.com 522 URI: www.alcatel-lucent.com/bell-labs