idnits 2.17.1 draft-ietf-sipcore-event-rate-control-07.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 969 has weird spacing: '...n-State max-...' == Line 971 has weird spacing: '...n-State min-...' == Line 973 has weird spacing: '...n-State adap...' == Line 982 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 (April 1, 2011) is 4774 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 984, 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: October 3, 2011 Ericsson 7 April 1, 2011 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-07 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 October 3, 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 . . . . . . . . . . . . . . . . . 20 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 number of notifications per second. 160 min-rate: specifies a minimum number of notifications per second. 162 adaptive-minimum-rate: specifies an adaptive minimum number of 163 notifications per second. 165 These mechanisms are applicable to any event subscription, both 166 single event subscription and event list subscription. A notifier 167 compliant to this specification will adjust the rate at which it 168 generates notifications. 170 2. Definitions and Document Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119] and 175 indicate requirement levels for compliant implementations. 177 Indented passages such as this one are used in this document to 178 provide additional information and clarifying text. They do not 179 contain normative protocol behavior. 181 3. Overview 183 3.1. Use Case for Limiting the Maximum Rate of Notifications 185 A presence client in a mobile device contains a list of 100 buddies 186 or presentities. In order to decrease the processing and network 187 load of watching 100 presentities, the presence client has employed a 188 Resource List Server (RLS) with the list of buddies, and therefore 189 only needs a single subscription to the RLS in order to receive 190 notifications of the presence state of the resource list. 192 In order to control the buffer policy of the RLS, the presence client 193 sets a maximum rate of notifications. The RLS will buffer 194 notifications that are generated faster than they are allowed to be 195 sent due to the maximum rate and batch all of the buffered state 196 changes together in a single notification. The maximum rate applies 197 to the overall resource list, which means that there is a hard cap 198 imposed by the maximum rate to the number of notifications per second 199 the presence client can expect to receive. 201 The presence client can also modify the maximum rate of notifications 202 during the lifetime of the subscription. For example, if the mobile 203 device detects inactivity from the user for a period of time, the 204 presence client can simply pause notifications by choosing a "max- 205 rate" parameter that allows only a single notification for the 206 remainder of the subscription lifetime. When the user becomes active 207 again, the presence client can resume the stream of notifications by 208 re-subscribing with a "max-rate" parameter set to the earlier used 209 value. Application of the mechanism defined by RFC 5839 [RFC5839] 210 can also eliminate the transmission of a (full-state) notification 211 carrying the latest resource state to the presence client after a 212 subscription refresh. 214 3.2. Use Case for Setting a Minimum Rate for Notifications 216 A location application is monitoring the movement of a target. In 217 order to decrease the processing and network load, the location 218 application has made a subscription to a Location Server with a set 219 of location filters [I-D.ietf-geopriv-loc-filters] that specify 220 trigger criteria, e.g. to send an update only when the target has 221 moved at least n meters. However, the application is also interested 222 in receiving the current state periodically even if the state of the 223 target has not changed enough to satisfy any of the trigger criteria, 224 e.g., has not moved at least n meters within the period. 226 The location application sets a minimum rate of notifications and 227 include it in the subscription sent to the Location Server. The "min- 228 rate" parameter indicates the minimum number of notifications per 229 second the notifier needs to generate. 231 The location application can also modify the minimum rate of 232 notifications during the lifetime of the subscription. For example, 233 when the subscription to the movement of a target is made, the 234 notifier may not have the location information available. Thus, the 235 first notification might be empty, or certain values might be absent. 236 An important use case is placing constraints on when complete state 237 should be provided after creating the subscription. Once state is 238 acquired and the second notification is sent, the subscriber updates 239 or changes the "min-rate" parameter to a more sensible value. This 240 update can be performed in the response to the notification that 241 contains the complete state information. 243 3.3. Use Case for Specifying an Adaptive Minimum Rate of Notifications 245 The minimum rate mechanism introduces a static and instantaneous rate 246 control without the functionality to increase or decrease the 247 notification rate adaptively. However, there are some applications 248 that would work better with an adaptive minimum rate control. 250 A location application is monitoring the movement of a target. In 251 order to decrease the processing in the application, the location 252 application wants to make a subscription that dynamically decreases 253 the minimum rate of notifications if the target has sent out several 254 notifications recently. However, if there have have been only few 255 recent notifications by the target, the location application wants 256 the minimum rate of notifications to increase. 258 The location application sets an adaptive minimum rate of 259 notifications and include it in the subscription sent to the Location 260 Server. The "adaptive-min-rate" parameter value is used by the 261 notifier to dynamically calculate the actual maximum time between two 262 notifications. In order to dynamically calculate the maximum time, 263 the notifier takes into consideration the rate at which notifications 264 have been sent recently. In the adaptive minimum rate mechanism the 265 notifier can increase or decrease the notification rate compared to 266 the minimum rate mechanism based on the recent number of 267 notifications sent out in the last period. 269 The location application can also modify the "adaptive-min-rate" 270 parameter during the lifetime of the subscription. 272 3.4. Requirements 274 REQ1: The subscriber must be able to set a maximum rate of 275 notifications in a specific subscription. 277 REQ2: The subscriber must be able to set a minimum rate of 278 notifications in a specific subscription. 280 REQ3: The subscriber must be able to set an adaptive minimum rate 281 of notifications in a specific subscription, which adjusts 282 the minimum rate of notifications based on a moving average. 284 REQ4: It must be possible to apply the maximum rate, the minimum 285 rate and the adaptive minimum rate mechanisms all together, 286 or in any combination, in a specific subscription. 288 REQ5: It must be possible to use any of the different rate control 289 mechanisms in subscriptions to any events. 291 REQ6: It must be possible to use any of the different rate control 292 mechanisms together with any other event filtering 293 mechanisms. 295 REQ7: The notifier must be allowed to use a policy in which the 296 maximum rate, minimum rate and adaptive minimum rate 297 parameters are adjusted from the value given by the 298 subscriber. 300 For example, due to congestion reasons, local policy at 301 the notifier could temporarily dictate a policy that in 302 effect further decreases the maximum rate of 303 notifications. In another example, the notifier can 304 increase the subscriber proposed maximum rate so that at 305 least one notification is generated during the remainder 306 of the subscription lifetime. 308 REQ8: The different rate control mechanisms must address corner 309 cases for setting the notification rates appropriately. At a 310 minimum, the mechanisms must address the situation when the 311 time between two notifications would exceed the subscription 312 duration and should provide procedures for avoiding this 313 situation. 315 REQ9: The different rate control mechanisms must be possible to be 316 invoked, modified, or removed in the course of an active 317 subscription. 319 REQ10: The different rate control mechanisms must allow for the 320 application of authentication and integrity protection 321 mechanisms to subscriptions invoking that mechanism. 323 4. Basic Operations 325 4.1. Subscriber Behavior 327 In general, the way in which a subscriber generates SUBSCRIBE 328 requests and processes NOTIFY requests is according to RFC 3265 329 [RFC3265]. 331 A subscriber that wants to have a maximum, minimum or adaptive 332 minimum rate of event notifications in a specific event subscription 333 does so by including a "max-rate", "min-rate" or "adaptive-min-rate" 334 Event header field parameter(s) as part of the SUBSCRIBE request. 336 A subscriber that wants to update a previously agreed event rate 337 control parameter does so by including the updated "max-rate", "min- 338 rate" or "adaptive-min-rate" Event header field parameter(s) as part 339 of a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY 340 request. If the subscriber did not include at least one of the "max- 341 rate", "min-rate" or "adaptive-min-rate" header field parameters in 342 the most recent SUBSCRIBE request in a given dialog, the subscriber 343 MUST NOT include an Event header field with any of those parameters 344 in a 2xx response to a NOTIFY request in that dialog. 346 4.2. Notifier Behavior 348 In general, the way in which a notifier processes SUBSCRIBE requests 349 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 351 A notifier that supports the different rate control mechanisms MUST 352 adjust its rate of notification according to the rate control values 353 agreed with the subscriber. If the notifier needs to lower the 354 subscription expiration value or if a local policy or other 355 implementation-determined constraint at the notifier can not satisfy 356 the rate control request, then the notifier can adjust (i.e. increase 357 or decrease) appropriately the subscriber requested rate control 358 values. The notifier MUST reflect back the possibly adjusted rate 359 control values in a "max-rate", "min-rate" or "adaptive-min-rate" 360 Subscription-State header field parameter of the subsequent NOTIFY 361 requests. 363 5. Operation of the Maximum Rate Mechanism 365 5.1. Subscriber Behavior 367 A subscriber that wishes to apply a maximum rate to notifications in 368 a subscription MUST construct a SUBSCRIBE request that includes the 369 "max-rate" Event header field parameter. This parameter specifies 370 the requested maximum number of notifications per second that is 371 equivalent to the reciprocal value of the minimum time interval 372 between two consecutive notifications. The value of this parameter 373 is a positive decimal fraction measured in 1/seconds. For example, 374 when the subscriber wants to receive notifications no more frequently 375 than once in every seven seconds, then it sets the value of the "max- 376 rate" parameter to 1/7. 378 Note that the witnessed time between two consecutive received 379 notifications may not conform to the "max-rate" value for a number 380 of reasons. For example, network jitter and retransmissions may 381 result in the subscriber receiving the notifications more frequent 382 than the "max-rate" value recommends. 384 A subscriber that wishes to update the previously agreed maximum rate 385 of notifications MUST include the updated "max-rate" Event header 386 field parameter in a subsequent SUBSCRIBE request or a 2xx response 387 to the NOTIFY request. 389 A subscriber that wishes to remove the maximum rate control from 390 notifications MUST indicate so by not including a "max-rate" Event 391 header field parameter in a subsequent SUBSCRIBE request or a 2xx 392 response to the NOTIFY request. 394 There are two main consequences for the subscriber when applying the 395 maximum rate mechanism: state transitions may be lost and event 396 notifications may be delayed. If either of these side effects 397 constitute a problem to the application that utilizes the event 398 notifications, developers are instructed not to use the mechanism. 400 5.2. Notifier Behavior 402 A notifier that supports the maximum rate mechanism MUST extract the 403 value of the "max-rate" Event header parameter from a SUBSCRIBE 404 request or a 2xx response to the NOTIFY request and use it as the 405 suggested maximum number of notifications per second. This value can 406 be adjusted by the notifier, as defined in Section 5.3. 408 A compliant notifier MUST reflect back the possibly adjusted maximum 409 rate of notifications in a "max-rate" Subscription-State header field 410 parameter of the subsequent NOTIFY requests. The indicated "max- 411 rate" value is adopted by the notifier, and the notification rate is 412 adjusted accordingly. 414 A notifier that does not understand this extension will not reflect 415 the "max-rate" Subscription-State header field parameter in the 416 NOTIFY requests; the absence of this parameter indicates to the 417 subscriber that no rate control is supported by the notifier. 419 A compliant notifier MUST NOT generate notifications more frequently 420 than the maximum rate allows for, except when generating the 421 notification either upon receipt of a SUBSCRIBE request (the first 422 notification), when the subscription state is changing from "pending" 423 to "active" state or upon termination of the subscription (the last 424 notification). Such notifications reset the timer for the next 425 notification. 427 When a local policy dictates a maximum rate for notifications, a 428 notifier will not generate notifications more frequently than the 429 local policy maximum rate, even if the subscriber is not asking for 430 maximum rate control. The notifier MAY inform the subscriber about 431 such local policy maximum rate using the "max-rate" Subscription- 432 State header field parameter included in subsequent NOTIFY requests. 434 Retransmissions of NOTIFY requests are not affected by the maximum 435 rate mechanism, i.e., the maximum rate mechanism only applies to the 436 generation of new transactions. In other words, the maximum rate 437 mechanism does not in any way break or modify the normal 438 retransmission mechanism specified in RFC 3261 [RFC3261]. 440 5.3. Selecting the Maximum Rate 442 Special care needs to be taken when selecting the maximum rate. For 443 example, the maximum rate could potentially set a minimum time value 444 between notifications that exceeds the subscription expiration value. 445 Such a configuration would effectively quench the notifier, resulting 446 in exactly two notifications to be generated. If the subscriber 447 requests a maximum rate that would result in no notification before 448 the subscription expiration, the notifier MUST increase the maximum 449 rate and set it to the reciprocal value of the subscription 450 expiration time left. According to RFC 3265 [RFC3265] the notifier 451 may also shorten the subscription expiry anytime during an active 452 subscription. If the subscription expiry is shortened during an 453 active subscription, the notifier MUST also increase the "max-rate" 454 value and set it to reciprocal value of the reduced subscription 455 expiration time. 457 In some cases it makes sense to pause the notification stream on an 458 existing subscription dialog on a temporary basis without terminating 459 the subscription, e.g. due to inactivity on the application user 460 interface. Whenever a subscriber discovers the need to perform the 461 notification pause operation, it SHOULD set the maximum rate to the 462 reciprocal value of the remaining subscription expiration value. 463 This results in receiving no further notifications until the 464 subscription expires or the subscriber sends a SUBSCRIBE request 465 resuming notifications. 467 The notifier MAY decide to increase or decrease the proposed "max- 468 rate" value by the subscriber based on its local policy, static 469 configuration or other implementation-determined constraints. In 470 addition, different event packages MAY define additional constraints 471 for the allowed maximum rate ranges. Such constraints are out of the 472 scope of this specification. 474 5.4. The Maximum Rate Mechanism for Resource List Server 476 When applied to a list subscription [RFC4662], the maximum rate 477 mechanism has some additional considerations. Specifically, the 478 maximum rate applies to the aggregate notification stream resulting 479 from the list subscription, rather than explicitly controlling the 480 notification of each of the implied constituent events. Moreover, 481 the RLS can use the maximum rate mechanism on its own to control the 482 rate of the back-end subscriptions to avoid overflowing its buffer. 484 The notifier is responsible for sending out event notifications upon 485 state changes of the subscribed resource. We can model the notifier 486 as consisting of four components: the event state resource(s), the 487 Resource List Server (RLS) (or any other notifier), a notification 488 buffer, and finally the subscriber, or watcher of the event state, as 489 shown in Figure 1. 491 +--------+ 492 | Event | 493 +--------+ |Resource| +--------+ 494 | Event | +--------+ | Event | 495 |Resource| | |Resource| 496 +---.=---+ | +---=----+ 497 `-.. | _.--' 498 ``-._ | _.--' 499 +'--'--'-+ 500 |Resource| 501 | List | 502 | Server | 503 +---.----+ 504 | 505 | 506 )--+---( 507 | | .--------. 508 |Buffer|<======'max-rate| 509 | | `--------' 510 )--.---( 511 | 512 | 513 .---+---. 514 | Event | 515 |Watcher| 516 `-------' 518 Figure 1: Model for the Resource List Server (RLS) Supporting 519 Throttling 521 In short, the RLS reads event state changes from the event state 522 resource, either by creating a back end subscription, or by other 523 means; it packages them into event notifications and submits them 524 into the output buffer. The rate at which this output buffer drains 525 is controlled by the subscriber via the maximum rate mechanism. When 526 a set of notifications are batched together, the way in which 527 overlapping resource state is handled depends on the type of the 528 resource state: 530 In theory, there are many buffer policies that the notifier could 531 implement. However, we only concentrate on two practical buffer 532 policies in this specification, leaving additional ones for 533 further study and out of the scope of this specification. These 534 two buffer policies depend on the mode in which the notifier is 535 operating. 537 Full-state: Last (most recent) full state notification of each 538 resource is sent out, and all others in the buffer are discarded. 539 This policy applies to those event packages that carry full-state 540 notifications. 542 Partial-state: The state deltas of each buffered partial 543 notification per resource are merged, and the resulting 544 notification is sent out. This policy applies to those event 545 packages that carry partial-state notifications. 547 5.5. Buffer Policy Description 549 5.5.1. Partial State Notifications 551 With partial notifications, the notifier needs to maintain a separate 552 buffer for each subscriber since each subscriber may have a different 553 value for the maximum rate of notifications. The notifier will 554 always need to keep both a copy of the current full state of the 555 resource F, as well as the last successfully communicated full state 556 view F' of the resource in a specific subscription. The construction 557 of a partial notification then involves creating a difference of the 558 two states, and generating a notification that contains that 559 difference. 561 When the maximum rate mechanism is applied to the subscription, it is 562 important that F' is replaced with F only when the difference of F 563 and F' was already included in a partial state notification to the 564 subscriber allowed by the maximum rate mechanism. Additionally, the 565 notifier implementation SHOULD check to see that the size of an 566 accumulated partial state notification is smaller than the full 567 state, and if not, the notifier SHOULD send the full state 568 notification instead. 570 5.5.2. Full State Notifications 572 With full state notifications, the notifier only needs to keep the 573 full state of the resource, and when that changes, send the resulting 574 notification over to the subscriber. 576 When the maximum rate mechanism is applied to the subscription, the 577 notifier receives the state changes of the resource, and generates a 578 notification. If there is a pending notification, the notifier 579 simply replaces that notification with the new notification, 580 discarding the older state. 582 5.6. Estimated Bandwidth Savings 584 It is difficult to estimate the total bandwidth savings accrued by 585 using the maximum rate mechanism over a subscription, since such 586 estimates will vary depending on the usage scenarios. However, it is 587 easy to see that given a subscription where several full state 588 notifications would have normally been sent in any given interval set 589 by the "max-rate" parameter, only a single notification is sent 590 during the same interval when using the maximum rate mechanism 591 yielding bandwidth savings of several times the notification size. 593 With partial-state notifications, drawing estimates is further 594 complicated by the fact that the states of consecutive updates may or 595 may not overlap. However, even in the worst case scenario, where 596 each partial update is to a different part of the full state, a rate 597 controlled notification merging all of these n partial states 598 together should at a maximum be the size of a full-state update. In 599 this case, the bandwidth savings are approximately n times the size 600 of the header fields of the NOTIFY request. 602 It is also true that there are several compression schemes available 603 that have been designed to save bandwidth in SIP, e.g., SigComp 604 [RFC3320] and TLS compression [RFC3943]. However, such compression 605 schemes are complementary rather than competing mechanisms to the 606 maximum rate mechanism. After all, they can both be applied 607 simultaneously. 609 6. Operation of the Minimum Rate Mechanism 611 6.1. Subscriber Behavior 613 A subscriber that wishes to apply a minimum rate to notifications in 614 a subscription MUST construct a SUBSCRIBE request that includes the 615 "min-rate" Event header field parameter. This parameter specifies 616 the requested minimum number of notifications per second that is 617 equivalent to the reciprocal value of the maximum time interval 618 between two consecutive notifications. The value of this parameter 619 is a positive decimal fraction measured in 1/seconds. For example, 620 when the subscriber wants to receive notifications at least once in 621 every seven seconds, then it sets the value of the "min-rate" 622 parameter to 1/7. 624 A subscriber that wishes to update the previously agreed minimum rate 625 of notifications MUST include the updated "min-rate" Event header 626 field parameter in a subsequent SUBSCRIBE request or a 2xx response 627 to the NOTIFY request. 629 A subscriber that wishes to remove the minimum rate control from 630 notifications MUST indicate so by not including a "min-rate" Event 631 header field parameter in a subsequent SUBSCRIBE request or a 2xx 632 response to the NOTIFY request. 634 The main consequence for the subscriber when applying the minimum 635 rate mechanism is that it can receive a notification even if nothing 636 has changed in the current state of the notifier. However, RFC 5839 637 [RFC5839] defines a mechanism that allows suppressing a NOTIFY 638 request or a NOTIFY request body if the state has not changed. 640 6.2. Notifier Behavior 642 A notifier that supports the minimum rate mechanism MUST extract the 643 value of the "min-rate" Event header field parameter from a SUBSCRIBE 644 request or a 2xx response to the NOTIFY request and use it as the 645 suggested minimum number of notifications per second. This value can 646 be adjusted by the notifier, as defined in Section 6.3. 648 A compliant notifier MUST reflect back the possibly adjusted minimum 649 rate of notifications in a "min-rate" Subscription-State header field 650 parameter of the subsequent NOTIFY requests. The indicated "min- 651 rate" value is adopted by the notifier, and the notification rate is 652 adjusted accordingly. 654 A notifier that does not understand this extension, will not reflect 655 the "min-rate" Subscription-State header field parameter in the 656 NOTIFY requests; the absence of this parameter indicates to the 657 subscriber that no rate control is supported by the notifier. 659 A compliant notifier MUST generate notifications when state changes 660 occur or when the time since the most recent notification exceeds the 661 reciprocal value of the "min-rate" parameter. Depending on the event 662 package and subscriber preferences indicated in the SUBSCRIBE 663 request, the NOTIFY request sent as a result of a minimum rate 664 mechanism MUST contain either the current full state or the partial 665 state showing the difference between the current state and the last 666 successfully communicated state. If the subscriber and the notifier 667 support the procedures in RFC 5839 [RFC5839] the complete NOTIFY 668 request or the NOTIFY request body can be suppressed if the state has 669 not changed from the previous notification. 671 Retransmissions of NOTIFY requests are not affected by the minimum 672 rate mechanism, i.e., the minimum rate mechanism only applies to the 673 generation of new transactions. In other words, the minimum rate 674 mechanism does not in any way break or modify the normal 675 retransmission mechanism. 677 6.3. Selecting the Minimum Rate 679 The minimum rate mechanism can be used to generate a lot of 680 notifications, creating additional processing load for the notifier. 681 Some of the notifications may also be unnecessary possibly repeating 682 already known state information to the subscriber. It is difficult 683 to provide generic guidelines for the acceptable minimum rate value 684 ranges, however the subscriber SHOULD request for the lowest possible 685 minimum rate. Different event packages MAY define additional 686 constraints for the allowed minimum rate values. Such constraints 687 are out of the scope of this specification. 689 The notifier MAY decide to increase or decrease the proposed "min- 690 rate" value by the subscriber based on its local policy, static 691 configuration or other implementation-determined constraints. 693 7. Operation of the Adaptive Minimum Rate Mechanism 695 7.1. Subscriber Behavior 697 A subscriber that wishes to apply an adaptive minimum rate to 698 notifications in a subscription MUST construct a SUBSCRIBE request 699 that includes the "adaptive-min-rate" Event header field parameter. 700 This parameter specifies an adaptive minimum number of notifications 701 per second that is equivalent to the the reciprocal value of the 702 adaptive maximum time interval between two consecutive notifications. 703 The value of this parameter is a positive decimal fraction measured 704 in 1/seconds. For example, when the subscriber wants to receive 705 notifications once in every seven seconds on an average, then it sets 706 the value of the "adaptive-min-rate" parameter to 1/7. 708 A subscriber that wishes to update the previously agreed adaptive 709 minimum rate of notifications MUST include the updated "adaptive-min- 710 rate" Event header field parameter in a subsequent SUBSCRIBE request 711 or a 2xx response to the NOTIFY request. 713 A subscriber that wishes to remove the adaptive minimum rate control 714 from notifications MUST indicate so by not including a "adaptive-min- 715 rate" Event header field parameter in a subsequent SUBSCRIBE request 716 or a 2xx response to the NOTIFY request. 718 The main consequence for the subscriber when applying the adaptive 719 minimum rate mechanism is that it can receive a notification even if 720 nothing has changed in the current state of the notifier. However, 721 RFC 5839 [RFC5839] defines a mechanism that allows suppressing a 722 NOTIFY request or a NOTIFY request body if the state has not changed. 724 7.2. Notifier Behavior 726 A notifier that supports the adaptive minimum rate mechanism MUST 727 extract the value of the "adaptive-min-rate" Event header parameter 728 from a SUBSCRIBE request or a 2xx response to the NOTIFY request and 729 use it to calculate the actual maximum time between two notifications 730 as defined in Section 7.4. 732 The "adaptive-min-rate" value can be adjusted by the notifier, as 733 defined in Section 7.3. 735 A compliant notifier MUST reflect back the possibly adjusted adaptive 736 minimum rate of notifications in an "adaptive-min-rate" Subscription- 737 State header field parameter of the subsequent NOTIFY requests. The 738 indicated "adaptive-min-rate" value is adopted by the notifier, and 739 the notification rate is adjusted accordingly. 741 A notifier that does not understand this extension will not reflect 742 the "adaptive-min-rate" Subscription-State header parameter in the 743 NOTIFY requests; the absence of this parameter indicates to the 744 subscriber that no rate control is supported by the notifier. 746 A compliant notifier MUST generate notifications when state changes 747 occur or when the time since the most recent notification exceeds the 748 value calculated using the formula defined in Section 7.4. Depending 749 on the event package and subscriber preferences indicated in the 750 SUBSCRIBE request, the NOTIFY request sent as a result of a minimum 751 rate mechanism MUST contain either the current full state or the 752 partial state showing the difference between the current state and 753 the last successfully communicated state. If the subscriber and the 754 notifier support the procedures in RFC 5839 [RFC5839] the complete 755 NOTIFY request or the NOTIFY request body can be suppressed if the 756 state has not changed from the previous notification. 758 The adaptive minimum rate mechanism is implemented as follows: 760 1) When a subscription is first created, the notifier creates a 761 record ("count" parameter) that keeps track of the number of 762 notifications that have been sent in the "period". The "count" 763 parameter is initialized to contain a history of having sent a 764 "period * adaptive-min-rate" number of notifications for the 765 "period". 767 2) The "timeout" value is calculated according to the equation given 768 in Section 7.4. 770 3) If the timeout period passes without a NOTIFY request being sent 771 in the subscription, then the current resource state is sent 772 (subject to any filtering associated with the subscription). 774 4) Whenever a NOTIFY request is sent (regardless of whether due to a 775 "timeout" event or a state change), the notifier updates the 776 notification history record stored in the "count" parameter, 777 recalculates the value of "timeout," and returns to step 3. 779 Retransmissions of NOTIFY requests are not affected by the timeout, 780 i.e., the timeout only applies to the generation of new transactions. 781 In other words, the timeout does not in any way break or modify the 782 normal retransmission mechanism specified in RFC 3261 [RFC3261]. 784 7.3. Selecting the Adaptive Minimum Rate 786 The adaptive minimum rate mechanism can be used to generate a lot of 787 notifications, creating additional processing load for the notifier. 788 Some of the notifications may also be unnecessary possibly repeating 789 already known state information to the subscriber. It is difficult 790 to provide generic guidelines for the acceptable adaptive minimum 791 rate value ranges, however the subscriber SHOULD request for the 792 lowest possible adaptive minimum rate value. Different event 793 packages MAY define additional constraints for the allowed adaptive 794 minimum rate values. Such constraints are out of the scope of this 795 specification. 797 The notifier MAY decide to increase or decrease the proposed 798 "adaptive-min-rate" value based on its local policy, static 799 configuration or other implementation-determined constraints. 801 7.4. Calculating the Timeout 803 The formula used to vary the absolute pacing in a way that will meet 804 the adaptive minimum rate requested over the period is given in 805 equation (1): 807 timeout = count / ((adaptive-min-rate ^ 2) * period) (1) 809 The output of the formula, "timeout", is the time to the next 810 notification, expressed in seconds. The formula has three inputs: 812 adaptive-min-rate: The value of the "adaptive-min-rate" parameter 813 conveyed in the Subscription-State header field. 815 period: The rolling average period, in seconds. The granularity of 816 the values for the "period" parameter is set by local policy at 817 the notifier, however the notifier MUST choose a value greater 818 than the reciprocal value of the "adaptive-min-rate" parameter. 819 It is also RECOMMENDED that the notifier chooses a "period" 820 parameter several times larger than reciprocal value of the 821 "adaptive-min-rate" parameter in order to maximize the 822 effectiveness of the equation (1). It is an implementation 823 decision whether the notifier uses the same value of the "period" 824 parameter for all subscriptions or individual values for each 825 subscription. 827 count: The number of notifications that have been sent during the 828 last "period" of seconds not including any retransmissions of 829 requests. 831 In case both the maximum rate and the adaptive minimum rate 832 mechanisms are used in the same subscription the formula used to 833 dynamically calculate the timeout is given in equation (2): 835 timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2)*period)] (2) 837 max-rate: The value of the "max-rate" parameter conveyed in the 838 Subscription-State header field. 840 The formula in (2) makes sure that for all the possible values of the 841 "max-rate" and "adaptive-min-rate" parameters, with "adaptive-min- 842 rate" < "max-rate", the timeout never results in a lower value than 843 the reciprocal value of the "max-rate" parameter. 845 In some situation it may be beneficial for the notifier to achieve an 846 adaptive minimum rate in a different way than the algorithm detailed 847 in this document allows. However, the notifier MUST comply with any 848 "max-rate" or "min-rate" parameters that have been negotiated. 850 8. Usage of the Maximum Rate, Minimum Rate and Adaptive Minimum Rate 851 Mechanisms in a combination 853 Applications can subscribe to an event package using all the rate 854 control mechanisms individually, or in combination; in fact there is 855 no technical incompatibility among them. However there are some 856 combinations of the different rate control mechanisms that make 857 little sense to be used together. This section lists all the 858 combinations that are possible to insert in a subscription; the 859 utility to use each combination in a subscription is also analyzed. 861 maximum rate and minimum rate: This combination allows to reduce the 862 notification rate, but at the same time assures the reception of a 863 notification every time the most recent notification exceeds a 864 specified interval. 866 A subscriber SHOULD choose a "min-rate" value lower than the "max- 867 rate" value, otherwise the notifier MUST adjust the subscriber 868 provided "min-rate" value to a value equal to or lower than the 869 "max-rate" value. 871 maximum rate and adaptive minimum rate: It works in a similar way as 872 the combination above, but with the difference that the interval 873 at which notifications are assured changes dynamically. 875 A subscriber SHOULD choose a "adaptive-min-rate" value lower than 876 the "max-rate" value, otherwise the notifier MUST adjust the 877 subscriber provided "adaptive-min-rate" value to a value equal to 878 or lower than the "max-rate" value. 880 minimum rate and adaptive minimum rate: When using the adaptive 881 minimum rate mechanism, frequent state changes in a short period 882 can result in no notifications for a longer period following the 883 short period. The addition of the minimum rate mechanism ensures 884 the subscriber always receives notifications after a specified 885 interval. 887 A subscriber SHOULD choose a "min-rate" value lower than the 888 "adaptive-min-rate" value, otherwise the notifier MUST NOT 889 consider the "min-rate" value. 891 maximum rate, minimum rate and adaptive minimum rate: This 892 combination makes little sense to be used although not forbidden. 894 A subscriber SHOULD choose a "min-rate" and "adaptive-min-rate" 895 values lower than the "max-rate" value, otherwise the notifier 896 MUST adjust the subscriber provided "min-rate" and "adaptive-min- 897 rate" values to a value equal to or lower than the "max-rate" 898 value. 900 A subscriber SHOULD choose a "min-rate" value lower than the 901 "adaptive-min-rate" value, otherwise the notifier MUST NOT 902 consider the "min-rate" value. 904 9. Protocol Element Definitions 906 This section describes the protocol extensions required for the 907 different rate control mechanisms. 909 9.1. "max-rate", "min-rate" and "adaptive-min-rate" Header Field 910 Parameters 912 The "max-rate", "min-rate" and "adaptive-min-rate" parameters are 913 added to the rule definitions of the Event header field and the 914 Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage 915 of this parameter is described in Section 5, Section 6 and Section 7. 917 9.2. Grammar 919 This section describes the Augmented BNF [RFC5234] definitions for 920 the new header field parameters. Note that we derive here from the 921 ruleset present in RFC 3265 [RFC3265], adding additional alternatives 922 to the alternative sets of "event-param" and "subexp-params" defined 923 therein. The "delta-seconds" element is defined in RFC 3261 924 [RFC3261]. 926 event-param =/ max-rate-param / min-rate-param / amin-rate-param 927 subexp-params =/ max-rate-param / min-rate-param / amin-rate-param 928 max-rate-param = "max-rate" EQUAL ("1" SLASH delta-seconds) 929 min-rate-param = "min-rate" EQUAL ("1" SLASH delta-seconds) 930 amin-rate-param = "adaptive-min-rate" EQUAL ("1" SLASH delta-seconds) 932 9.3. Event Header Field Usage in Responses to the NOTIFY request 934 This table expands the table described in Section 7.2 of RFC 3265 935 [RFC3265] allowing the Event header field to appear in a 2xx response 936 to a NOTIFY request. The use of the Event header field in responses 937 other than 2xx to NOTIFY requests is undefined and out of scope of 938 this specification. 940 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 941 ----------------------------------------------------------------- 942 Event 2xx - - - - - - - - o 944 A subscriber that wishes to update the previously agreed value for 945 maximum, minimum or adaptive minimum rate of notifications MUST 946 include all desired values for the "max-rate", "min-rate" and 947 "adaptive-min-rate" parameters in an Event header field of the 2xx 948 response to a NOTIFY request. Any of the other header field 949 parameters currently defined for the Event header field by other 950 specifications do not have a meaning if the Event header field is 951 included in the 2xx response to the NOTIFY request. These header 952 field parameters MUST be ignored by the notifier, if present. 954 The event type listed in the Event header field of the 2xx response 955 to the NOTIFY request MUST match the event type of the Event header 956 field in the corresponding NOTIFY request. 958 10. IANA Considerations 960 This specification registers three new SIP header field parameters, 961 defined by the following information which is to be added to the 962 Header Field Parameters and Parameter Values sub-registry under 963 http://www.iana.org/assignments/sip-parameters. 965 Predefined 966 Header Field Parameter Name Values Reference 967 -------------------- --------------- ---------- --------- 968 Event max-rate No [RFCxxxx] 969 Subscription-State max-rate No [RFCxxxx] 970 Event min-rate No [RFCxxxx] 971 Subscription-State min-rate No [RFCxxxx] 972 Event adaptive-min-rate No [RFCxxxx] 973 Subscription-State adaptive-min-rate No [RFCxxxx] 975 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 976 this specification, when assigned.) 978 This specification also updates the reference defining the Event 979 header field in the Header Fields sub-registry under 980 http://www.iana.org/assignments/sip-parameters. 982 Header Name compact Reference 983 ----------- ------- ------------------ 984 Event o [RFC3265][RFCxxxx] 986 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 987 this specification, when assigned.) 989 11. Security Considerations 991 Naturally, the security considerations listed in RFC 3265 [RFC3265], 992 which the rate control mechanisms described in this document extends, 993 apply in entirety. In particular, authentication and message 994 integrity SHOULD be applied to subscriptions with this extension. 996 RFC 3265 [RFC3265] recommends the integrity protection of the Event 997 header field of SUBSCRIBE requests. Implementations of this 998 extension SHOULD also provide integrity protection for the Event 999 header field included in the 2xx response to the NOTIFY request. 1000 Without integrity protection an eavesdropper could see and modify the 1001 Event header field; or it could also manipulate the transmission of a 1002 200 (OK) response to the NOTIFY request in order to suppress or flood 1003 notifications without the subscriber seeing what caused the problem. 1005 When the maximum rate mechanism involves partial state notifications, 1006 the security considerations listed in RFC 5263 [RFC5263] apply in 1007 entirety. 1009 12. Acknowledgments 1011 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 1012 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 1013 Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, 1014 Michael Procter, Janet Gunn and Ari Keranen for support and/or review 1015 of this work. 1017 Thanks to Brian Rosen for the idea of the minimum and adaptive 1018 minimum rate mechanisms, and Adam Roach for the work on the algorithm 1019 for the adaptive minimum rate mechanism and other feedback. 1021 13. References 1023 13.1. Normative References 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, March 1997. 1028 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1029 A., Peterson, J., Sparks, R., Handley, M., and E. 1030 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1031 June 2002. 1033 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1034 Event Notification", RFC 3265, June 2002. 1036 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1037 Initiation Protocol (SIP) Event Notification Extension for 1038 Resource Lists", RFC 4662, August 2006. 1040 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1041 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1043 [RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. 1044 Khartabil, "Session Initiation Protocol (SIP) Extension 1045 for Partial Notification of Presence Information", 1046 RFC 5263, September 2008. 1048 13.2. Informative References 1050 [I-D.ietf-geopriv-loc-filters] 1051 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 1052 Location Notifications in the Session Initiation Protocol 1053 (SIP)", draft-ietf-geopriv-loc-filters-11 (work in 1054 progress), March 2010. 1056 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 1057 Liu, Z., and J. Rosenberg, "Signaling Compression 1058 (SigComp)", RFC 3320, January 2003. 1060 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 1061 Package for Registrations", RFC 3680, March 2004. 1063 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 1064 Indication Event Package for the Session Initiation 1065 Protocol (SIP)", RFC 3842, August 2004. 1067 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 1068 Initiation Protocol (SIP)", RFC 3856, August 2004. 1070 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 1071 Package for the Session Initiation Protocol (SIP)", 1072 RFC 3857, August 2004. 1074 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 1075 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 1076 November 2004. 1078 [RFC5839] Niemi, A. and D. Willis, "An Extension to Session 1079 Initiation Protocol (SIP) Events for Conditional Event 1080 Notification", RFC 5839, May 2010. 1082 Authors' Addresses 1084 Aki Niemi 1085 Nokia 1086 P.O. Box 407 1087 NOKIA GROUP, FIN 00045 1088 Finland 1090 Phone: +358 50 389 1644 1091 Email: aki.niemi@nokia.com 1092 Krisztian Kiss 1093 Nokia 1094 200 South Mathilda Ave 1095 Sunnyvale, CA 94086 1096 US 1098 Phone: +1 650 391 5969 1099 Email: krisztian.kiss@nokia.com 1101 Salvatore Loreto 1102 Ericsson 1103 Hirsalantie 11 1104 Jorvas 02420 1105 Finland 1107 Email: salvatore.loreto@ericsson.com