idnits 2.17.1 draft-ietf-sipcore-event-rate-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 851 has weird spacing: '...n-State min-...' == Line 853 has weird spacing: '...n-State max-...' == Line 855 has weird spacing: '...n-State aver...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A subscriber SHOULD choose a "max-interval" value higher than the "average-interval" value, otherwise the notifier MUST not consider the "max-interval" value. -- The document date (May 11, 2009) is 5456 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: 'OPEN ISSUE' is mentioned on line 745, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 855, but not defined == Unused Reference: 'RFC3261' is defined on line 885, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-11) exists of draft-ietf-geopriv-loc-filters-03 == Outdated reference: A later version (-04) exists of draft-ietf-sipcore-subnot-etags-02 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft K. Kiss 4 Intended status: Standards Track Nokia 5 Expires: November 12, 2009 S. Loreto 6 Ericsson 7 May 11, 2009 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 12, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document specifies mechanisms for adjusting the rate of Session 50 Initiation Protocol (SIP) event notifications. These mechanisms can 51 be applied in subscriptions to all SIP event packages. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Definitions and Document Conventions . . . . . . . . . . . . . 4 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. Use Case for maximizing the rate of notifications . . . . 4 59 3.2. Use Case for minimizing the rate of notifications . . . . 5 60 3.3. Use Case for specifying the average rate of 61 notifications . . . . . . . . . . . . . . . . . . . . . . 6 62 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.5. The maximum rate mechanism for Resource List Server . . . 7 64 3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 65 4. Operation of the maximum rate mechanism . . . . . . . . . . . 10 66 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10 67 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 10 68 4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 11 69 4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 12 70 4.4.1. Partial State Notifications . . . . . . . . . . . . . 12 71 4.4.2. Full State Notifications . . . . . . . . . . . . . . . 12 72 4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 13 73 5. Operation of the minimum rate mechanism . . . . . . . . . . . 13 74 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 13 75 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 14 76 6. Operation of the average rate mechanism . . . . . . . . . . . 14 77 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 14 78 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15 79 6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 16 80 7. Usage of "min-interval", "max-interval" and 81 "average-interval" in a combination . . . . . . . . . . . . . 17 82 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 8.1. "min-interval", "max-interval" and "average-interval" 84 Header Field Parameters . . . . . . . . . . . . . . . . . 18 85 8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 18 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 94 1. Introduction 96 The SIP events framework [RFC3265] defines a generic framework for 97 subscriptions to and notifications of events related to SIP systems. 98 This framework defines the methods SUBSCRIBE and NOTIFY, and 99 introduces the concept of an event package, which is a concrete 100 application of the SIP events framework to a particular class of 101 events. 103 One of the things the SIP events framework mandates is that each 104 event package specification defines an absolute maximum on the rate 105 at which notifications are allowed to be generated by a single 106 notifier. Such a limit is provided in order to reduce network 107 congestion. 109 All of the existing event package specifications include a maximum 110 notification rate recommendation, ranging from once in every five 111 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 113 Per the SIP events framework, each event package specification is 114 also allowed to define additional throttle mechanisms which allow the 115 subscriber to further limit the rate of event notification. So far 116 none of the event package specifications have defined such a 117 mechanism. 119 The resource list extension [RFC4662] to the SIP events framework 120 also deals with rate limiting of event notifications. The extension 121 allows a subscriber to subscribe to a heterogeneous list of resources 122 with a single SUBSCRIBE request, rather than having to install a 123 subscription for each resource separately. The event list 124 subscription also allows rate limiting, or throttling of 125 notifications, by means of the Resource List Server (RLS) buffering 126 notifications of resource state changes, and sending them in batches. 127 However, the event list mechanism provides no means for the 128 subscriber to set the interval for the throttling; it is strictly an 129 implementation decision whether batching of notifications is 130 supported, and by what means. 132 This document defines an extension to the SIP events framework 133 defining the following three "Event" header field parameters that 134 allow a subscriber to set a Minimum, a Maximum and an Average rate of 135 event notifications generated by the notifier: 137 min-interval: specifies a minimum notification time period between 138 two notifications, in seconds. 140 max-interval: specifies a maximum notification time period between 141 two notifications, in seconds. Whenever the time since the most 142 recent notification exceeds the value in the "max-interval" 143 parameter, then the current state would be sent in its entirety, 144 just like after a subscription refresh. 146 average-interval: specifies an average cadence at which 147 notifications are desired, in seconds. It works similar to the 148 "max-interval" parameter, except that it will reduce the frequency 149 at which notifications are sent if several have already been sent 150 recently. 152 The requirements and model are further discussed in Section 3. All 153 those mechanisms are simply timer values that indicates the minimum, 154 maximum and average time period allowed between two notifications. 155 As a result of those mechanism, a compliant notifier will adjust the 156 rate at which it generates notifications. 158 These mechanisms are applicable to any event subscription, both 159 single event subscription and event list subscription. 161 2. Definitions and Document Conventions 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119] and 166 indicate requirement levels for compliant implementations. 168 Indented passages such as this one are used in this document to 169 provide additional information and clarifying text. They do not 170 contain normative protocol behavior. 172 3. Overview 174 3.1. Use Case for maximizing the rate of notifications 176 A presence client in a mobile device contains a list of 100 buddies 177 or presentities. In order to decrease the processing and network 178 load of watching 100 presentities, the presence client has employed a 179 Resource List Server (RLS) with the list of buddies, and therefore 180 only needs a single subscription to the RLS in order to receive 181 notification of the presence state of the resource list. 183 In order to control the buffer policy of the RLS, the presence client 184 sets a maximum rate ("min-interval" parameter), i.e. a minimum time 185 interval between two notifications. Alternatively, the presence 186 client could set the maximum rate for the resource list via a list 187 manipulation interface, e.g., using the XML Configuration Access 188 Protocol (XCAP) [RFC4825]. 190 The RLS will buffer notifications that do not comply with the maximum 191 rate and batch all of the buffered state changes together in a single 192 notification only when allowed by the maximum rate. The maximum rate 193 applies to the overall resource list, which means that there is a 194 hard cap imposed by the maximum rate to the amount of traffic the 195 presence client can expect to receive. 197 For example, with a "min-interval" of 20 seconds, the presence 198 application can expect to receive a notification at a minimum of 199 every 20 seconds. 201 The presence client can also modify the "min-interval" parameter 202 during the lifetime of the subscription. For example, if the User 203 Interface (UI) of the application shows inactivity for a period of 204 time, it can simply pause the notifications by setting the "min- 205 interval" parameter to the subscription expiration time, while still 206 keeping the subscription alive. When the user becomes active again, 207 the presence client can resume the stream of notifications by re- 208 setting the "min-interval" parameter to the earlier used value. 210 Currently, a subscription refresh is needed in order to update the 211 maximum rate. However, this is highly inefficient, since each 212 refresh automatically generates a (full-state) notification 213 carrying the latest resource state. There is work 214 [I-D.ietf-sipcore-subnot-etags] ongoing to solve these 215 inefficiencies. 217 3.2. Use Case for minimizing the rate of notifications 219 A location application is monitoring the movement of a target. 221 In order to decrease the processing and network load, the location 222 application has made a subscription with a set of location filters 223 [I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for 224 example, to send an update only when the target has moved at least n 225 meters. However, the application is also interested to receive the 226 current state periodically even if the state of the target is 227 unchanged or has not changed enough to satisfy any of the trigger 228 criteria, i.e. has not moved at least n meters within the period. 230 In order to control the actual state, the location application sets a 231 minimum rate ("max-interval" parameter), i.e. a maximum time interval 232 between two notifications. The minimum rate setting triggers a 233 notification that is exactly and precisely like a notification after 234 a subscription refresh. 236 The location application can also modify the "max-interval" parameter 237 during the lifetime of the subscription. 239 3.3. Use Case for specifying the average rate of notifications 241 The previous mechanisms introduce a static and instantaneous rate 242 control. However there are some applications that would work better 243 with an adaptive rate control. This section illustrates the tracking 244 scenario. 246 A tracking application is monitoring a target. 248 In order to decrease the processing and network load, the tracking 249 application wants to make a subscription that dynamically increases 250 the interval between notifications if the target has sent out several 251 notifications recently. 253 In order to set an adaptive rate control, the application defines a 254 average cadence ("average-interval" parameter) at which notifications 255 are desired. The "average-interval" parameter value is used by the 256 notifier to dynamically calculate the maximum time allowed between 257 two subscriptions. In order to dynamically calculate the maximum, 258 the Notifier takes into consideration the frequency at which 259 notifications have been sent recently. 261 This type of rate control allows the notifier to dynamically increase 262 or decrease the Notification frequency. 264 The tracking application can also modify the "average-interval" 265 parameter during the lifetime of the subscription. 267 3.4. Requirements 269 REQ1: The subscriber must be able to set the minimum time period 270 ("min-interval" parameter) between two notifications in a 271 specific subscription. 273 REQ2: The subscriber must be able to set the maximum time period 274 ("max-interval" parameter) between two notifications in a 275 specific subscription. 277 REQ3: The subscriber must be able to set an average cadence 278 ("average-interval" parameter) at which notifications are 279 desired in a specific subscription. 281 REQ4: It must be possible to apply all together, or in any 282 combination, the "min-interval", "max-interval" and "average- 283 interval" mechanisms in a specific subscription. 285 REQ5: It must be possible to use of the different rate control 286 mechanisms in subscriptions to any events. 288 REQ6: It must be possible to use the different rate control 289 mechanisms together with any other event filtering 290 mechanisms. 292 REQ7: The notifier must be allowed to use a policy in which the 293 minimum time period between two notifications is adjusted 294 from the value given by the subscriber. 296 For example, due to congestion reasons, local policy at 297 the notifier could temporarily dictate a policy that in 298 effect increases the subscriber-configured minimum time 299 period between two notifications. 301 REQ8: The different rate control mechanisms must discuss corner 302 cases for setting the time periods between two notifications. 303 At a minimum, the mechanisms must include discussion of the 304 situation resulting from a minimum, maximum or average time 305 period which exceeds the subscription duration, and should 306 provide mechanisms for avoiding this situation. 308 REQ9: The different rate control mechanisms must be possible to be 309 installed, modified, or removed in the course of an active 310 subscription. 312 REQ10: The different rate control mechanisms must allow for the 313 application of authentication and integrity protection 314 mechanisms to subscriptions invoking that mechanism. 316 Note that Section 10 contains further discussion on the security 317 implications of the different rate control mechanisms. 319 3.5. The maximum rate mechanism for Resource List Server 321 When applied to a list subscription, the maximum rate mechanism has 322 some additional considerations. Specifically, the maximum rate 323 applies to the aggregate notification stream resulting from the list 324 subscription, rather than explicitly controlling the notification of 325 each of the implied constituent events. Moreover, the list event 326 notifier can use the maximum rate mechanism on its own to control the 327 rate of the individual subscriptions to avoid overflowing its buffer. 329 The notifier is responsible for sending out event notifications upon 330 state changes of the subscribed resource. We can model the notifier 331 as consisting of three components: the event state resource(s), the 332 Resource List Server (RLS) (or any other notifier), a notification 333 buffer, and finally the subscriber, or watcher of the event state, as 334 shown in Figure 1. 336 +--------+ 337 | Event | 338 +--------+ |Resource| +--------+ 339 | Event | +--------+ | Event | 340 |Resource| | |Resource| 341 +---.=---+ | +---=----+ 342 `-.. | _.--' 343 ``-._ | _.--' 344 +'--'--'-+ 345 |Resource| 346 | List | 347 | Server | 348 +---.----+ 349 | 350 | 351 )--+---( 352 | | .------------. 353 |Buffer|<======'min-interval| 354 | | `------------' 355 )--.---( 356 | 357 | 358 .---+---. 359 | Event | 360 |Watcher| 361 `-------' 363 Figure 1: Model for the Resource List Server (RLS) Supporting 364 Throttling 366 In short, the RLS reads event state changes from the event state 367 resource, either by creating a back end subscription, or by other 368 means; it packages them into event notifications, and submits them 369 into the output buffer. The rate at which this output buffer drains 370 is controlled by the subscriber via the maximum rate mechanism. When 371 a set of notifications are batched together, the way in which 372 overlapping resource state is handled depends on the type of the 373 resource state: 375 In theory, there are many buffer policies that the notifier could 376 implement. However, we only concentrate on two practical buffer 377 policies in this specification, leaving additional ones for 378 further study and out of the scope of this work. These two buffer 379 policies depend on the mode in which the notifier is operating. 381 Full-state: Last (most recent) full state notification of each 382 resource is sent out, and all others in the buffer are discarded. 383 This policy applies to those event packages that carry full-state 384 notifications. 386 Partial-state: The state deltas of each buffered partial 387 notification per resource are merged, and the resulting 388 notification is sent out. This policy applies to those event 389 packages that carry partial-state notifications. 391 3.6. Basic Operation 393 A subscriber that wants to limit the rate of event notification in a 394 specific event subscription does so by including a "min-interval" 395 Event header parameter as part of the SUBSCRIBE request. The "min- 396 interval" value indicates the minimum time allowed between 397 transmission of two consecutive notifications in a subscription. 399 Note that the witnessed time between two consecutive received 400 notifications may not conform to the "min-interval" value for a 401 number of reasons. For example, network jitter and 402 retransmissions may result in the subscriber receiving the 403 notifications with smaller intervals than the "min-interval" value 404 recommends. 406 A subscriber that wants to have a maximum notification time period in 407 a specific event subscription does so by including a "max-interval" 408 Event header parameter as part of the SUBSCRIBE request. The "max- 409 interval" value indicates the maximum time allowed between 410 transmission of two consecutive notifications in a subscription. 412 A subscriber that wants to have an average cadence for the 413 notifications in a specific event subscription does so by including a 414 "average-interval" Event header parameter as part of the SUBSCRIBE 415 request. 417 A notifier that supports the different rate control mechanisms will 418 comply with the value given in "min-interval", "max-interval" and 419 "average-interval" parameters and adjust its rate of notification 420 accordingly. However, if the notifier needs to lower the 421 subscription expiration value or a local policy at the notifier can 422 not satisfy the rate control request, then the notifier can adjust 423 opportunely the subscriber requested rate control. 425 Rate controlled notifications will have exactly the same properties 426 as the ones without rate control, with the exception that they will 427 be generated within the timing constraints requested. 429 4. Operation of the maximum rate mechanism 431 4.1. Subscriber Behavior 433 In general, the way in which a subscriber generates SUBSCRIBE 434 requests and processes NOTIFY requests is according to RFC 3265 435 [RFC3265]. 437 A subscriber that wishes to apply a maximum rate to notifications in 438 a subscription MUST construct a SUBSCRIBE request that includes a 439 minimum time interval between two consecutive notifications included 440 in the "min-interval" Event header field parameter. The value of 441 this parameter is an integral number of seconds in decimal. 443 A subscriber that wishes to remove a the maximum rate control from 444 notifications MUST construct a SUBSCRIBE request that does not 445 include a "min-interval" Event header field parameter. 447 There are two main consequences for the subscriber when applying the 448 maximum rate mechanism: state transitions may be lost, and event 449 notifications may be delayed. If either of these side effects 450 constitute a problem to the application that is to utilize event 451 notifications, developers are instructed not to use the mechanism. 453 4.2. Notifier Behavior 455 In general, the way in which a notifier processes SUBSCRIBE requests 456 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 458 A notifier that supports the maximum rate mechanism MUST extract the 459 value of the "min-interval" Event header parameter and use it as the 460 suggested time allowed between two notifications. This value can be 461 adjusted by the notifier, as defined in Section 4.3. 463 A compliant notifier MUST reflect back the possibly adjusted minimum 464 time interval in a "min-interval" Subscription-State header field 465 parameter of the subsequent NOTIFY requests. The indicated "min- 466 interval" value is adopted by the notifier, and the notification rate 467 is adjusted accordingly. 469 A notifier that does not understand this extension will not reflect 470 the "min-interval" Subscription-State header field parameter in the 471 NOTIFY requests; the absence of this parameter serves as a hint to 472 the subscriber that no rate control is supported by the notifier. 474 A compliant notifier MUST NOT generate notifications more frequently 475 than the maximum rate allows for, except when generating the 476 notification either upon receipt of a SUBSCRIBE request (the first 477 notification), when the subscription state is changing from "pending" 478 to "active" state or upon termination of the subscription (the last 479 notification). Such notifications reset the timer for the next 480 notification, even though they do not need to abide by it. 482 When a local policy dictates a maximum rate for notifications, a 483 notifier will not generate notifications more frequently than the 484 local policy maximum rate, even if the subscriber is not asking for 485 maximum rate control. The notifier MAY inform the subscriber about 486 such local policy maximum rate using the "min-interval" Subscription- 487 State header field parameter included in the subsequent NOTIFY 488 requests. 490 Retransmissions of NOTIFY requests are not affected by the maximum 491 rate mechanism, i.e., the maximum rate mechanism only applies to the 492 generation of new transactions. In other words, the maximum rate 493 mechanism does not in any way break or modify the normal 494 retransmission mechanism. 496 4.3. Selecting the maximum rate 498 Special care needs to be taken when selecting the "min-interval" 499 value. Using the "min-interval" syntax it is possible to insist both 500 very short and very long intervals between notifications. For 501 example, the maximum rate could potentially set a minimum time value 502 between notifications that exceeds the subscription expiration value. 503 Such a configuration would effectively quench the notifier, resulting 504 in exactly two notifications to be generated. 506 In some cases it makes sense to pause the notification stream on an 507 existing subscription dialog on a temporary basis without terminating 508 the subscription, e.g. due to inactivity on the application UI. 509 Whenever a subscriber discovers the need to perform the notification 510 pause operation, it SHOULD set the "min-interval" value to the 511 remaining subscription expiration value. This results in receiving 512 no further notifications until the subscription expires, renewed or 513 notifications are resumed by the subscriber. 515 The notifier is responsible for adjusting the proposed maximum rate 516 value based on its local policy or other properties. 518 If the subscriber requests a "min-interval" value greater than the 519 subscription expiration, the notifier MUST lower the "min-interval" 520 value and set it to the expiration time left. According to RFC 3265 521 [RFC3265] the notifier may also shorten the subscription expiry 522 anytime during an active subscription. For such cases, the notifier 523 MUST also lower the "min-interval" value and set it to the reduced 524 expiration time. 526 The notifier MAY also choose a higher "min-interval" value, e.g., 527 because of static configuration given by local policy. The notifier 528 MUST include the adjusted "min-interval" value in the Subscription- 529 State header field's "min-interval" parameter in each of the NOTIFY 530 requests. In addition, different event packages MAY define 531 additional constraints to the allowed "min-interval" intervals. Such 532 constraints are out of the scope of this specification. 534 4.4. Buffer Policy Description 536 4.4.1. Partial State Notifications 538 With partial notifications, the notifier will always need to keep 539 both a copy of the current full state of the resource F, as well as 540 the last successfully communicated full state view F' of the resource 541 in a specific subscription. The construction of a partial 542 notification then involves creating a difference of the two states, 543 and generating a notification that contains that difference. 545 When the maximum rate mechanism is applied to the subscription, it is 546 important that F' is replaced with F only when the difference of F 547 and F' was already included in a partial state notification to the 548 subscriber allowed by the maximum rate mechanism. Additionally, the 549 notifier implementation SHOULD check to see that the size of an 550 accumulated partial state notification is smaller than the full 551 state, and if not, the notifier SHOULD send the full state 552 notification instead. 554 4.4.2. Full State Notifications 556 With full state notifications, the notifier only needs to keep the 557 full state of the resource, and when that changes, send the resulting 558 notification over to the subscriber. 560 When the maximum rate mechanism is applied to the subscription, the 561 notifier receives the state changes of the resource, and generates a 562 notification. If there is a pending notification, the notifier 563 simply replaces that notification with the new notification, 564 discarding the older state. 566 4.5. Estimated Bandwidth Savings 568 It is difficult to estimate the total bandwidth savings accrued by 569 using the maximum rate mechanism over a subscription, since such 570 estimates will vary depending on the usage scenarios. However, it is 571 easy to see that given a subscription where several full state 572 notifications would have normally been sent in any given interval set 573 by the "min-interval" parameter, only a single notification is sent 574 during the same interval when using the maximum rate mechanism, 575 yielding bandwidth savings of several times the notification size. 577 With partial-state notifications, drawing estimates is further 578 complicated by the fact that the states of consecutive updates may or 579 may not overlap. However, even in the worst case scenario, where 580 each partial update is to a different part of the full state, a rate 581 controlled notification merging all of these n partial states 582 together should at a maximum be the size of a full-state update. In 583 this case, the bandwidth savings are approximately n times the size 584 of the NOTIFY header. 586 It is also true that there are several compression schemes available 587 that have been designed to save bandwidth in SIP, e.g., SigComp 588 [RFC3320] and TLS compression [RFC3943]. However, such compression 589 schemes are complementary rather than competing mechanisms to the 590 maximum rate mechanism. After all, they can both be applied 591 simultaneously, and in such a way that the compound savings are as 592 good as the sum of applying each one alone. 594 5. Operation of the minimum rate mechanism 596 5.1. Subscriber Behavior 598 In general, the way in which a subscriber generates SUBSCRIBE 599 requests and processes NOTIFY requests is according to RFC 3265 600 [RFC3265]. 602 A subscriber that wishes to apply a minimum rate to notifications in 603 a subscription MUST construct a SUBSCRIBE request that includes a 604 maximum time interval between two consecutive notifications included 605 in the "max-interval" Event header field parameter. 607 A subscriber that wishes to remove the minimum rate control from 608 notifications MUST construct a SUBSCRIBE request that does not 609 include a "max-interval" Event header field parameter. The value of 610 this parameter is an integral number of seconds in decimal. 612 The main consequence for the subscriber when applying the minimum 613 rate mechanism is that it can receive a notification even if nothing 614 has changed in the current state of the notifier. 616 There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a 617 reference in a notification if nothing has changed. 619 5.2. Notifier Behavior 621 In general, the way in which a notifier processes SUBSCRIBE requests 622 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 624 A notifier that supports the minimum rate mechanism MUST extract the 625 value of the "max-interval" Event header parameter and use it as the 626 suggested maximum time allowed between two notifications. This value 627 can be adjusted by the notifier based on its local policy or other 628 properties. 630 A compliant notifier MUST reflect back the possibly adjusted maximum 631 time interval in a "max-interval" Subscription-State header field 632 parameter of the subsequent NOTIFY requests. The indicated "max- 633 interval" value is adopted by the notifier, and the notification rate 634 is adjusted accordingly. 636 A notifier that does not understand this extension, will not reflect 637 the "max-interval" Subscription-State header field parameter in the 638 NOTIFY requests; the absence of this parameter serves as a hint to 639 the subscriber that no rate control is supported by the notifier. 641 A compliant notifier MUST generate notifications whenever the time 642 since the most recent notification exceeds the value in the "max- 643 interval" parameter. The NOTIFY request then MUST contain the 644 current state in its entirety, just like after a subscription 645 refresh. 647 Retransmissions of NOTIFY requests are not affected by the minimum 648 rate mechanism, i.e., the minimum rate mechanism only applies to the 649 generation of new transactions. In other words, the minimum rate 650 mechanism does not in any way break or modify the normal 651 retransmission mechanism. 653 6. Operation of the average rate mechanism 655 6.1. Subscriber Behavior 657 In general, the way in which a subscriber generates SUBSCRIBE 658 requests and processes NOTIFY requests is according to RFC 3265 659 [RFC3265]. 661 A subscriber that wishes to apply an average rate to notifications in 662 a subscription MUST construct a SUBSCRIBE request that includes a 663 proposed average time interval between two consecutive notifications 664 included in a "average-interval" Event header field parameter. The 665 value of this parameter is an integral number of seconds in decimal. 667 A subscriber that wishes to remove the average rate control from 668 notifications MUST construct a SUBSCRIBE request that does not 669 include the "average-interval" Event header field parameter. 671 The main consequence for the subscriber when applying the average 672 rate mechanism is that it can receive a notification even if nothing 673 has changed in the current state of the notifier. 675 There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a 676 reference in a notification if nothing has changed. 678 6.2. Notifier Behavior 680 In general, the way in which a notifier processes SUBSCRIBE requests 681 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 683 A notifier that supports the average rate mechanism MUST extract the 684 value of the "average-interval" Event header parameter, and uses it 685 to calculate the maximum time allowed between two transactions as 686 defined in Section 6.3. This value can be adjusted by the notifier 687 based on its local policy or other properties. 689 A compliant notifier MUST reflect back the possibly adjusted average 690 time interval in an "average-interval" Subscription-State header 691 field parameter of the subsequent NOTIFY requests. The indicated 692 "average-interval" value is adopted by the notifier, and the 693 notification rate is adjusted accordingly. 695 A notifier that does not understand this extension will not reflect 696 the "average-interval" Subscription-State header parameter in the 697 NOTIFY requests; the absence of this parameter serves as a hint to 698 the subscriber that no rate control is supported by the notifier. 700 A compliant notifier MUST generate notifications whenever the time 701 since the most recent notification exceeds the value calculated using 702 the formula defined in Section 6.3. 704 The average rate mechanism is implemented as follows: 706 1) When a subscription is first created, the notifier creates a 707 record that keeps track of the number of notifications that have 708 been sent in the "period". This record is initialized to contain 709 a history of having sent one message every "average-interval" 710 seconds for the "period". 712 2) The "timeout" value is calculated according to the equation given 713 in Section 6.3. 715 3) If the timeout period passes without a NOTIFY request being sent 716 in the subscription, then the current resource state is sent 717 (subject to any filtering associated with the subscription). 719 4) Whenever a NOTIFY request is sent (regardless of whether due to a 720 timeout or a state change), the notifier updates the notification 721 history record, recalculates the value of "timeout," and returns 722 to step 3. 724 Retransmissions of NOTIFY requests are not affected by the timeout, 725 i.e., the timeout only applies to the generation of new transactions. 726 In other words, the timeout does not in any way break or modify the 727 normal retransmission mechanism. 729 6.3. Calculating the timeout 731 The formula used to vary the absolute pacing in a way that will meet 732 the average rate requested over the period is given in equation (1): 734 timeout = (average-interval ^ 2) * count / period (1) 736 The output of the formula, "timeout", is the time to the next 737 notification, expressed in seconds. The formula has three inputs: 739 average-interval: The value of the "average-interval" parameter 740 conveyed in the Event header field, in seconds. 742 period: The rolling average period, in seconds. A suggested 743 reasonable period is 60 seconds. 745 [OPEN ISSUE] Is the period value something we should be able to 746 tune, or we can simply specify a reasonable period? 748 count: The number of notifications that have been sent during the 749 last "period" of seconds. 751 In case both the maximum rate and the average rate mechanisms are 752 used in the same subscription the formula used to dynamically 753 calculate the timeout is given in equation (2): 755 timeout = MAX[min-interval, (average-interval ^ 2) * count / period] (2) 757 min-interval: The value of the "min-interval" parameter conveyed in 758 the Event header field, in seconds. 760 The formula in (2) makes sure that for all the possible values of the 761 "min-interval" and "average-interval" parameters, with "average- 762 interval" > "min-interval", the timeout never results in a lower 763 value than the value of the "min-interval" parameter. 765 7. Usage of "min-interval", "max-interval" and "average-interval" in a 766 combination 768 Applications can subscribe to an event package using all the rate 769 control mechanisms individually, or in combination; in fact there is 770 no technical incompatibility among them. However there are some 771 combinations of the different rate control mechanisms that make 772 little sense to be used together. This section lists all the 773 combinations that are possible to insert in a subscription; the 774 utility to use each combination in a subscription is also analyzed. 776 min-interval and max-interval: this combination allows to reduce the 777 notification frequency rate, but at the same time assures the 778 reception of a notification every time the most recent 779 notification exceeds a specified interval. 781 A subscriber SHOULD choose a "max-interval" value higher than the 782 "min-interval" value, otherwise the notifier MUST adjust the 783 subscriber provided "max-interval" value to a value equivalent or 784 higher than the "min-interval" value. 786 min-interval and average-interval: it works in a similar way as the 787 combination above, but with the difference that the interval at 788 which notifications are assured changes dynamically. 790 A subscriber SHOULD choose a "average-interval" value higher than 791 the "min-interval" value, otherwise the notifier MUST adjust the 792 subscriber provided "average-interval" value to a value equivalent 793 or higher than the "min-interval" value. 795 max-interval and average-interval: as both the parameters are 796 designed as minimum rate mechanisms, this combination makes sense 797 only in some corner cases. 799 A subscriber SHOULD choose a "max-interval" value higher than the 800 "average-interval" value, otherwise the notifier MUST not consider 801 the "max-interval" value. 803 min-interval, max-interval and average-interval: this combination 804 makes little sense to be used. 806 8. Syntax 808 This section describes the syntax extensions required for the 809 different rate control mechanisms. 811 8.1. "min-interval", "max-interval" and "average-interval" Header Field 812 Parameters 814 The "min-interval", "max-interval" and "average-interval" parameters 815 are added to the rule definitions of the Event header field and the 816 Subscription-State header field in the SIP Events [RFC3265] grammar. 817 Usage of this parameter is described in Section 4, Section 5 and 818 Section 6. 820 8.2. Augmented BNF Definitions 822 This section describes the Augmented BNF [RFC5234] definitions for 823 the new syntax elements. Note that we derive here from the ruleset 824 present in SIP Events [RFC3265], adding additional alternatives to 825 the alternative sets of "event-param" and "subexp-params" defined 826 therein. 828 event-param =/ min-interval-param 829 subexp-params =/ min-interval-param 830 min-interval-param = "min-interval" EQUAL delta-seconds 832 event-param =/ max-interval-param 833 subexp-params =/ max-interval-param 834 max-interval-param = "max-interval" EQUAL delta-seconds 836 event-param =/ average-interval-param 837 subexp-params =/ average-interval-param 838 average-interval-param = "average-interval" EQUAL delta-seconds 840 9. IANA Considerations 842 This specification registers three new SIP header field parameters, 843 defined by the following information which is to be added to the 844 Header Field Parameters and Parameter Values sub-registry under 845 http://www.iana.org/assignments/sip-parameters. 847 Predefined 848 Header Field Parameter Name Values Reference 849 -------------------- --------------- ---------- --------- 850 Event min-interval No [RFCxxxx] 851 Subscription-State min-interval No [RFCxxxx] 852 Event max-interval No [RFCxxxx] 853 Subscription-State max-interval No [RFCxxxx] 854 Event average-interval No [RFCxxxx] 855 Subscription-State average-interval No [RFCxxxx] 857 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 858 this specification, when assigned.) 860 10. Security Considerations 862 Naturally, the security considerations listed in SIP events 863 [RFC3265], which the rate control mechanisms described in this 864 document extends, apply in entirety. In particular, authentication 865 and message integrity SHOULD be applied to subscriptions with this 866 extension. 868 11. Acknowledgments 870 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 871 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 872 Khartabil and Dale Worley for support and/or review of this work. 874 Thanks to Brian Rosen for the idea of the "force" and "average" 875 mechanisms, and to Adam Roach for the work on the averaging 876 algorithm. 878 12. References 880 12.1. Normative References 882 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 883 Requirement Levels", BCP 14, RFC 2119, March 1997. 885 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 886 A., Peterson, J., Sparks, R., Handley, M., and E. 887 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 888 June 2002. 890 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 891 Event Notification", RFC 3265, June 2002. 893 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 894 Initiation Protocol (SIP) Event Notification Extension for 895 Resource Lists", RFC 4662, August 2006. 897 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 898 Specifications: ABNF", STD 68, RFC 5234, January 2008. 900 12.2. Informative References 902 [I-D.ietf-geopriv-loc-filters] 903 Mahy, R. and B. Rosen, "A Document Format for Filtering 904 and Reporting Location Notications in the Presence 905 Information Document Format Location Object (PIDF-LO)", 906 draft-ietf-geopriv-loc-filters-03 (work in progress), 907 November 2008. 909 [I-D.ietf-sipcore-subnot-etags] 910 Niemi, A., "An Extension to Session Initiation Protocol 911 (SIP) Events for Conditional Event Notification", 912 draft-ietf-sipcore-subnot-etags-02 (work in progress), 913 April 2009. 915 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 916 Liu, Z., and J. Rosenberg, "Signaling Compression 917 (SigComp)", RFC 3320, January 2003. 919 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 920 Package for Registrations", RFC 3680, March 2004. 922 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 923 Indication Event Package for the Session Initiation 924 Protocol (SIP)", RFC 3842, August 2004. 926 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 927 Initiation Protocol (SIP)", RFC 3856, August 2004. 929 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 930 Package for the Session Initiation Protocol (SIP)", 931 RFC 3857, August 2004. 933 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 934 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 935 November 2004. 937 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 938 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 940 Authors' Addresses 942 Aki Niemi 943 Nokia 944 P.O. Box 407 945 NOKIA GROUP, FIN 00045 946 Finland 948 Phone: +358 50 389 1644 949 Email: aki.niemi@nokia.com 951 Krisztian Kiss 952 Nokia 953 313 Fairchild Dr 954 Mountain View, CA 94043 955 US 957 Phone: +1 650 391 5969 958 Email: krisztian.kiss@nokia.com 960 Salvatore Loreto 961 Ericsson 962 Hirsalantie 11 963 Jorvas 02420 964 Finland 966 Email: salvatore.loreto@ericsson.com