idnits 2.17.1 draft-ietf-sipcore-event-rate-control-06.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 973 has weird spacing: '...n-State max-...' == Line 975 has weird spacing: '...n-State min-...' == Line 977 has weird spacing: '...n-State adap...' == Line 986 has weird spacing: '...er Name compa...' (Using the creation date from RFC3265, updated by this document, for RFC5378 checks: 2001-07-05) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 1, 2011) is 4803 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 988, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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 Updates: 3265 (if approved) Nokia 5 Intended status: Standards Track S. Loreto 6 Expires: September 2, 2011 Ericsson 7 March 1, 2011 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-06 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. This document 18 updates RFC 3265. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 2, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Definitions and Document Conventions . . . . . . . . . . . . . 5 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Use Case for Limiting the Maximum Rate of Notifications . 5 70 3.2. Use Case for Setting a Minimum Rate for Notifications . . 6 71 3.3. Use Case for Specifying an Adaptive Minimum Rate of 72 Notifications . . . . . . . . . . . . . . . . . . . . . . 6 73 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 8 75 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 8 76 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 9 77 5. Operation of the Maximum Rate Mechanism . . . . . . . . . . . 9 78 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 9 79 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 10 80 5.3. Selecting the Maximum Rate . . . . . . . . . . . . . . . . 11 81 5.4. The Maximum Rate Mechanism for Resource List Server . . . 11 82 5.5. Buffer Policy Description . . . . . . . . . . . . . . . . 13 83 5.5.1. Partial State Notifications . . . . . . . . . . . . . 13 84 5.5.2. Full State Notifications . . . . . . . . . . . . . . . 13 85 5.6. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14 86 6. Operation of the Minimum Rate Mechanism . . . . . . . . . . . 14 87 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 14 88 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15 89 6.3. Selecting the Minimum Rate . . . . . . . . . . . . . . . . 16 90 7. Operation of the Adaptive Minimum Rate Mechanism . . . . . . . 16 91 7.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16 92 7.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17 93 7.3. Selecting the Adaptive Minimum Rate . . . . . . . . . . . 18 94 7.4. Calculating the Timeout . . . . . . . . . . . . . . . . . 18 95 8. Usage of the Maximum Rate, Minimum Rate and Adaptive 96 Minimum Rate Mechanisms in a combination . . . . . . . . . . . 19 97 9. Protocol Element Definitions . . . . . . . . . . . . . . . . . 21 98 9.1. "max-rate", "min-rate" and "adaptive-min-rate" Header 99 Field Parameters . . . . . . . . . . . . . . . . . . . . . 21 100 9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 21 101 9.3. Event Header Field Usage in Responses to the NOTIFY 102 request . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 104 11. Security Considerations . . . . . . . . . . . . . . . . . . . 22 105 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 107 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 108 13.2. Informative References . . . . . . . . . . . . . . . . . . 24 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 111 1. Introduction 113 The SIP events framework [RFC3265] defines a generic framework for 114 subscriptions to and notifications of events related to SIP systems. 115 This framework defines the methods SUBSCRIBE and NOTIFY, and 116 introduces the concept of an event package, which is a concrete 117 application of the SIP events framework to a particular class of 118 events. 120 One of the things the SIP events framework mandates is that each 121 event package specification defines an absolute maximum on the rate 122 at which notifications are allowed to be generated by a single 123 notifier. Such a limit is provided in order to reduce network load. 125 All of the existing event package specifications include a maximum 126 notification rate recommendation, ranging from once in every five 127 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 129 Per the SIP events framework, each event package specification is 130 also allowed to define additional throttle mechanisms which allow the 131 subscriber to further limit the rate of event notification. So far 132 none of the event package specifications have defined such a 133 mechanism. 135 The resource list extension [RFC4662] to the SIP events framework 136 also deals with rate limiting of event notifications. The extension 137 allows a subscriber to subscribe to a heterogeneous list of resources 138 with a single SUBSCRIBE request, rather than having to install a 139 subscription for each resource separately. The event list 140 subscription also allows rate limiting, or throttling of 141 notifications, by means of the Resource List Server (RLS) buffering 142 notifications of resource state changes, and sending them in batches. 143 However, the event list mechanism provides no means for the 144 subscriber to set the interval for the throttling. 146 Some event packages are also interested in specifying an absolute or 147 an adaptive minimum rate at which notifications need to be generated 148 by a notifier. This helps the subscriber to effectively use 149 different trigger criterias within a subscription to eliminate 150 unnecessary notifications but at the same time make sure that the 151 current event state is periodically received. 153 This document defines an extension to the SIP events framework 154 defining the following three Event header field parameters that allow 155 a subscriber to set a maximum, a minimum and an adaptive minimum rate 156 of notifications generated by the notifier: 158 max-rate: specifies a maximum rate of notifications (a minimum time 159 period between two notifications). 161 min-rate: specifies a minimum rate notifications (a maximum time 162 period between two notifications). 164 average-rate: specifies an adaptive minimum rate of notifications 165 (an adaptive maximum time period between two notifications). 167 These mechanisms are applicable to any event subscription, both 168 single event subscription and event list subscription. A notifier 169 compliant to this specification will adjust the rate at which it 170 generates notifications. 172 2. Definitions and Document Conventions 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119] and 177 indicate requirement levels for compliant implementations. 179 Indented passages such as this one are used in this document to 180 provide additional information and clarifying text. They do not 181 contain normative protocol behavior. 183 3. Overview 185 3.1. Use Case for Limiting the Maximum Rate of Notifications 187 A presence client in a mobile device contains a list of 100 buddies 188 or presentities. In order to decrease the processing and network 189 load of watching 100 presentities, the presence client has employed a 190 Resource List Server (RLS) with the list of buddies, and therefore 191 only needs a single subscription to the RLS in order to receive 192 notifications of the presence state of the resource list. 194 In order to control the buffer policy of the RLS, the presence client 195 sets a maximum rate of notifications. The RLS will buffer 196 notifications that are generated faster than they are allowed to be 197 sent due to the maximum rate and batch all of the buffered state 198 changes together in a single notification. The maximum rate applies 199 to the overall resource list, which means that there is a hard cap 200 imposed by the maximum rate to the number of notifications per second 201 the presence client can expect to receive. 203 The presence client can also modify the maximum rate of notifications 204 during the lifetime of the subscription. For example, if the mobile 205 device detects inactivity from the user for a period of time, the 206 presence client can simply pause notifications by choosing a "max- 207 rate" parameter that allows only a single notification for the 208 remainder of the subscription lifetime. When the user becomes active 209 again, the presence client can resume the stream of notifications by 210 re-subscribing with a "max-rate" parameter set to the earlier used 211 value. Application of the mechanism defined by RFC 5839 [RFC5839] 212 can also eliminate the transmission of a (full-state) notification 213 carrying the latest resource state to the presence client after a 214 subscription refresh. 216 3.2. Use Case for Setting a Minimum Rate for Notifications 218 A location application is monitoring the movement of a target. In 219 order to decrease the processing and network load, the location 220 application has made a subscription to a Location Server with a set 221 of location filters [I-D.ietf-geopriv-loc-filters] that specify 222 trigger criteria, e.g. to send an update only when the target has 223 moved at least n meters. However, the application is also interested 224 in receiving the current state periodically even if the state of the 225 target has not changed enough to satisfy any of the trigger criteria, 226 e.g., has not moved at least n meters within the period. 228 The location application sets a minimum rate of notifications and 229 include it in the subscription sent to the Location Server. The "min- 230 rate" parameter indicates the minimum number of notifications per 231 second the notifier needs to generate. 233 The location application can also modify the minimum rate of 234 notifications during the lifetime of the subscription. For example, 235 when the subscription to the movement of a target is made, the 236 notifier may not have the location information available. Thus, the 237 first notification might be empty, or certain values might be absent. 238 An important use case is placing constraints on when complete state 239 should be provided after creating the subscription. Once state is 240 acquired and the second notification is sent, the subscriber updates 241 or changes the "min-rate" parameter to a more sensible value. This 242 update can be performed in the response to the notification that 243 contains the complete state information. 245 3.3. Use Case for Specifying an Adaptive Minimum Rate of Notifications 247 The minimum rate mechanism introduces a static and instantaneous rate 248 control without the functionality to increase or decrease the 249 notification rate adaptively. However, there are some applications 250 that would work better with an adaptive minimum rate control. 252 A location application is monitoring the movement of a target. In 253 order to decrease the processing in the application, the location 254 application wants to make a subscription that dynamically decreases 255 the minimum rate of notifications if the target has sent out several 256 notifications recently. However, if there have have been only few 257 recent notifications by the target, the location application wants 258 the minimum rate of notifications to increase. 260 The location application sets an adaptive minimum rate of 261 notifications and include it in the subscription sent to the Location 262 Server. The "adaptive-min-rate" parameter value is used by the 263 notifier to dynamically calculate the actual maximum time between two 264 notifications. In order to dynamically calculate the maximum time, 265 the notifier takes into consideration the rate at which notifications 266 have been sent recently. In the adaptive minimum rate mechanism the 267 notifier can increase or decrease the notification rate compared to 268 the minimum rate mechanism based on the recent number of 269 notifications sent out in the last period. 271 The location application can also modify the "adaptive-min-rate" 272 parameter during the lifetime of the subscription. 274 3.4. Requirements 276 REQ1: The subscriber must be able to set a maximum rate of 277 notifications in a specific subscription. 279 REQ2: The subscriber must be able to set a minimum rate of 280 notifications in a specific subscription. 282 REQ3: The subscriber must be able to set an adaptive minimum rate 283 of notifications in a specific subscription, which adjusts 284 the minimum rate of notifications based on a moving average. 286 REQ4: It must be possible to apply the maximum rate, the minimum 287 rate and the adaptive minimum rate mechanisms all together, 288 or in any combination, in a specific subscription. 290 REQ5: It must be possible to use any of the different rate control 291 mechanisms in subscriptions to any events. 293 REQ6: It must be possible to use any of the different rate control 294 mechanisms together with any other event filtering 295 mechanisms. 297 REQ7: The notifier must be allowed to use a policy in which the 298 maximum rate, minimum rate and adaptive minimum rate 299 parameters are adjusted from the value given by the 300 subscriber. 302 For example, due to congestion reasons, local policy at 303 the notifier could temporarily dictate a policy that in 304 effect further decreases the maximum rate of 305 notifications. In another example, the notifier can 306 increase the subscriber proposed maximum rate so that at 307 least one notification is generated during the remainder 308 of the subscription lifetime. 310 REQ8: The different rate control mechanisms must address corner 311 cases for setting the notification rates appropriately. At a 312 minimum, the mechanisms must address the situation when the 313 time between two notifications would exceed the subscription 314 duration and should provide procedures for avoiding this 315 situation. 317 REQ9: The different rate control mechanisms must be possible to be 318 invoked, modified, or removed in the course of an active 319 subscription. 321 REQ10: The different rate control mechanisms must allow for the 322 application of authentication and integrity protection 323 mechanisms to subscriptions invoking that mechanism. 325 4. Basic Operations 327 4.1. Subscriber Behavior 329 In general, the way in which a subscriber generates SUBSCRIBE 330 requests and processes NOTIFY requests is according to RFC 3265 331 [RFC3265]. 333 A subscriber that wants to have a maximum, minimum or adaptive 334 minimum rate of event notifications in a specific event subscription 335 does so by including a "max-rate", "min-rate" or "adaptive-min-rate" 336 Event header field parameter(s) as part of the SUBSCRIBE request. 338 A subscriber that wants to update a previously agreed event rate 339 control parameter does so by including the updated "max-rate", "min- 340 rate" or "adaptive-min-rate" Event header field parameter(s) as part 341 of a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY 342 request. If the subscriber did not include at least one of the "max- 343 rate", "min-rate" or "adaptive-min-rate" header field parameters in 344 the most recent SUBSCRIBE request in a given dialog, the subscriber 345 MUST NOT include an Event header field with any of those parameters 346 in a 2xx response to a NOTIFY request in that dialog. 348 4.2. Notifier Behavior 350 In general, the way in which a notifier processes SUBSCRIBE requests 351 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 353 A notifier that supports the different rate control mechanisms MUST 354 adjust its rate of notification according to the rate control values 355 agreed with the subscriber. If the notifier needs to lower the 356 subscription expiration value or if a local policy or other 357 implementation-determined constraint at the notifier can not satisfy 358 the rate control request, then the notifier can adjust (i.e. increase 359 or decrease) appropriately the subscriber requested rate control 360 values. The notifier MUST reflect back the possibly adjusted rate 361 control values in a "max-rate", "min-rate" or "adaptive-min-rate" 362 Subscription-State header field parameter of the subsequent NOTIFY 363 requests. 365 5. Operation of the Maximum Rate Mechanism 367 5.1. Subscriber Behavior 369 A subscriber that wishes to apply a maximum rate to notifications in 370 a subscription MUST construct a SUBSCRIBE request that includes the 371 "max-rate" Event header field parameter specifying the requested 372 maximum number of notifications per second. The value of this 373 parameter is the reciprocal value of the "min-interval" parameter, 374 the minimum time interval between two consecutive notifications. The 375 value of the "min-interval" parameter is a positive decimal integer 376 measured in seconds. For example, when the subscriber wants to 377 receive notifications no more frequently than once in every seven 378 seconds, then it sets the value of the "max-rate" parameter to 1/7. 380 Note that the witnessed time between two consecutive received 381 notifications may not conform to the "max-rate" value for a number 382 of reasons. For example, network jitter and retransmissions may 383 result in the subscriber receiving the notifications more frequent 384 than the "max-rate" value recommends. 386 A subscriber that wishes to update the previously agreed maximum rate 387 of notifications MUST include the updated "max-rate" Event header 388 field parameter in a subsequent SUBSCRIBE request or a 2xx response 389 to the NOTIFY request. 391 A subscriber that wishes to remove the maximum rate control from 392 notifications MUST indicate so by not including a "max-rate" Event 393 header field parameter in a subsequent SUBSCRIBE request or a 2xx 394 response to the NOTIFY request. 396 There are two main consequences for the subscriber when applying the 397 maximum rate mechanism: state transitions may be lost and event 398 notifications may be delayed. If either of these side effects 399 constitute a problem to the application that utilizes the event 400 notifications, developers are instructed not to use the mechanism. 402 5.2. Notifier Behavior 404 A notifier that supports the maximum rate mechanism MUST extract the 405 value of the "max-rate" Event header parameter from a SUBSCRIBE 406 request or a 2xx response to the NOTIFY request and use it as the 407 suggested maximum number of notifications per second. This value can 408 be adjusted by the notifier, as defined in Section 5.3. 410 A compliant notifier MUST reflect back the possibly adjusted maximum 411 rate of notifications in a "max-rate" Subscription-State header field 412 parameter of the subsequent NOTIFY requests. The indicated "max- 413 rate" value is adopted by the notifier, and the notification rate is 414 adjusted accordingly. 416 A notifier that does not understand this extension will not reflect 417 the "max-rate" Subscription-State header field parameter in the 418 NOTIFY requests; the absence of this parameter indicates to the 419 subscriber that no rate control is supported by the notifier. 421 A compliant notifier MUST NOT generate notifications more frequently 422 than the maximum rate allows for, except when generating the 423 notification either upon receipt of a SUBSCRIBE request (the first 424 notification), when the subscription state is changing from "pending" 425 to "active" state or upon termination of the subscription (the last 426 notification). Such notifications reset the timer for the next 427 notification. 429 When a local policy dictates a maximum rate for notifications, a 430 notifier will not generate notifications more frequently than the 431 local policy maximum rate, even if the subscriber is not asking for 432 maximum rate control. The notifier MAY inform the subscriber about 433 such local policy maximum rate using the "max-rate" Subscription- 434 State header field parameter included in subsequent NOTIFY requests. 436 Retransmissions of NOTIFY requests are not affected by the maximum 437 rate mechanism, i.e., the maximum rate mechanism only applies to the 438 generation of new transactions. In other words, the maximum rate 439 mechanism does not in any way break or modify the normal 440 retransmission mechanism specified in RFC 3261 [RFC3261]. 442 5.3. Selecting the Maximum Rate 444 Special care needs to be taken when selecting the maximum rate. For 445 example, the maximum rate could potentially set a minimum time value 446 between notifications that exceeds the subscription expiration value. 447 Such a configuration would effectively quench the notifier, resulting 448 in exactly two notifications to be generated. If the subscriber 449 requests a maximum rate that would result in no notification before 450 the subscription expiration, the notifier MUST increase the maximum 451 rate and set it to the reciprocal value of the subscription 452 expiration time left. According to RFC 3265 [RFC3265] the notifier 453 may also shorten the subscription expiry anytime during an active 454 subscription. If the subscription expiry is shortened during an 455 active subscription, the notifier MUST also increase the "max-rate" 456 value and set it to reciprocal value of the reduced subscription 457 expiration time. 459 In some cases it makes sense to pause the notification stream on an 460 existing subscription dialog on a temporary basis without terminating 461 the subscription, e.g. due to inactivity on the application user 462 interface. Whenever a subscriber discovers the need to perform the 463 notification pause operation, it SHOULD set the maximum rate to the 464 reciprocal value of the remaining subscription expiration value. 465 This results in receiving no further notifications until the 466 subscription expires or the subscriber sends a SUBSCRIBE request 467 resuming notifications. 469 The notifier MAY decide to increase or decrease the proposed "max- 470 rate" value by the subscriber based on its local policy, static 471 configuration or other implementation-determined constraints. In 472 addition, different event packages MAY define additional constraints 473 for the allowed maximum rate ranges. Such constraints are out of the 474 scope of this specification. 476 5.4. The Maximum Rate Mechanism for Resource List Server 478 When applied to a list subscription [RFC4662], the maximum rate 479 mechanism has some additional considerations. Specifically, the 480 maximum rate applies to the aggregate notification stream resulting 481 from the list subscription, rather than explicitly controlling the 482 notification of each of the implied constituent events. Moreover, 483 the RLS can use the maximum rate mechanism on its own to control the 484 rate of the back-end subscriptions to avoid overflowing its buffer. 486 The notifier is responsible for sending out event notifications upon 487 state changes of the subscribed resource. We can model the notifier 488 as consisting of four components: the event state resource(s), the 489 Resource List Server (RLS) (or any other notifier), a notification 490 buffer, and finally the subscriber, or watcher of the event state, as 491 shown in Figure 1. 493 +--------+ 494 | Event | 495 +--------+ |Resource| +--------+ 496 | Event | +--------+ | Event | 497 |Resource| | |Resource| 498 +---.=---+ | +---=----+ 499 `-.. | _.--' 500 ``-._ | _.--' 501 +'--'--'-+ 502 |Resource| 503 | List | 504 | Server | 505 +---.----+ 506 | 507 | 508 )--+---( 509 | | .--------. 510 |Buffer|<======'max-rate| 511 | | `--------' 512 )--.---( 513 | 514 | 515 .---+---. 516 | Event | 517 |Watcher| 518 `-------' 520 Figure 1: Model for the Resource List Server (RLS) Supporting 521 Throttling 523 In short, the RLS reads event state changes from the event state 524 resource, either by creating a back end subscription, or by other 525 means; it packages them into event notifications and submits them 526 into the output buffer. The rate at which this output buffer drains 527 is controlled by the subscriber via the maximum rate mechanism. When 528 a set of notifications are batched together, the way in which 529 overlapping resource state is handled depends on the type of the 530 resource state: 532 In theory, there are many buffer policies that the notifier could 533 implement. However, we only concentrate on two practical buffer 534 policies in this specification, leaving additional ones for 535 further study and out of the scope of this specification. These 536 two buffer policies depend on the mode in which the notifier is 537 operating. 539 Full-state: Last (most recent) full state notification of each 540 resource is sent out, and all others in the buffer are discarded. 541 This policy applies to those event packages that carry full-state 542 notifications. 544 Partial-state: The state deltas of each buffered partial 545 notification per resource are merged, and the resulting 546 notification is sent out. This policy applies to those event 547 packages that carry partial-state notifications. 549 5.5. Buffer Policy Description 551 5.5.1. Partial State Notifications 553 With partial notifications, the notifier needs to maintain a separate 554 buffer for each subscriber since each subscriber may have a different 555 value for the maximum rate of notifications. The notifier will 556 always need to keep both a copy of the current full state of the 557 resource F, as well as the last successfully communicated full state 558 view F' of the resource in a specific subscription. The construction 559 of a partial notification then involves creating a difference of the 560 two states, and generating a notification that contains that 561 difference. 563 When the maximum rate mechanism is applied to the subscription, it is 564 important that F' is replaced with F only when the difference of F 565 and F' was already included in a partial state notification to the 566 subscriber allowed by the maximum rate mechanism. Additionally, the 567 notifier implementation SHOULD check to see that the size of an 568 accumulated partial state notification is smaller than the full 569 state, and if not, the notifier SHOULD send the full state 570 notification instead. 572 5.5.2. Full State Notifications 574 With full state notifications, the notifier only needs to keep the 575 full state of the resource, and when that changes, send the resulting 576 notification over to the subscriber. 578 When the maximum rate mechanism is applied to the subscription, the 579 notifier receives the state changes of the resource, and generates a 580 notification. If there is a pending notification, the notifier 581 simply replaces that notification with the new notification, 582 discarding the older state. 584 5.6. Estimated Bandwidth Savings 586 It is difficult to estimate the total bandwidth savings accrued by 587 using the maximum rate mechanism over a subscription, since such 588 estimates will vary depending on the usage scenarios. However, it is 589 easy to see that given a subscription where several full state 590 notifications would have normally been sent in any given interval set 591 by the "max-rate" parameter, only a single notification is sent 592 during the same interval when using the maximum rate mechanism 593 yielding bandwidth savings of several times the notification size. 595 With partial-state notifications, drawing estimates is further 596 complicated by the fact that the states of consecutive updates may or 597 may not overlap. However, even in the worst case scenario, where 598 each partial update is to a different part of the full state, a rate 599 controlled notification merging all of these n partial states 600 together should at a maximum be the size of a full-state update. In 601 this case, the bandwidth savings are approximately n times the size 602 of the header fields of the NOTIFY request. 604 It is also true that there are several compression schemes available 605 that have been designed to save bandwidth in SIP, e.g., SigComp 606 [RFC3320] and TLS compression [RFC3943]. However, such compression 607 schemes are complementary rather than competing mechanisms to the 608 maximum rate mechanism. After all, they can both be applied 609 simultaneously. 611 6. Operation of the Minimum Rate Mechanism 613 6.1. Subscriber Behavior 615 A subscriber that wishes to apply a minimum rate to notifications in 616 a subscription MUST construct a SUBSCRIBE request that includes the 617 "min-rate" Event header field parameter specifying the requested 618 minimum number of notifications per second. The value of this 619 parameter is the reciprocal value of the "max-interval" parameter, 620 the maximum time interval between two consecutive notifications. The 621 value of the "max-interval" parameter is a positive decimal integer 622 measured in seconds. For example, when the subscriber wants to 623 receive notifications at least once in every seven seconds, then it 624 sets the value of the "min-rate" parameter to 1/7. 626 A subscriber that wishes to update the previously agreed minimum rate 627 of notifications MUST include the updated "min-rate" Event header 628 field parameter in a subsequent SUBSCRIBE request or a 2xx response 629 to the NOTIFY request. 631 A subscriber that wishes to remove the minimum rate control from 632 notifications MUST indicate so by not including a "min-rate" Event 633 header field parameter in a subsequent SUBSCRIBE request or a 2xx 634 response to the NOTIFY request. 636 The main consequence for the subscriber when applying the minimum 637 rate mechanism is that it can receive a notification even if nothing 638 has changed in the current state of the notifier. However, RFC 5839 639 [RFC5839] defines a mechanism that allows suppressing a NOTIFY 640 request or a NOTIFY request body if the state has not changed. 642 6.2. Notifier Behavior 644 A notifier that supports the minimum rate mechanism MUST extract the 645 value of the "min-rate" Event header field parameter from a SUBSCRIBE 646 request or a 2xx response to the NOTIFY request and use it as the 647 suggested minimum number of notifications per second. This value can 648 be adjusted by the notifier, as defined in Section 6.3. 650 A compliant notifier MUST reflect back the possibly adjusted minimum 651 rate of notifications in a "min-rate" Subscription-State header field 652 parameter of the subsequent NOTIFY requests. The indicated "min- 653 rate" value is adopted by the notifier, and the notification rate is 654 adjusted accordingly. 656 A notifier that does not understand this extension, will not reflect 657 the "min-rate" Subscription-State header field parameter in the 658 NOTIFY requests; the absence of this parameter indicates to the 659 subscriber that no rate control is supported by the notifier. 661 A compliant notifier MUST generate notifications when state changes 662 occur or when the time since the most recent notification exceeds the 663 "max-interval" value, the reciprocal value of the "min-rate" 664 parameter. Depending on the event package and subscriber preferences 665 indicated in the SUBSCRIBE request, the NOTIFY request sent as a 666 result of a minimum rate mechanism MUST contain either the current 667 full state or the partial state showing the difference between the 668 current state and the last successfully communicated state. If the 669 subscriber and the notifier support the procedures in RFC 5839 670 [RFC5839] the complete NOTIFY request or the NOTIFY request body can 671 be suppressed if the state has not changed from the previous 672 notification. 674 Retransmissions of NOTIFY requests are not affected by the minimum 675 rate mechanism, i.e., the minimum rate mechanism only applies to the 676 generation of new transactions. In other words, the minimum rate 677 mechanism does not in any way break or modify the normal 678 retransmission mechanism. 680 6.3. Selecting the Minimum Rate 682 The minimum rate mechanism can be used to generate a lot of 683 notifications, creating additional processing load for the notifier. 684 Some of the notifications may also be unnecessary possibly repeating 685 already known state information to the subscriber. It is difficult 686 to provide generic guidelines for the acceptable minimum rate value 687 ranges, however the subscriber SHOULD request for the lowest possible 688 minimum rate. Different event packages MAY define additional 689 constraints for the allowed minimum rate values. Such constraints 690 are out of the scope of this specification. 692 The notifier MAY decide to increase or decrease the proposed "min- 693 rate" value by the subscriber based on its local policy, static 694 configuration or other implementation-determined constraints. 696 7. Operation of the Adaptive Minimum Rate Mechanism 698 7.1. Subscriber Behavior 700 A subscriber that wishes to apply an adaptive minimum rate to 701 notifications in a subscription MUST construct a SUBSCRIBE request 702 that includes the "adaptive-min-rate" Event header field parameter 703 specifying an adaptive minimum number of notifications per second. 704 The value of this parameter is the reciprocal value of the "adaptive- 705 max-interval" parameter, the adaptive maximum time interval between 706 two consecutive notifications. The value of the "adaptive-max- 707 interval" parameter is a positive decimal integer measured in 708 seconds. For example, when the subscriber wants to receive 709 notifications once in every seven seconds on an average, then it sets 710 the value of the "adaptive-min-rate" parameter to 1/7. 712 A subscriber that wishes to update the previously agreed adaptive 713 minimum rate of notifications MUST include the updated "adaptive-min- 714 rate" Event header field parameter in a subsequent SUBSCRIBE request 715 or a 2xx response to the NOTIFY request. 717 A subscriber that wishes to remove the adaptive minimum rate control 718 from notifications MUST indicate so by not including a "adaptive-min- 719 rate" Event header field parameter in a subsequent SUBSCRIBE request 720 or a 2xx response to the NOTIFY request. 722 The main consequence for the subscriber when applying the adaptive 723 minimum rate mechanism is that it can receive a notification even if 724 nothing has changed in the current state of the notifier. However, 725 RFC 5839 [RFC5839] defines a mechanism that allows suppressing a 726 NOTIFY request or a NOTIFY request body if the state has not changed. 728 7.2. Notifier Behavior 730 A notifier that supports the adaptive minimum rate mechanism MUST 731 extract the value of the "adaptive-min-rate" Event header parameter 732 from a SUBSCRIBE request or a 2xx response to the NOTIFY request and 733 use it to calculate the actual maximum time between two notifications 734 as defined in Section 7.4. 736 The "adaptive-min-rate" value can be adjusted by the notifier, as 737 defined in Section 7.3. 739 A compliant notifier MUST reflect back the possibly adjusted adaptive 740 minimum rate of notifications in an "adaptive-min-rate" Subscription- 741 State header field parameter of the subsequent NOTIFY requests. The 742 indicated "adaptive-min-rate" value is adopted by the notifier, and 743 the notification rate is adjusted accordingly. 745 A notifier that does not understand this extension will not reflect 746 the "adaptive-min-rate" Subscription-State header parameter in the 747 NOTIFY requests; the absence of this parameter indicates to the 748 subscriber that no rate control is supported by the notifier. 750 A compliant notifier MUST generate notifications when state changes 751 occur or when the time since the most recent notification exceeds the 752 value calculated using the formula defined in Section 7.4. Depending 753 on the event package and subscriber preferences indicated in the 754 SUBSCRIBE request, the NOTIFY request sent as a result of a minimum 755 rate mechanism MUST contain either the current full state or the 756 partial state showing the difference between the current state and 757 the last successfully communicated state. If the subscriber and the 758 notifier support the procedures in RFC 5839 [RFC5839] the complete 759 NOTIFY request or the NOTIFY request body can be suppressed if the 760 state has not changed from the previous notification. 762 The adaptive minimum rate mechanism is implemented as follows: 764 1) When a subscription is first created, the notifier creates a 765 record ("count" parameter) that keeps track of the number of 766 notifications that have been sent in the "period". The "count" 767 parameter is initialized to contain a history of having sent a 768 "period * adaptive-min-rate" number of notifications for the 769 "period". 771 2) The "timeout" value is calculated according to the equation given 772 in Section 7.4. 774 3) If the timeout period passes without a NOTIFY request being sent 775 in the subscription, then the current resource state is sent 776 (subject to any filtering associated with the subscription). 778 4) Whenever a NOTIFY request is sent (regardless of whether due to a 779 "timeout" event or a state change), the notifier updates the 780 notification history record stored in the "count" parameter, 781 recalculates the value of "timeout," and returns to step 3. 783 Retransmissions of NOTIFY requests are not affected by the timeout, 784 i.e., the timeout only applies to the generation of new transactions. 785 In other words, the timeout does not in any way break or modify the 786 normal retransmission mechanism specified in RFC 3261 [RFC3261]. 788 7.3. Selecting the Adaptive Minimum Rate 790 The adaptive minimum rate mechanism can be used to generate a lot of 791 notifications, creating additional processing load for the notifier. 792 Some of the notifications may also be unnecessary possibly repeating 793 already known state information to the subscriber. It is difficult 794 to provide generic guidelines for the acceptable adaptive minimum 795 rate value ranges, however the subscriber SHOULD request for the 796 lowest possible adaptive minimum rate value. Different event 797 packages MAY define additional constraints for the allowed adaptive 798 minimum rate values. Such constraints are out of the scope of this 799 specification. 801 The notifier MAY decide to increase or decrease the proposed 802 "adaptive-min-rate" value based on its local policy, static 803 configuration or other implementation-determined constraints. 805 7.4. Calculating the Timeout 807 The formula used to vary the absolute pacing in a way that will meet 808 the adaptive minimum rate requested over the period is given in 809 equation (1): 811 timeout = count /(adaptive-min-rate ^ 2) * period (1) 813 The output of the formula, "timeout", is the time to the next 814 notification, expressed in seconds. The formula has three inputs: 816 adaptive-min-rate: The value of the "adaptive-min-rate" parameter 817 conveyed in the Subscription-State header field. 819 period: The rolling average period, in seconds. The granularity of 820 the values for the "period" parameter is set by local policy at 821 the notifier, however the notifier MUST choose a value greater 822 than the value of the "adaptive-max-interval" parameter, the 823 reciprocal value of the "adaptive-min-rate" parameter. It is also 824 RECOMMENDED that the notifier chooses a "period" parameter several 825 times larger than "adaptive-max-interval" parameter in order to 826 maximize the effectiveness of the equation (1). It is an 827 implementation decision whether the notifier uses the same value 828 of the "period" parameter for all subscriptions or individual 829 values for each subscription. 831 count: The number of notifications that have been sent during the 832 last "period" of seconds not including any retransmissions of 833 requests. 835 In case both the maximum rate and the adaptive minimum rate 836 mechanisms are used in the same subscription the formula used to 837 dynamically calculate the timeout is given in equation (2): 839 timeout = MAX[1/max-rate, count /(adaptive-min-rate ^ 2) * period] (2) 841 max-rate: The value of the "max-rate" parameter conveyed in the 842 Subscription-State header field. 844 The formula in (2) makes sure that for all the possible values of the 845 "max-rate" and "adaptive-min-rate" parameters, with "adaptive-min- 846 rate" < "max-rate", the timeout never results in a lower value than 847 "min-interval", the reciprocal value of the "max-rate" parameter. 849 In some situation it may be beneficial for the notifier to achieve an 850 adaptive minimum rate in a different way than the algorithm detailed 851 in this document allows. However, the notifier MUST comply with any 852 "max-rate" or "min-rate" parameters that have been negotiated. 854 8. Usage of the Maximum Rate, Minimum Rate and Adaptive Minimum Rate 855 Mechanisms in a combination 857 Applications can subscribe to an event package using all the rate 858 control mechanisms individually, or in combination; in fact there is 859 no technical incompatibility among them. However there are some 860 combinations of the different rate control mechanisms that make 861 little sense to be used together. This section lists all the 862 combinations that are possible to insert in a subscription; the 863 utility to use each combination in a subscription is also analyzed. 865 maximum rate and minimum rate: This combination allows to reduce the 866 notification rate, but at the same time assures the reception of a 867 notification every time the most recent notification exceeds a 868 specified interval. 870 A subscriber SHOULD choose a "min-rate" value lower than the "max- 871 rate" value, otherwise the notifier MUST adjust the subscriber 872 provided "min-rate" value to a value equal to or lower than the 873 "max-rate" value. 875 maximum rate and adaptive minimum rate: It works in a similar way as 876 the combination above, but with the difference that the interval 877 at which notifications are assured changes dynamically. 879 A subscriber SHOULD choose a "adaptive-min-rate" value lower than 880 the "max-rate" value, otherwise the notifier MUST adjust the 881 subscriber provided "adaptive-min-rate" value to a value equal to 882 or lower than the "max-rate" value. 884 minimum rate and adaptive minimum rate: When using the adaptive 885 minimum rate mechanism, frequent state changes in a short period 886 can result in no notifications for a longer period following the 887 short period. The addition of the minimum rate mechanism ensures 888 the subscriber always receives notifications after a specified 889 interval. 891 A subscriber SHOULD choose a "min-rate" value lower than the 892 "adaptive-min-rate" value, otherwise the notifier MUST NOT 893 consider the "min-rate" value. 895 maximum rate, minimum rate and adaptive minimum rate: This 896 combination makes little sense to be used although not forbidden. 898 A subscriber SHOULD choose a "min-rate" and "adaptive-min-rate" 899 values lower than the "max-rate" value, otherwise the notifier 900 MUST adjust the subscriber provided "min-rate" and "adaptive-min- 901 rate" values to a value equal to or lower than the "max-rate" 902 value. 904 A subscriber SHOULD choose a "min-rate" value lower than the 905 "adaptive-min-rate" value, otherwise the notifier MUST NOT 906 consider the "min-rate" value. 908 9. Protocol Element Definitions 910 This section describes the protocol extensions required for the 911 different rate control mechanisms. 913 9.1. "max-rate", "min-rate" and "adaptive-min-rate" Header Field 914 Parameters 916 The "max-rate", "min-rate" and "adaptive-min-rate" parameters are 917 added to the rule definitions of the Event header field and the 918 Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage 919 of this parameter is described in Section 5, Section 6 and Section 7. 921 9.2. Grammar 923 This section describes the Augmented BNF [RFC5234] definitions for 924 the new header field parameters. Note that we derive here from the 925 ruleset present in RFC 3265 [RFC3265], adding additional alternatives 926 to the alternative sets of "event-param" and "subexp-params" defined 927 therein. The "delta-seconds" element is defined in RFC 3261 928 [RFC3261]. 930 event-param =/ max-rate-param / min-rate-param / amin-rate-param 931 subexp-params =/ max-rate-param / min-rate-param / amin-rate-param 932 max-rate-param = "max-rate" EQUAL ("1" SLASH delta-seconds) 933 min-rate-param = "min-rate" EQUAL ("1" SLASH delta-seconds) 934 amin-rate-param = "adaptive-min-rate" EQUAL ("1" SLASH delta-seconds) 936 9.3. Event Header Field Usage in Responses to the NOTIFY request 938 This table expands the table described in Section 7.2 of RFC 3265 939 [RFC3265] allowing the Event header field to appear in a 2xx response 940 to a NOTIFY request. The use of the Event header field in responses 941 other than 2xx to NOTIFY requests is undefined and out of scope of 942 this specification. 944 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 945 ----------------------------------------------------------------- 946 Event 2xx - - - - - - - - o 948 A subscriber that wishes to update the previously agreed value for 949 maximum, minimum or adaptive minimum rate of notifications MUST 950 include all desired values for the "max-rate", "min-rate" and 951 "adaptive-min-rate" parameters in an Event header field of the 2xx 952 response to a NOTIFY request. Any of the other header field 953 parameters currently defined for the Event header field by other 954 specifications do not have a meaning if the Event header field is 955 included in the 2xx response to the NOTIFY request. These header 956 field parameters MUST be ignored by the notifier, if present. 958 The event type listed in the Event header field of the 2xx response 959 to the NOTIFY request MUST match the event type of the Event header 960 field in the corresponding NOTIFY request. 962 10. IANA Considerations 964 This specification registers three new SIP header field parameters, 965 defined by the following information which is to be added to the 966 Header Field Parameters and Parameter Values sub-registry under 967 http://www.iana.org/assignments/sip-parameters. 969 Predefined 970 Header Field Parameter Name Values Reference 971 -------------------- --------------- ---------- --------- 972 Event max-rate No [RFCxxxx] 973 Subscription-State max-rate No [RFCxxxx] 974 Event min-rate No [RFCxxxx] 975 Subscription-State min-rate No [RFCxxxx] 976 Event adaptive-min-rate No [RFCxxxx] 977 Subscription-State adaptive-min-rate No [RFCxxxx] 979 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 980 this specification, when assigned.) 982 This specification also updates the reference defining the Event 983 header field in the Header Fields sub-registry under 984 http://www.iana.org/assignments/sip-parameters. 986 Header Name compact Reference 987 ----------- ------- ------------------ 988 Event o [RFC3265][RFCxxxx] 990 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 991 this specification, when assigned.) 993 11. Security Considerations 995 Naturally, the security considerations listed in RFC 3265 [RFC3265], 996 which the rate control mechanisms described in this document extends, 997 apply in entirety. In particular, authentication and message 998 integrity SHOULD be applied to subscriptions with this extension. 1000 RFC 3265 [RFC3265] recommends the integrity protection of the Event 1001 header field of SUBSCRIBE requests. Implementations of this 1002 extension SHOULD also provide integrity protection for the Event 1003 header field included in the 2xx response to the NOTIFY request. 1004 Without integrity protection an eavesdropper could see and modify the 1005 Event header field; or it could also manipulate the transmission of a 1006 200 (OK) response to the NOTIFY request in order to suppress or flood 1007 notifications without the subscriber seeing what caused the problem. 1009 When the maximum rate mechanism involves partial state notifications, 1010 the security considerations listed in RFC 5263 [RFC5263] apply in 1011 entirety. 1013 12. Acknowledgments 1015 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 1016 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 1017 Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, 1018 Michael Procter and Janet Gunn for support and/or review of this 1019 work. 1021 Thanks to Brian Rosen for the idea of the minimum and adaptive 1022 minimum rate mechanisms, and Adam Roach for the work on the algorithm 1023 for the adaptive minimum rate mechanism and other feedback. 1025 13. References 1027 13.1. Normative References 1029 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1030 Requirement Levels", BCP 14, RFC 2119, March 1997. 1032 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1033 A., Peterson, J., Sparks, R., Handley, M., and E. 1034 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1035 June 2002. 1037 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1038 Event Notification", RFC 3265, June 2002. 1040 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1041 Initiation Protocol (SIP) Event Notification Extension for 1042 Resource Lists", RFC 4662, August 2006. 1044 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1045 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1047 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 1048 Khartabil, "Session Initiation Protocol (SIP) Extension 1049 for Partial Notification of Presence Information", 1050 RFC 5263, September 2008. 1052 13.2. Informative References 1054 [I-D.ietf-geopriv-loc-filters] 1055 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 1056 Location Notifications in the Session Initiation Protocol 1057 (SIP)", draft-ietf-geopriv-loc-filters-11 (work in 1058 progress), March 2010. 1060 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 1061 Liu, Z., and J. Rosenberg, "Signaling Compression 1062 (SigComp)", RFC 3320, January 2003. 1064 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1065 Package for Registrations", RFC 3680, March 2004. 1067 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1068 Indication Event Package for the Session Initiation 1069 Protocol (SIP)", RFC 3842, August 2004. 1071 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1072 Initiation Protocol (SIP)", RFC 3856, August 2004. 1074 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 1075 Package for the Session Initiation Protocol (SIP)", 1076 RFC 3857, August 2004. 1078 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 1079 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 1080 November 2004. 1082 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 1083 Initiation Protocol (SIP) Events for Conditional Event 1084 Notification", RFC 5839, May 2010. 1086 Authors' Addresses 1088 Aki Niemi 1089 Nokia 1090 P.O. Box 407 1091 NOKIA GROUP, FIN 00045 1092 Finland 1094 Phone: +358 50 389 1644 1095 Email: aki.niemi@nokia.com 1097 Krisztian Kiss 1098 Nokia 1099 200 South Mathilda Ave 1100 Sunnyvale, CA 94086 1101 US 1103 Phone: +1 650 391 5969 1104 Email: krisztian.kiss@nokia.com 1106 Salvatore Loreto 1107 Ericsson 1108 Hirsalantie 11 1109 Jorvas 02420 1110 Finland 1112 Email: salvatore.loreto@ericsson.com