idnits 2.17.1 draft-ietf-sipcore-event-rate-control-04.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 == Line 939 has weird spacing: '...n-State min-...' == Line 941 has weird spacing: '...n-State max-...' == Line 943 has weird spacing: '...n-State aver...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 09, 2010) is 5039 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: 'RFCxxxx' is mentioned on line 943, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft K. Kiss 4 Intended status: Standards Track Nokia 5 Expires: January 10, 2011 S. Loreto 6 Ericsson 7 July 09, 2010 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-04 13 Abstract 15 This document specifies mechanisms for adjusting the rate of Session 16 Initiation Protocol (SIP) event notifications. These mechanisms can 17 be applied in subscriptions to all SIP event packages. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 10, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Definitions and Document Conventions . . . . . . . . . . . . . 5 67 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. Use Case for limiting the maximum rate of notifications . 5 69 3.2. Use Case for setting a minimum rate for notifications . . 6 70 3.3. Use Case for specifying the average rate of 71 notifications . . . . . . . . . . . . . . . . . . . . . . 7 72 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.5. The maximum rate mechanism for Resource List Server . . . 8 74 3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10 75 4. Operation of the maximum rate mechanism . . . . . . . . . . . 11 76 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 11 77 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 11 78 4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 12 79 4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 13 80 4.4.1. Partial State Notifications . . . . . . . . . . . . . 13 81 4.4.2. Full State Notifications . . . . . . . . . . . . . . . 14 82 4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14 83 5. Operation of the minimum rate mechanism . . . . . . . . . . . 14 84 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 15 85 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15 86 6. Operation of the average rate mechanism . . . . . . . . . . . 16 87 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16 88 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17 89 6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 18 90 7. Usage of "min-interval", "max-interval" and 91 "average-interval" in a combination . . . . . . . . . . . . . 19 92 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 8.1. "min-interval", "max-interval" and "average-interval" 94 Header Field Parameters . . . . . . . . . . . . . . . . . 20 95 8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 20 96 8.3. Event header field usage in responses to the NOTIFY 97 request . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 100 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 101 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 103 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 The SIP events framework [RFC3265] defines a generic framework for 109 subscriptions to and notifications of events related to SIP systems. 110 This framework defines the methods SUBSCRIBE and NOTIFY, and 111 introduces the concept of an event package, which is a concrete 112 application of the SIP events framework to a particular class of 113 events. 115 One of the things the SIP events framework mandates is that each 116 event package specification defines an absolute maximum on the rate 117 at which notifications are allowed to be generated by a single 118 notifier. Such a limit is provided in order to reduce network load. 120 All of the existing event package specifications include a maximum 121 notification rate recommendation, ranging from once in every five 122 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 124 Per the SIP events framework, each event package specification is 125 also allowed to define additional throttle mechanisms which allow the 126 subscriber to further limit the rate of event notification. So far 127 none of the event package specifications have defined such a 128 mechanism. 130 The resource list extension [RFC4662] to the SIP events framework 131 also deals with rate limiting of event notifications. The extension 132 allows a subscriber to subscribe to a heterogeneous list of resources 133 with a single SUBSCRIBE request, rather than having to install a 134 subscription for each resource separately. The event list 135 subscription also allows rate limiting, or throttling of 136 notifications, by means of the Resource List Server (RLS) buffering 137 notifications of resource state changes, and sending them in batches. 138 However, the event list mechanism provides no means for the 139 subscriber to set the interval for the throttling; it is strictly an 140 implementation decision whether batching of notifications is 141 supported, and by what means. 143 This document defines an extension to the SIP events framework 144 defining the following three "Event" header field parameters that 145 allow a subscriber to set a Minimum, a Maximum and an Average rate of 146 event notifications generated by the notifier: 148 min-interval: specifies a minimum notification time period between 149 two notifications, in seconds. 151 max-interval: specifies a maximum notification time period between 152 two notifications, in seconds. 154 average-interval: specifies an average cadence at which 155 notifications are desired, in seconds. 157 The requirements and model are further discussed in Section 3. All 158 these mechanisms are simply timer values that indicate the minimum, 159 maximum and average time period allowed between two notifications. 160 As a result of these mechanisms, a compliant notifier will adjust the 161 rate at which it generates notifications. 163 These mechanisms are applicable to any event subscription, both 164 single event subscription and event list subscription. 166 2. Definitions and Document Conventions 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in RFC 2119 [RFC2119] and 171 indicate requirement levels for compliant implementations. 173 Indented passages such as this one are used in this document to 174 provide additional information and clarifying text. They do not 175 contain normative protocol behavior. 177 3. Overview 179 3.1. Use Case for limiting the maximum rate of notifications 181 A presence client in a mobile device contains a list of 100 buddies 182 or presentities. In order to decrease the processing and network 183 load of watching 100 presentities, the presence client has employed a 184 Resource List Server (RLS) with the list of buddies, and therefore 185 only needs a single subscription to the RLS in order to receive 186 notification of the presence state of the resource list. 188 In order to control the buffer policy of the RLS, the presence client 189 sets a maximum rate ("min-interval" parameter), i.e. a minimum time 190 interval between two notifications. Alternatively, the presence 191 client could set the maximum rate for the resource list via a list 192 manipulation interface, e.g., using the XML Configuration Access 193 Protocol (XCAP) [RFC4825]. 195 The RLS will buffer notifications that do not comply with the maximum 196 rate and batch all of the buffered state changes together in a single 197 notification only when allowed by the maximum rate. The maximum rate 198 applies to the overall resource list, which means that there is a 199 hard cap imposed by the maximum rate to the number of notifications 200 the presence client can expect to receive. 202 For example, with a "min-interval" of 20 seconds, the presence 203 application can expect to receive a notification at a minimum of 204 every 20 seconds. 206 The presence client can also modify the "min-interval" parameter 207 during the lifetime of the subscription. For example, if the User 208 Interface (UI) of the application shows inactivity for a period of 209 time, it can simply pause the notifications by setting the "min- 210 interval" parameter to the subscription expiration time, while still 211 keeping the subscription alive. When the user becomes active again, 212 the presence client can resume the stream of notifications by re- 213 subscribing with a "min-interval" parameter set to the earlier used 214 value. Application of the mechanism defined by RFC 5839 [RFC5839] 215 can also eliminate for the presence client to receive a (full-state) 216 notification carrying the latest resource state after the 217 subscription refresh. 219 3.2. Use Case for setting a minimum rate for notifications 221 A location application is monitoring the movement of a target. 223 In order to decrease the processing and network load, the location 224 application has made a subscription with a set of location filters 225 [I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for 226 example, to send an update only when the target has moved at least n 227 meters. However, the application is also interested in receiving the 228 current state periodically even if the state of the target has not 229 changed enough to satisfy any of the trigger criteria, i.e. has not 230 moved at least n meters within the period. 232 In order to control the actual state, the location application sets a 233 minimum rate ("max-interval" parameter), i.e. a maximum time interval 234 between two notifications. 236 The location application can also modify the "max-interval" parameter 237 during the lifetime of the subscription. When the subscription to 238 the movement of a target is made, the notifier may not have the 239 location information available. Thus, the first notification might 240 be empty, or certain values might be absent. An important use case 241 is placing constraints on when complete state should be provided 242 after creating the subscription. The "max-interval" parameter 243 indicates the time to the notifier when a complete state information 244 should be notified. Once state is acquired and the second 245 notification is sent, the subscriber updates or changes the "max- 246 interval" parameter to a more sensible value. This update can be 247 performed in the 200 OK response to the NOTIFY request that contains 248 the complete state information. 250 3.3. Use Case for specifying the average rate of notifications 252 The previous mechanisms introduce a static and instantaneous rate 253 control. However there are some applications that would work better 254 with an adaptive rate control. This section illustrates the tracking 255 scenario. 257 A tracking application is monitoring a target. 259 In order to decrease the processing and network load, the tracking 260 application wants to make a subscription that dynamically increases 261 the interval between notifications if the target has sent out several 262 notifications recently. 264 In order to set an adaptive rate control, the application defines a 265 average cadence ("average-interval" parameter) at which notifications 266 are desired. The "average-interval" parameter value is used by the 267 notifier to dynamically calculate the maximum time allowed between 268 two notifications. In order to dynamically calculate the maximum, 269 the Notifier takes into consideration the frequency at which 270 notifications have been sent recently. 272 This type of rate control allows the notifier to dynamically increase 273 or decrease the Notification frequency. 275 The tracking application can also modify the "average-interval" 276 parameter during the lifetime of the subscription. 278 3.4. Requirements 280 REQ1: The subscriber must be able to set the minimum time period 281 ("min-interval" parameter) between two notifications in a 282 specific subscription. 284 REQ2: The subscriber must be able to set the maximum time period 285 ("max-interval" parameter) between two notifications in a 286 specific subscription. 288 REQ3: The subscriber must be able to set an average cadence 289 ("average-interval" parameter) at which notifications are 290 desired in a specific subscription. 292 REQ4: It must be possible to apply all together, or in any 293 combination, the "min-interval", "max-interval" and "average- 294 interval" mechanisms in a specific subscription. 296 REQ5: It must be possible to use of the different rate control 297 mechanisms in subscriptions to any events. 299 REQ6: It must be possible to use the different rate control 300 mechanisms together with any other event filtering 301 mechanisms. 303 REQ7: The notifier must be allowed to use a policy in which the 304 minimum time period between two notifications is adjusted 305 from the value given by the subscriber. 307 For example, due to congestion reasons, local policy at 308 the notifier could temporarily dictate a policy that in 309 effect increases the subscriber-configured minimum time 310 period between two notifications. In another example, the 311 notifier can decrease the proposed minimum time by the 312 subscriber to match it with the remaining expiry time left 313 for the subscription. 315 REQ8: The different rate control mechanisms must discuss corner 316 cases for setting the time periods between two notifications. 317 At a minimum, the mechanisms must include discussion of the 318 situation resulting from a minimum, maximum or average time 319 period which exceeds the subscription duration, and should 320 provide mechanisms for avoiding this situation. 322 REQ9: The different rate control mechanisms must be possible to be 323 installed, modified, or removed in the course of an active 324 subscription. 326 REQ10: The different rate control mechanisms must allow for the 327 application of authentication and integrity protection 328 mechanisms to subscriptions invoking that mechanism. 330 3.5. The maximum rate mechanism for Resource List Server 332 When applied to a list subscription [RFC4662], the maximum rate 333 mechanism has some additional considerations. Specifically, the 334 maximum rate applies to the aggregate notification stream resulting 335 from the list subscription, rather than explicitly controlling the 336 notification of each of the implied constituent events. Moreover, 337 the RLS can use the maximum rate mechanism on its own to control the 338 rate of the back-end subscriptions to avoid overflowing its buffer. 340 The notifier is responsible for sending out event notifications upon 341 state changes of the subscribed resource. We can model the notifier 342 as consisting of three components: the event state resource(s), the 343 Resource List Server (RLS) (or any other notifier), a notification 344 buffer, and finally the subscriber, or watcher of the event state, as 345 shown in Figure 1. 347 +--------+ 348 | Event | 349 +--------+ |Resource| +--------+ 350 | Event | +--------+ | Event | 351 |Resource| | |Resource| 352 +---.=---+ | +---=----+ 353 `-.. | _.--' 354 ``-._ | _.--' 355 +'--'--'-+ 356 |Resource| 357 | List | 358 | Server | 359 +---.----+ 360 | 361 | 362 )--+---( 363 | | .------------. 364 |Buffer|<======'min-interval| 365 | | `------------' 366 )--.---( 367 | 368 | 369 .---+---. 370 | Event | 371 |Watcher| 372 `-------' 374 Figure 1: Model for the Resource List Server (RLS) Supporting 375 Throttling 377 In short, the RLS reads event state changes from the event state 378 resource, either by creating a back end subscription, or by other 379 means; it packages them into event notifications, and submits them 380 into the output buffer. The rate at which this output buffer drains 381 is controlled by the subscriber via the maximum rate mechanism. When 382 a set of notifications are batched together, the way in which 383 overlapping resource state is handled depends on the type of the 384 resource state: 386 In theory, there are many buffer policies that the notifier could 387 implement. However, we only concentrate on two practical buffer 388 policies in this specification, leaving additional ones for 389 further study and out of the scope of this work. These two buffer 390 policies depend on the mode in which the notifier is operating. 392 Full-state: Last (most recent) full state notification of each 393 resource is sent out, and all others in the buffer are discarded. 394 This policy applies to those event packages that carry full-state 395 notifications. 397 Partial-state: The state deltas of each buffered partial 398 notification per resource are merged, and the resulting 399 notification is sent out. This policy applies to those event 400 packages that carry partial-state notifications. 402 3.6. Basic Operation 404 A subscriber that wants to limit the rate of event notification in a 405 specific event subscription does so by including a "min-interval" 406 Event header parameter as part of the SUBSCRIBE request. The "min- 407 interval" value indicates the minimum time allowed between 408 transmission of two consecutive notifications in a subscription. 410 Note that the witnessed time between two consecutive received 411 notifications may not conform to the "min-interval" value for a 412 number of reasons. For example, network jitter and 413 retransmissions may result in the subscriber receiving the 414 notifications with smaller intervals than the "min-interval" value 415 recommends. 417 A subscriber that wants to have a maximum notification time period in 418 a specific event subscription does so by including a "max-interval" 419 Event header parameter as part of the SUBSCRIBE request. The "max- 420 interval" value indicates the maximum time allowed between 421 transmission of two consecutive notifications in a subscription. 423 A subscriber that wants to have an average cadence for the 424 notifications in a specific event subscription does so by including a 425 "average-interval" Event header parameter as part of the SUBSCRIBE 426 request. 428 A subscriber that wants to update a previously agreed event rate 429 control parameter does so by including the updated "min-interval", 430 "max-interval" or "average-interval" Event header parameter as part 431 of a subsequent SUBSCRIBE request or a 200-class response to the 432 NOTIFY request. 434 A notifier that supports the different rate control mechanisms will 435 comply with the value given in "min-interval", "max-interval" and 436 "average-interval" parameters and adjust its rate of notification 437 accordingly. However, if the notifier needs to lower the 438 subscription expiration value or a local policy or other 439 implementation-determined constraint at the notifier can not satisfy 440 the rate control request, then the notifier can adjust (i.e. increase 441 or decrease) opportunely the subscriber requested rate control. 443 4. Operation of the maximum rate mechanism 445 4.1. Subscriber Behavior 447 In general, the way in which a subscriber generates SUBSCRIBE 448 requests and processes NOTIFY requests is according to RFC 3265 449 [RFC3265]. 451 A subscriber that wishes to apply a maximum rate to notifications in 452 a subscription MUST construct a SUBSCRIBE request that includes a 453 minimum time interval between two consecutive notifications included 454 in the "min-interval" Event header field parameter. The value of 455 this parameter is an integral number of seconds in decimal. 457 A subscriber that wishes to update the previously agreed maximum rate 458 of notifications MUST include the updated "min-interval" Event header 459 field parameter in a subsequent SUBSCRIBE request or a 200-class 460 response to the NOTIFY request. If the Event header field of the 461 SUBSCRIBE request did not include the "min-interval" parameter, the 462 subscriber MUST NOT include an initial value of the "min-interval" 463 Event header field parameter in a 200-class response to the NOTIFY 464 request. 466 A subscriber that wishes to remove the maximum rate control from 467 notifications MUST indicate so by not including a "min-interval" 468 Event header field parameter in a subsequent SUBSCRIBE request or a 469 200-class response to the NOTIFY request. 471 There are two main consequences for the subscriber when applying the 472 maximum rate mechanism: state transitions may be lost, and event 473 notifications may be delayed. If either of these side effects 474 constitute a problem to the application that is to utilize event 475 notifications, developers are instructed not to use the mechanism. 477 4.2. Notifier Behavior 479 In general, the way in which a notifier processes SUBSCRIBE requests 480 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 482 A notifier that supports the maximum rate mechanism MUST extract the 483 value of the "min-interval" Event header parameter from a SUBSCRIBE 484 request or a 200-class response to the NOTIFY request and use it as 485 the suggested time allowed between two notifications. This value can 486 be adjusted by the notifier, as defined in Section 4.3. If the Event 487 header field of the SUBSCRIBE request did not include the "min- 488 interval" parameter, the notifier MUST ignore an initial value of the 489 "min-interval" Event header field parameter in a 200-class response 490 to the NOTIFY request, if present. 492 A compliant notifier MUST reflect back the possibly adjusted minimum 493 time interval in a "min-interval" Subscription-State header field 494 parameter of the subsequent NOTIFY requests. The indicated "min- 495 interval" value is adopted by the notifier, and the notification rate 496 is adjusted accordingly. 498 A notifier that does not understand this extension will not reflect 499 the "min-interval" Subscription-State header field parameter in the 500 NOTIFY requests; the absence of this parameter indicates to the 501 subscriber that no rate control is supported by the notifier. 503 A compliant notifier MUST NOT generate notifications more frequently 504 than the maximum rate allows for, except when generating the 505 notification either upon receipt of a SUBSCRIBE request (the first 506 notification), when the subscription state is changing from "pending" 507 to "active" state or upon termination of the subscription (the last 508 notification). Such notifications reset the timer for the next 509 notification, even though they do not need to abide by it. 511 When a local policy dictates a maximum rate for notifications, a 512 notifier will not generate notifications more frequently than the 513 local policy maximum rate, even if the subscriber is not asking for 514 maximum rate control. The notifier MAY inform the subscriber about 515 such local policy maximum rate using the "min-interval" Subscription- 516 State header field parameter included in the subsequent NOTIFY 517 requests. 519 Retransmissions of NOTIFY requests are not affected by the maximum 520 rate mechanism, i.e., the maximum rate mechanism only applies to the 521 generation of new transactions. In other words, the maximum rate 522 mechanism does not in any way break or modify the normal 523 retransmission mechanism specified in RFC 3261 [RFC3261]. 525 4.3. Selecting the maximum rate 527 Special care needs to be taken when selecting the "min-interval" 528 value. Using the "min-interval" syntax it is possible to insist both 529 very short and very long intervals between notifications. 531 For example, the maximum rate could potentially set a minimum time 532 value between notifications that exceeds the subscription expiration 533 value. Such a configuration would effectively quench the notifier, 534 resulting in exactly two notifications to be generated. If the 535 subscriber requests a "min-interval" value greater than the 536 subscription expiration, the notifier MUST lower the "min-interval" 537 value and set it to the expiration time left. According to RFC 3265 538 [RFC3265] the notifier may also shorten the subscription expiry 539 anytime during an active subscription. If the subscription expiry is 540 shortened during an active subscription, the notifier MUST also lower 541 the "min-interval" value and set it to the reduced expiration time. 543 In some cases it makes sense to pause the notification stream on an 544 existing subscription dialog on a temporary basis without terminating 545 the subscription, e.g. due to inactivity on the application UI. 546 Whenever a subscriber discovers the need to perform the notification 547 pause operation, it SHOULD set the "min-interval" value to the 548 remaining subscription expiration value. This results in receiving 549 no further notifications until the subscription expires or the 550 subscriber sends a SUBSCRIBE request resuming notifications. 552 The notifier MAY decide to increase or decrease the proposed maximum 553 rate value by the subscriber based on its local policy, static 554 configuration or other implementation-determined constraints. The 555 notifier MUST include the adjusted "min-interval" value in the 556 Subscription-State header field's "min-interval" parameter in each of 557 the NOTIFY requests. In addition, different event packages MAY 558 define additional constraints to the allowed "min-interval" 559 intervals. Such constraints are out of the scope of this 560 specification. 562 4.4. Buffer Policy Description 564 4.4.1. Partial State Notifications 566 With partial notifications, the notifier will always need to keep 567 both a copy of the current full state of the resource F, as well as 568 the last successfully communicated full state view F' of the resource 569 in a specific subscription. The construction of a partial 570 notification then involves creating a difference of the two states, 571 and generating a notification that contains that difference. 573 When the maximum rate mechanism is applied to the subscription, it is 574 important that F' is replaced with F only when the difference of F 575 and F' was already included in a partial state notification to the 576 subscriber allowed by the maximum rate mechanism. Additionally, the 577 notifier implementation SHOULD check to see that the size of an 578 accumulated partial state notification is smaller than the full 579 state, and if not, the notifier SHOULD send the full state 580 notification instead. 582 4.4.2. Full State Notifications 584 With full state notifications, the notifier only needs to keep the 585 full state of the resource, and when that changes, send the resulting 586 notification over to the subscriber. 588 When the maximum rate mechanism is applied to the subscription, the 589 notifier receives the state changes of the resource, and generates a 590 notification. If there is a pending notification, the notifier 591 simply replaces that notification with the new notification, 592 discarding the older state. 594 4.5. Estimated Bandwidth Savings 596 It is difficult to estimate the total bandwidth savings accrued by 597 using the maximum rate mechanism over a subscription, since such 598 estimates will vary depending on the usage scenarios. However, it is 599 easy to see that given a subscription where several full state 600 notifications would have normally been sent in any given interval set 601 by the "min-interval" parameter, only a single notification is sent 602 during the same interval when using the maximum rate mechanism, 603 yielding bandwidth savings of several times the notification size. 605 With partial-state notifications, drawing estimates is further 606 complicated by the fact that the states of consecutive updates may or 607 may not overlap. However, even in the worst case scenario, where 608 each partial update is to a different part of the full state, a rate 609 controlled notification merging all of these n partial states 610 together should at a maximum be the size of a full-state update. In 611 this case, the bandwidth savings are approximately n times the size 612 of the header fields of the NOTIFY request. 614 It is also true that there are several compression schemes available 615 that have been designed to save bandwidth in SIP, e.g., SigComp 616 [RFC3320] and TLS compression [RFC3943]. However, such compression 617 schemes are complementary rather than competing mechanisms to the 618 maximum rate mechanism. After all, they can both be applied 619 simultaneously, and in such a way that the compound savings are as 620 good as the sum of applying each one alone. 622 5. Operation of the minimum rate mechanism 623 5.1. Subscriber Behavior 625 In general, the way in which a subscriber generates SUBSCRIBE 626 requests and processes NOTIFY requests is according to RFC 3265 627 [RFC3265]. 629 A subscriber that wishes to apply a minimum rate to notifications in 630 a subscription MUST construct a SUBSCRIBE request that includes a 631 maximum time interval between two consecutive notifications included 632 in the "max-interval" Event header field parameter. The value of 633 this parameter is an integral number of seconds in decimal. 635 A subscriber that wishes to update the previously agreed minimum rate 636 of notifications MUST include the updated "max-interval" Event header 637 field parameter in a subsequent SUBSCRIBE request or a 200-class 638 response to the NOTIFY request. If the Event header field of the 639 SUBSCRIBE request did not include the "max-interval" parameter, the 640 subscriber MUST NOT include an initial value of the "max-interval" 641 Event header field parameter in a 200-class response to the NOTIFY 642 request. 644 A subscriber that wishes to remove the minimum rate control from 645 notifications MUST indicate so by not including a "max-interval" 646 Event header field parameter in a subsequent SUBSCRIBE request or a 647 200-class response to the NOTIFY request. 649 The main consequence for the subscriber when applying the minimum 650 rate mechanism is that it can receive a notification even if nothing 651 has changed in the current state of the notifier. However, RFC 5839 652 [RFC5839] defines a mechanism that allows sending only an etag 653 instead of the full resource state in a notification if the state has 654 not changed. 656 5.2. Notifier Behavior 658 In general, the way in which a notifier processes SUBSCRIBE requests 659 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 661 A notifier that supports the minimum rate mechanism MUST extract the 662 value of the "max-interval" Event header parameter from a SUBSCRIBE 663 request or a 200-class response to the NOTIFY request and use it as 664 the suggested maximum time allowed between two notifications. If the 665 Event header field of the SUBSCRIBE request did not include the "max- 666 interval" parameter, the notifier MUST ignore an initial value of the 667 "max-interval" Event header field parameter in a 200-class response 668 to the NOTIFY request, if present. 670 The notifier MAY decide to increase or decrease the proposed minimum 671 rate value based on its local policy, static configuration or other 672 implementation-determined constraints. A compliant notifier MUST 673 reflect back the possibly adjusted maximum time interval in a "max- 674 interval" Subscription-State header field parameter of the subsequent 675 NOTIFY requests. The indicated "max-interval" value is adopted by 676 the notifier, and the notification rate is adjusted accordingly. 678 A notifier that does not understand this extension, will not reflect 679 the "max-interval" Subscription-State header field parameter in the 680 NOTIFY requests; the absence of this parameter indicates to the 681 subscriber that no rate control is supported by the notifier. 683 A compliant notifier MUST generate notifications whenever the time 684 since the most recent notification exceeds the value in the "max- 685 interval" parameter. Depending on the event package and subscriber 686 preferences indicated in the SUBSCRIBE request, the NOTIFY request 687 sent as a result of a max-interval expiration MUST contain either the 688 current full state or the partial state showing the difference 689 between the current state and the last successfully communicated 690 state. 692 Retransmissions of NOTIFY requests are not affected by the minimum 693 rate mechanism, i.e., the minimum rate mechanism only applies to the 694 generation of new transactions. In other words, the minimum rate 695 mechanism does not in any way break or modify the normal 696 retransmission mechanism. 698 6. Operation of the average rate mechanism 700 6.1. Subscriber Behavior 702 In general, the way in which a subscriber generates SUBSCRIBE 703 requests and processes NOTIFY requests is according to RFC 3265 704 [RFC3265]. 706 A subscriber that wishes to apply an average rate to notifications in 707 a subscription MUST construct a SUBSCRIBE request that includes a 708 proposed average time interval between two consecutive notifications 709 included in a "average-interval" Event header field parameter. The 710 value of this parameter is an integral number of seconds in decimal. 712 A subscriber that wishes to update the previously agreed average rate 713 of notifications MUST include the updated "average-interval" Event 714 header field parameter in a subsequent SUBSCRIBE request or a 200- 715 class response to the NOTIFY request. If the Event header field of 716 the SUBSCRIBE request did not include the "average-interval" 717 parameter, the subscriber MUST NOT include an initial value of the 718 "average-interval" Event header field parameter in a 200-class 719 response to the NOTIFY request. 721 A subscriber that wishes to remove the average rate control from 722 notifications MUST indicate so by not including a "average-interval" 723 Event header field parameter in a subsequent SUBSCRIBE request or a 724 200-class response to the NOTIFY request. 726 The main consequence for the subscriber when applying the average 727 rate mechanism is that it can receive a notification even if nothing 728 has changed in the current state of the notifier. However, RFC 5839 729 [RFC5839] defines a mechanism that allows sending only an etag 730 instead of the full resource state in a notification if the state has 731 not changed. 733 6.2. Notifier Behavior 735 In general, the way in which a notifier processes SUBSCRIBE requests 736 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 738 A notifier that supports the average rate mechanism MUST extract the 739 value of the "average-interval" Event header parameter from a 740 SUBSCRIBE request or a 200-class response to the NOTIFY request and 741 use it to calculate the maximum time allowed between two transactions 742 as defined in Section 6.3. If the Event header field of the 743 SUBSCRIBE request did not include the "average-interval" parameter, 744 the notifier MUST ignore an initial value of the "average-interval" 745 Event header field parameter in a 200-class response to the NOTIFY 746 request, if present. 748 The notifier MAY decide to increase or decrease the proposed average 749 time interval based on its local policy, static configuration or 750 other implementation-determined constraints. A compliant notifier 751 MUST reflect back the possibly adjusted average time interval in an 752 "average-interval" Subscription-State header field parameter of the 753 subsequent NOTIFY requests. The indicated "average-interval" value 754 is adopted by the notifier, and the notification rate is adjusted 755 accordingly. 757 A notifier that does not understand this extension will not reflect 758 the "average-interval" Subscription-State header parameter in the 759 NOTIFY requests; the absence of this parameter indicates to the 760 subscriber that no rate control is supported by the notifier. 762 A compliant notifier SHOULD generate notifications whenever the time 763 since the most recent notification exceeds the value calculated using 764 the formula defined in Section 6.3. 766 The average rate mechanism is implemented as follows: 768 1) When a subscription is first created, the notifier creates a 769 record that keeps track of the number of notifications that have 770 been sent in the "period". This record is initialized to contain 771 a history of having sent one message every "average-interval" 772 seconds for the "period". 774 2) The "timeout" value is calculated according to the equation given 775 in Section 6.3. 777 3) If the timeout period passes without a NOTIFY request being sent 778 in the subscription, then the current resource state is sent 779 (subject to any filtering associated with the subscription). 781 4) Whenever a NOTIFY request is sent (regardless of whether due to a 782 timeout or a state change), the notifier updates the notification 783 history record, recalculates the value of "timeout," and returns 784 to step 3. 786 Retransmissions of NOTIFY requests are not affected by the timeout, 787 i.e., the timeout only applies to the generation of new transactions. 788 In other words, the timeout does not in any way break or modify the 789 normal retransmission mechanism specified in RFC 3261 [RFC3261]. 791 6.3. Calculating the timeout 793 The formula used to vary the absolute pacing in a way that will meet 794 the average rate requested over the period is given in equation (1): 796 timeout = (average-interval ^ 2) * count / period (1) 798 The output of the formula, "timeout", is the time to the next 799 notification, expressed in seconds. The formula has three inputs: 801 average-interval: The value of the "average-interval" parameter 802 conveyed in the Subscription-State header field, in seconds. 804 period: The rolling average period, in seconds. The value of the 805 "period" parameter MUST be greater than the value of the "average- 806 interval" parameter. 808 count: The number of notifications that have been sent during the 809 last "period" of seconds not including any retransmissions of 810 requests. 812 In case both the maximum rate and the average rate mechanisms are 813 used in the same subscription the formula used to dynamically 814 calculate the timeout is given in equation (2): 816 timeout = MAX[min-interval, (average-interval ^ 2) * count / period] (2) 818 min-interval: The value of the "min-interval" parameter conveyed in 819 the Event header field, in seconds. 821 The formula in (2) makes sure that for all the possible values of the 822 "min-interval" and "average-interval" parameters, with "average- 823 interval" > "min-interval", the timeout never results in a lower 824 value than the value of the "min-interval" parameter. 826 In some situation it may be beneficial for the Notifier to achieve an 827 average rate in a different way than the algorithm detailed in this 828 document allows. However, the Notifier MUST comply with any "min- 829 interval" or "max-interval" parameters that have been negotiated. 831 7. Usage of "min-interval", "max-interval" and "average-interval" in a 832 combination 834 Applications can subscribe to an event package using all the rate 835 control mechanisms individually, or in combination; in fact there is 836 no technical incompatibility among them. However there are some 837 combinations of the different rate control mechanisms that make 838 little sense to be used together. This section lists all the 839 combinations that are possible to insert in a subscription; the 840 utility to use each combination in a subscription is also analyzed. 842 min-interval and max-interval: this combination allows to reduce the 843 notification frequency rate, but at the same time assures the 844 reception of a notification every time the most recent 845 notification exceeds a specified interval. 847 A subscriber SHOULD choose a "max-interval" value higher than the 848 "min-interval" value, otherwise the notifier MUST adjust the 849 subscriber provided "max-interval" value to a value equivalent or 850 higher than the "min-interval" value. 852 min-interval and average-interval: it works in a similar way as the 853 combination above, but with the difference that the interval at 854 which notifications are assured changes dynamically. 856 A subscriber SHOULD choose a "average-interval" value higher than 857 the "min-interval" value, otherwise the notifier MUST adjust the 858 subscriber provided "average-interval" value to a value equivalent 859 or higher than the "min-interval" value. 861 max-interval and average-interval: as both the parameters are 862 designed as minimum rate mechanisms, this combination makes sense 863 only in some corner cases. 865 A subscriber SHOULD choose a "max-interval" value higher than the 866 "average-interval" value, otherwise the notifier MUST NOT consider 867 the "max-interval" value. 869 min-interval, max-interval and average-interval: this combination 870 makes little sense to be used although not forbidden. 872 A subscriber SHOULD choose a "max-interval" and "average-interval" 873 values higher than the "min-interval" value, otherwise the 874 notifier MUST adjust the subscriber provided "max-interval" and 875 "average-interval" values to a value equivalent or higher than the 876 "min-interval" value. 878 A subscriber SHOULD choose a "max-interval" value higher than the 879 "average-interval" value, otherwise the notifier MUST NOT consider 880 the "max-interval" value. 882 8. Syntax 884 This section describes the syntax extensions required for the 885 different rate control mechanisms. 887 8.1. "min-interval", "max-interval" and "average-interval" Header Field 888 Parameters 890 The "min-interval", "max-interval" and "average-interval" parameters 891 are added to the rule definitions of the Event header field and the 892 Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage 893 of this parameter is described in Section 4, Section 5 and Section 6. 895 8.2. Augmented BNF Definitions 897 This section describes the Augmented BNF [RFC5234] definitions for 898 the new syntax elements. Note that we derive here from the ruleset 899 present in RFC 3265 [RFC3265], adding additional alternatives to the 900 alternative sets of "event-param" and "subexp-params" defined 901 therein. 903 event-param =/ min-interval-param 904 subexp-params =/ min-interval-param 905 min-interval-param = "min-interval" EQUAL delta-seconds 907 event-param =/ max-interval-param 908 subexp-params =/ max-interval-param 909 max-interval-param = "max-interval" EQUAL delta-seconds 911 event-param =/ average-interval-param 912 subexp-params =/ average-interval-param 913 average-interval-param = "average-interval" EQUAL delta-seconds 915 8.3. Event header field usage in responses to the NOTIFY request 917 This table expands the table described in Section 7.2 of RFC 3265 918 [RFC3265] allowing the Event header field to appear in a 200-class 919 response to a NOTIFY request. A UA that wishes to update the value 920 for minimum, maximum or average rate of notifications can do so by 921 including all desired values for the rate control parameters in an 922 Event header field of the 200-class response to a NOTIFY request. 924 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 925 ----------------------------------------------------------------- 926 Event 2xx - - - - - - - - o 928 9. IANA Considerations 930 This specification registers three new SIP header field parameters, 931 defined by the following information which is to be added to the 932 Header Field Parameters and Parameter Values sub-registry under 933 http://www.iana.org/assignments/sip-parameters. 935 Predefined 936 Header Field Parameter Name Values Reference 937 -------------------- --------------- ---------- --------- 938 Event min-interval No [RFCxxxx] 939 Subscription-State min-interval No [RFCxxxx] 940 Event max-interval No [RFCxxxx] 941 Subscription-State max-interval No [RFCxxxx] 942 Event average-interval No [RFCxxxx] 943 Subscription-State average-interval No [RFCxxxx] 945 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 946 this specification, when assigned.) 948 10. Security Considerations 950 Naturally, the security considerations listed in RFC 3265 [RFC3265], 951 which the rate control mechanisms described in this document extends, 952 apply in entirety. In particular, authentication and message 953 integrity SHOULD be applied to subscriptions with this extension. 955 RFC 3265 [RFC3265] recommends the integrity protection of the Event 956 header field of SUBSCRIBE requests. Implementations of this 957 extension SHOULD also provide integrity protection for the Event 958 header field included in the 200-class response to the NOTIFY 959 request. 961 When the maximum rate mechanism involves partial state notifications, 962 the security considerations listed in RFC 5263 [RFC5263] apply in 963 entirety. 965 11. Acknowledgments 967 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 968 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 969 Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, 970 Michael Procter and Janet Gunn for support and/or review of this 971 work. 973 Thanks to Brian Rosen for the idea of the minimum and average rate 974 mechanisms, and Adam Roach for the work on the averaging algorithm 975 and other feedback. 977 12. References 979 12.1. Normative References 981 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 982 Requirement Levels", BCP 14, RFC 2119, March 1997. 984 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 985 A., Peterson, J., Sparks, R., Handley, M., and E. 986 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 987 June 2002. 989 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 990 Event Notification", RFC 3265, June 2002. 992 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 993 Initiation Protocol (SIP) Event Notification Extension for 994 Resource Lists", RFC 4662, August 2006. 996 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 997 Specifications: ABNF", STD 68, RFC 5234, January 2008. 999 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 1000 Khartabil, "Session Initiation Protocol (SIP) Extension 1001 for Partial Notification of Presence Information", 1002 RFC 5263, September 2008. 1004 12.2. Informative References 1006 [I-D.ietf-geopriv-loc-filters] 1007 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 1008 Location Notifications in the Session Initiation Protocol 1009 (SIP)", draft-ietf-geopriv-loc-filters-11 (work in 1010 progress), March 2010. 1012 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 1013 Liu, Z., and J. Rosenberg, "Signaling Compression 1014 (SigComp)", RFC 3320, January 2003. 1016 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1017 Package for Registrations", RFC 3680, March 2004. 1019 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1020 Indication Event Package for the Session Initiation 1021 Protocol (SIP)", RFC 3842, August 2004. 1023 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1024 Initiation Protocol (SIP)", RFC 3856, August 2004. 1026 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 1027 Package for the Session Initiation Protocol (SIP)", 1028 RFC 3857, August 2004. 1030 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 1031 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 1032 November 2004. 1034 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1035 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1037 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 1038 Initiation Protocol (SIP) Events for Conditional Event 1039 Notification", RFC 5839, May 2010. 1041 Authors' Addresses 1043 Aki Niemi 1044 Nokia 1045 P.O. Box 407 1046 NOKIA GROUP, FIN 00045 1047 Finland 1049 Phone: +358 50 389 1644 1050 Email: aki.niemi@nokia.com 1052 Krisztian Kiss 1053 Nokia 1054 323 Fairchild Dr 1055 Mountain View, CA 94043 1056 US 1058 Phone: +1 650 391 5969 1059 Email: krisztian.kiss@nokia.com 1061 Salvatore Loreto 1062 Ericsson 1063 Hirsalantie 11 1064 Jorvas 02420 1065 Finland 1067 Email: salvatore.loreto@ericsson.com