idnits 2.17.1 draft-niemi-sipping-event-throttle-08.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 872 has weird spacing: '...n-State thro...' == Line 874 has weird spacing: '...n-State forc...' == Line 876 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 "force" value higher than the "average" value, otherwise the notifier MUST not consider the "force" value. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 22, 2009) is 5539 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 876, but not defined == Unused Reference: 'RFC3261' is defined on line 905, 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 Summary: 1 error (**), 0 flaws (~~), 8 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 Intended status: Standards Track Nokia 5 Expires: August 26, 2009 S. Loreto 6 Ericsson 7 Feb 22, 2009 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Throttling 11 draft-niemi-sipping-event-throttle-08 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 August 26, 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 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. 48 Abstract 50 This memo specifies the throttle, forge and average mechanisms for 51 adjusting the rate of Session Initiation Protocol (SIP) event 52 notifications. These mechanisms can be applied in subscriptions to 53 all SIP event packages, but in particular the throttle mechanism is 54 especially designed to be used in combination with a subscription to 55 a Resource List Server (RLS). 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Definitions and Document Conventions . . . . . . . . . . . . . 5 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. Throttle Use Case . . . . . . . . . . . . . . . . . . . . 5 63 3.2. Force Use Case . . . . . . . . . . . . . . . . . . . . . . 6 64 3.3. Average Use Case . . . . . . . . . . . . . . . . . . . . . 7 65 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.5. Event Throttle Model for Resource List Server . . . . . . 8 67 3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10 68 3.7. Usage of Throttle, Force and Average in a subscription . . 11 69 4. Operation of Event Throttles . . . . . . . . . . . . . . . . . 12 70 4.1. Negotiating the Use of Throttle . . . . . . . . . . . . . 12 71 4.2. Setting the Throttle . . . . . . . . . . . . . . . . . . . 12 72 4.2.1. Subscriber Behavior . . . . . . . . . . . . . . . . . 12 73 4.2.2. Notifier Behavior . . . . . . . . . . . . . . . . . . 13 74 4.3. Selecting the Throttle Interval . . . . . . . . . . . . . 13 75 4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 14 76 4.4.1. Partial State Notifications . . . . . . . . . . . . . 14 77 4.4.2. Full State Notifications . . . . . . . . . . . . . . . 14 78 4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14 79 5. Operation of Event Force . . . . . . . . . . . . . . . . . . . 15 80 5.1. Negotiating the Use of Force . . . . . . . . . . . . . . . 15 81 5.2. Setting the Force . . . . . . . . . . . . . . . . . . . . 16 82 5.2.1. Subscriber Behavior . . . . . . . . . . . . . . . . . 16 83 5.2.2. Notifier Behavior . . . . . . . . . . . . . . . . . . 16 84 6. Operation of Event Average . . . . . . . . . . . . . . . . . . 17 85 6.1. Negotiating the Use of Average . . . . . . . . . . . . . . 17 86 6.2. Calculating the Average Interval . . . . . . . . . . . . . 17 87 6.3. Setting the Average . . . . . . . . . . . . . . . . . . . 18 88 6.3.1. Subscriber Behavior . . . . . . . . . . . . . . . . . 18 89 6.3.2. Notifier Behavior . . . . . . . . . . . . . . . . . . 18 90 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 91 7.1. "throttle", "force" and "average" Header Field 92 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 19 93 7.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 19 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 96 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 98 11.1. Normative References . . . . . . . . . . . . . . . . . . . 21 99 11.2. Informative References . . . . . . . . . . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 102 1. Introduction 104 The SIP events framework [RFC3265] defines a generic framework for 105 subscriptions to and notifications of events related to SIP systems. 106 This framework defines the methods SUBSCRIBE and NOTIFY, and 107 introduces the concept of an event package, which is a concrete 108 application of the SIP events framework to a particular class of 109 events. 111 One of the things the SIP events framework mandates is that each 112 event package specification defines an absolute maximum on the rate 113 at which notifications are allowed to be generated by a single 114 notifier. Such a limit is provided in order to reduce network 115 congestion. 117 All of the existing event package specifications include a maximum 118 notification rate recommendation, ranging from once in every five 119 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 121 Per the SIP events framework, each event package specification is 122 also allowed to define additional throttle mechanisms which allow the 123 subscriber to further limit the rate of event notification. So far 124 none of the event package specifications have defined such a 125 mechanism. 127 The resource list extension [RFC4662] to the SIP events framework 128 also deals with rate limiting of event notifications. The extension 129 allows a subscriber to subscribe to a heterogenous list of resources 130 with a single SUBSCRIBE request, rather than having to install a 131 subscription for each resource separately. The event list 132 subscription also allows rate limiting, or throttling of 133 notifications, by means of the Resource List Server (RLS) buffering 134 notifications of resource state changes, and sending them in batches. 135 However, the event list mechanism provides no means for the 136 subscriber to set the interval for the throttling; it is strictly an 137 implementation decision whether batching of notifications is 138 supported, and by what means. 140 This document defines an extension to the SIP events framework 141 defining the following three "Event" header field parameters that 142 allow a subscriber to set a Minimum, a Maximum and an Average rate of 143 event notifications generated by the notifier: 145 Throttle: specifies a minimum notification time period between two 146 notifications, in seconds. 148 Force: specifies a maximum notification time period between two 149 notifications, in seconds. Whenever the time since the most 150 recent notification exceeds the value in the "force" parameter, 151 then the current state would be sent in its entirety (just like 152 after a subscription refresh). 154 Average: specifies an average cadence at which notifications are 155 desired, in seconds. It works similar to the "force" parameter, 156 except that it will reduce the frequency at which notifications 157 are sent if several have already been sent recently. 159 The requirements and model are further discussed in Section 3. All 160 those mechanisms are simply timer values that indicates the minimum, 161 maximum and average time period allowed between two notifications. 162 As a result of those mechanism, a compliant notifier will adjust the 163 rate at which it generates notifications. 165 These mechanisms are applicable to any event subscription, both 166 single event subscription and event list subscription. 168 2. Definitions and Document Conventions 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119] and 173 indicate requirement levels for compliant implementations. 175 Indented passages such as this one are used in this document to 176 provide additional information and clarifying text. They do not 177 contain normative protocol behavior. 179 3. Overview 181 3.1. Throttle Use Case 183 A presence client in a mobile device contains a list of 100 buddies 184 or presentities. In order to decrease the processing and network 185 load of watching 100 presentities, the presence client has employed a 186 Resource List Server (RLS) with the list of buddies, and therefore 187 only needs a single subscription to the RLS in order to receive 188 notification of the presence state of the resource list. 190 In order to control the buffer policy of the RLS, the presence client 191 sets a throttle interval via the event throttle extension. 192 Alternatively, the presence client could set a default throttle for 193 the resource list, via a list manipulation interface, e.g., using the 194 XML Configuration Access Protocol (XCAP) [RFC4825]. 196 The RLS will buffer notifications that do not comply with the 197 throttle interval, and batch all of the buffered state changes 198 together in a single notification when allowed by the throttle. The 199 throttle applies to the overall resource list, which means that there 200 is a hard cap imposed by the throttle to the amount of traffic the 201 presence client can expect to receive. 203 For example, with a throttle of 20 seconds, the presence application 204 can expect to receive a notification every 20 seconds at a maximum. 206 The presence client can also modify the throttle during the lifetime 207 of the subscription. For example, if the User Interface (UI) of the 208 application shows inactivity for a period of time, it can simply 209 pause the notifications by setting the throttle interval to the 210 subscription expiration time, while still keeping the subscription 211 alive. When the user becomes active again, the presence client can 212 resume the stream of notifications by re-setting the throttle to the 213 earlier used value. 215 Currently, a subscription refresh is needed in order to update the 216 throttle interval. However, this is highly inefficient, since 217 each refresh automatically generates a (full-state) notification 218 carrying the latest resource state. There is work 219 [I-D.ietf-sip-subnot-etags] ongoing to solve these inefficiencies. 221 3.2. Force Use Case 223 A location application is monitoring the movement of a target. 225 In order to decrease the processing and network load, the location 226 application has made a subscription with a set of location filters 227 [I-D.ietf-geopriv-loc-filters] that specify, for example, to send an 228 update only when the target has moved at least 10 meters. However 229 the application is interested in receiving an update periodically 230 even if the target has not moved more than 10 meters in a second. 232 The application is interested in discovering if the state is changed, 233 even when it has not changed enough to satisfy any of the 'trigger' 234 criteria 235 In order to control the actual state, the location application sets a 236 force interval via the event force extension. The force triggers a 237 notification that is exactly and precisely like a notification after 238 a subscription refresh. 240 The location application can also modify the force during the 241 lifetime of the subscription. 243 3.3. Average Use Case 245 The throttle and force mechanisms introduce a static and 246 instantaneous rate control. However there are some applications that 247 would work better with an adaptive rate control (i.e. an average 248 rate). This section illustrates the tracking scenario. 250 A tracking application is monitoring a target. 252 In order to decrease the processing and network load, the tracking 253 application wants to make a subscription that dynamically reduces the 254 frequency at which notifications are sent if the target has started 255 to move sending out already several notifications recently. 257 In order to set an average rate control, the application defines a 258 average interval via the event average extension. The average value 259 is used by the notifier to dynamically calculate the maximum time 260 allowed between two subscriptions. In order to dinamically calculate 261 the maximum, the Notifer takes into consideration the frequency at 262 which notifications have been sent recently. 264 The average rate control allows the notifier to dynamically increase 265 or decrease the Notification frequency. 267 The tracking application can also modify the average interval during 268 the lifetime of the subscription by setting the event average 269 extension to a different value. 271 3.4. Requirements 273 REQ1: The subscriber must be able to set the minimum time 274 (throttle) period between two notifications in a specific 275 subscription. 277 REQ2: The subscriber must be able to set the maximum time period 278 (force) between two notifications in a specific subscription. 280 REQ3: The subscriber must be able to set an average cadence 281 (average) at which notifications are desired in a specific 282 subscription. 284 REQ4: It must be possible to apply all together, or in any 285 combination, the throttle, force and average mechanisms in a 286 specific subscription. 288 REQ5: It must be possible to use of the throttle, force and average 289 mechanisms in subscriptions to any events. 291 REQ6: It must be possible to use the throttle, force and average 292 mechanisms together with any other event filtering 293 mechanisms. 295 REQ7: The notifier must be allowed to use a throttling policy in 296 which the minimum time period between two notifications is 297 adjusted from the value given by the subscriber. 299 For example, due to congestion reasons, local policy at 300 the notifier could temporarily dictate a throttling policy 301 that in effect increases the subscriber-configured minimum 302 time period between two notifications. 304 REQ8: The throttle mechanism must discuss corner cases for setting 305 the minimum period between two notifications. At a minimum, 306 the throttling mechanism must include discussion of the 307 situation resulting from a minimum time period which exceeds 308 the subscription duration, and should provide mechanisms for 309 avoiding this situation. 311 REQ9: A throttle, force and average must be possible to be 312 installed, modified, or removed in the course of an active 313 subscription. 315 REQ10: A throttle, force and average mechanism must allow for the 316 application of authentication and integrity protection 317 mechanisms to subscriptions invoking that mechanism. 319 Note that Section 9 contains further discussion on the security 320 implications of the throttle mechanism. 322 3.5. Event Throttle Model for Resource List Server 324 When applied to a list subscription, the event throttle mechanism has 325 some additional considerations. Specifically, the throttle applies 326 to the aggregate notification stream resulting from the list 327 subscription, rather than explicitly controlling the notification of 328 each of the implied constituent events. Moreover, the list event 329 notifier can use the throttle mechanism on its own to control the 330 rate of the individual subscriptions to avoid overflowing its buffer. 332 The notifier is responsible for sending out event notifications upon 333 state changes of the subscribed resource.We can model the notifier as 334 consisting of three components: the event state resource(s), the 335 Resource List Server (RLS) (or any other notifier), a notification 336 buffer, and finally the subscriber, or watcher of the event state, as 337 shown in Figure 1. 339 +--------+ 340 | Event | 341 +--------+ |Resource| +--------+ 342 | Event | +--------+ | Event | 343 |Resource| | |Resource| 344 +---.=---+ | +---=----+ 345 `-.. | _.--' 346 ``-._ | _.--' 347 +'--'--'-+ 348 |Resource| 349 | List | 350 | Server | 351 +---.----+ 352 | 353 | 354 )--+---( 355 | | .--------. 356 |Buffer|<======'Throttle| 357 | | `--------' 358 )--.---( 359 | 360 | 361 .---+---. 362 | Event | 363 |Watcher| 364 `-------' 366 Figure 1: Model for the Resource List Server (RLS) Supporting 367 Throttling 369 In short, the RLS reads event state changes from the event state 370 resource, either by creating a backend subscription, or by other 371 means; it packages them into event notifications, and submits them 372 into the output buffer. The rate at which this output buffer drains 373 is controlled by the subscriber via the event throttle mechanism. 374 When a set of notifications are batched together, the way in which 375 overlapping resource state is handled depends on the type of the 376 resource state: 378 In theory, there are many buffer policies that the notifier could 379 implement. However, we only concentrate on two practical buffer 380 policies in this specification, leaving additional ones for 381 further study and out of the scope of this work. These two buffer 382 policies depend on the mode in which the notifier is operating. 384 Full-state: Last (most recent) full state notification of each 385 resource is sent out, and all others in the buffer are discarded. 386 This policy applies to those event packages that carry full-state 387 notifications. 389 Partial-state: The state deltas of each buffered partial 390 notification per resource are merged, and the resulting 391 notification is sent out. This policy applies to those event 392 packages that carry partial-state notifications. 394 3.6. Basic Operation 396 A subscriber that wants to limit the rate of event notification in a 397 specific event subscription does so by including a throttle as part 398 of the SUBSCRIBE request. The throttle indicating the minimum time 399 allowed between transmission of two consecutive notifications in a 400 subscription is given as an Event header parameter in the SUBSCRIBE 401 request. 403 Note that the witnessed time between two consecutive received 404 notifications may not conform to the set throttle for a number of 405 reasons. For example, network jitter and retransmissions may 406 result in the subscriber receiving the notifications in lesser 407 intervals than what the throttle recommends. 409 A subscriber that wants to have a maximum notification time period in 410 a specific event subscription does so by including a force as part of 411 the SUBSCRIBE request. The force indicating the maximum time allowed 412 between transmission of two consecutive notifications in a 413 subscription is given as an Event header parameter in the SUBSCRIBE 414 request. 416 A subscriber that wants to have an average cadence at which 417 notifications are desired in a specific event subscription does so by 418 including an average as part of the SUBSCRIBE request. The average 419 is given as an Event header parameter in the SUBSCRIBE request. 421 A notifier that supports the throttle, force and average mechanisms 422 will comply with value given in the throttle, force and average and 423 adjust its rate of notification accordingly. However, if the 424 notifier needs to lower the subscription expiration value or a local 425 policy at the notifier can not meet the requested throttle value, 426 then the notifier can adjust opportunely the received throttle value. 428 Throttled, forced and averaged notifications will have exactly the 429 same properties as the ones the un-throttled, un-forced and un- 430 averaged, with the exception that they will be generated with the 431 frequency that has been requested. 433 3.7. Usage of Throttle, Force and Average in a subscription 435 Applications can subscribe to an event package using all the 436 throttle, force and average mechanisms singly, or in combination; in 437 fact there is no technical incompatibility among them. However there 438 are some combinations that make little sense to be used together. 439 This section lists all the possible combinations that is possible to 440 insert in a subscription; the utility to use each combination in a 441 subscription is also analyzed. 443 Throttle and Force: this combination let possible to reduce the 444 notification frequence rate, but at same time assures the 445 reception of a notification every time the most recent 446 notification exceeds a specified interval. 448 A subscriber SHOULD choose a "force" value higher than the 449 "throttle" value, otherwise the notifier MUST adjust the 450 subscriber provided "force" value to a value equivalent or higher 451 than the "throttle" value. 453 Throttle and Average: it works in a similar way as the combination 454 above, but with the difference that the interval at which 455 notifications are assured changes dynamically. 457 A subscriber SHOULD choose an "average" value higher than the 458 "throttle" value, otherwise the notifier MUST adjust the 459 subscriber provided "average" value to a value equivalent or 460 higher than the "throttle" value. 462 Force and Average: as both the parameters are designed to force an 463 update, this combination makes sense only in some corner cases. 465 A subscriber SHOULD choose a "force" value higher than the 466 "average" value, otherwise the notifier MUST not consider the 467 "force" value. 469 Throttle, Force and Average: this combination makes little sense to 470 be used. 472 4. Operation of Event Throttles 474 4.1. Negotiating the Use of Throttle 476 A subscriber that wishes to apply a throttle to notifications in a 477 subscription constructs a SUBSCRIBE request that includes a throttle 478 interval in a "throttle" Event header field parameter. 480 A compliant notifier will reflect back the possibly adjusted throttle 481 interval in a "throttle" Subscription-State header field parameter of 482 the subsequent NOTIFY requests. The indicated throttle value is 483 adopted by the notifier, and the notification rate is adjusted 484 accordingly. 486 A notifier that does not understand the event-throttle extension, 487 will not reflect the "throttle" parameter in the NOTIFY requests; the 488 absence of this parameter serves as a hint to the subscriber that no 489 throttling is supported by the notifier. 491 A subscriber that wishes to remove a throttle from notifications 492 constructs a SUBSCRIBE request that does not include a "throttle" 493 Event header field parameter. 495 4.2. Setting the Throttle 497 4.2.1. Subscriber Behavior 499 In general, the way in which a subscriber generates SUBSCRIBE 500 requests and processes NOTIFY requests is according to RFC 3265 501 [RFC3265]. 503 A subscriber that wishes to throttle the notifications in a 504 subscription includes a "throttle" Event header parameter in the 505 SUBSCRIBE request, indicating in seconds the desired throttle value. 506 The value of this parameter is an integral number of seconds in 507 decimal. 509 There are two main consequences for the subscriber when applying the 510 throttle mechanism: state transitions may be lost, and event 511 notifications may be delayed. If either of these side effects 512 constitute a problem to the application that is to utilize event 513 throttles, developers are instructed not to use the mechanism. 515 4.2.2. Notifier Behavior 517 In general, the way in which a notifier processes SUBSCRIBE requests 518 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 520 A notifier that supports the event-throttle extension extracts the 521 value of the "throttle" Event header parameter, and uses it as the 522 suggested minimum time allowed between two notifications. This value 523 can be adjusted by the notifier, as defined in Section 4.3. 525 The notifier MUST reflect back the possibly adjusted throttle 526 interval in a "throttle" Subscription-State header field parameter of 527 the subsequent NOTIFY requests. 529 A compliant notifier MUST NOT generate notifications more frequent 530 than what the throttle allows for, except when generating the 531 notification either upon receipt of a SUBSCRIBE request (the first 532 notification), when the subscription state is changing from "pending" 533 to "active" state or upon termination of the subscription (the last 534 notification). Such notifications reset the throttle timer, even 535 though they do not need to abide by it. 537 Retransmissions of NOTIFY requests are not affected by the throttle, 538 i.e., the throttle only applies to the generation of new 539 transactions. In other words, the throttle is reset only after the 540 previous transaction has completed. 542 4.3. Selecting the Throttle Interval 544 Special care needs to be taken when selecting the throttle value. 545 Using the throttle syntax it is possible to insist both very short 546 and very long throttles to be applied to the subscription. For 547 example, a throttle could potentially set a minimum time value 548 between notifications that exceeds the subscription expiration value. 549 Such a configuration would effectively quench the notifier, resulting 550 in exactly two notifications to be generated. 552 In some cases it makes sense to pause the notification stream on an 553 existing subscription dialog on a temporary basis without terminating 554 the subscription, e.g. due to inactivity on the application UI. 555 Whenever a subscriber discovers the need to perform the notification 556 pause operation, it SHOULD set the throttle interval to the remaining 557 subscription expiration value. This results in receiving no further 558 notifications until the subscription expires, renewed or 559 notifications are resumed by the subscriber. 561 The notifier is responsible for adjusting the proposed throttle value 562 based on its local policy or other properties. 564 If the subscriber requests a throttle greater than the subscription 565 expiration,the notifier MUST lower the throttle value and set it to 566 the expiration time left. According to RFC 3265 [RFC3265] the 567 notifier may also shorten the subscription expiry anytime during an 568 active subscription. For such cases, the notifier MUST also lower 569 the throttle value and set it to the reduced expiration time. 571 The notifier MAY also choose a higher throttle value, e.g., because 572 of static throttle value configuration given by local policy. The 573 notifier MUST include the adjusted throttle value in the 574 Subscription-State header field's "throttle" parameter in each of the 575 NOTIFY requests. In addition, different event packages MAY define 576 additional constraints to the allowed throttle intervals. Such 577 constraints are out of the scope of this specification. 579 4.4. Buffer Policy Description 581 4.4.1. Partial State Notifications 583 With partial notifications, the notifier will always need to keep 584 both a copy of the current full state of the resource F, as well as 585 the last successfully communicated full state view F' of the resource 586 in a specific subscription. The construction of a partial 587 notification then involves creating a diff of the two states, and 588 generating a notification that contains that diff. 590 When a throttle is applied to the subscription, it is important that 591 F' is replaced with F only when the throttle is reset. Additionally, 592 the notifier implementation SHOULD check to see that the size of an 593 accumulated partial state notification is smaller than the full 594 state, and if not, the notifier SHOULD send the full state 595 notification instead. 597 4.4.2. Full State Notifications 599 With full state notifications, the notifier only needs to keep the 600 full state of the resource, and when that changes, send the resulting 601 notification over to the subscriber. 603 When a throttle is applied in the subscription, the notifier receives 604 the state changes of the resource, and generates a notification. If 605 there is a pending notification, the notifier simply replaces that 606 notification with the new notification, discarding the older state. 608 4.5. Estimated Bandwidth Savings 610 It is difficult to estimate the total bandwidth savings accrued by 611 using the throttle mechanism over a subscription, since such 612 estimates will vary depending on the usage scenarios. However, it is 613 easy to see that given a subscription where several full state 614 notification would have normally been sent in any given throttle 615 interval, a throttled subscription would only send a single 616 notification during the same interval, yielding bandwidth savings of 617 several times the notification size. 619 With partial-state notifications, drawing estimates is further 620 complicated by the fact that the states of consecutive updates may or 621 may not overlap. However, even in the worst case scenario, where 622 each partial update is to a different part of the full state, a 623 throttled notification merging all of these n partial states together 624 should at a maximum be the size of a full-state update. In this 625 case, the bandwidth savings are approximately n times the size of the 626 NOTIFY header. 628 It is also true that there are several compression schemes available 629 that have been designed to save bandwidth in SIP, e.g., SigComp 630 [RFC3320] and TLS compression [RFC3943]. However, such compression 631 schemes are complementary rather than competing mechanisms to the 632 throttle mechanism. After all, they can both be applied 633 simultaneously, and in such a way that the compound savings are as 634 good as the sum of applying each one alone. 636 5. Operation of Event Force 638 5.1. Negotiating the Use of Force 640 A subscriber that wishes to apply a maximum notification time period 641 between two notifications in a subscription constructs a SUBSCRIBE 642 request that includes a proposed maximum interval in a "force" Event 643 header field parameter. 645 A compliant notifier will reflect back the possibly adjusted forced 646 interval in a "force" Subscription-State header field parameter of 647 the subsequent NOTIFY requests. The indicated force value is adopted 648 by the notifier, and the notification rate is adjusted accordingly. 650 A notifier that does not understand the event-force extension, will 651 not reflect the "force" parameter in the NOTIFY requests; the absence 652 of this parameter serves as a hint to the subscriber that no forcing 653 is supported by the notifier. 655 A subscriber that wishes to remove a force from notifications 656 constructs a SUBSCRIBE request that does not include a "force" Event 657 header field parameter. 659 5.2. Setting the Force 661 5.2.1. Subscriber Behavior 663 In general, the way in which a subscriber generates SUBSCRIBE 664 requests and processes NOTIFY requests is according to RFC 3265 665 [RFC3265]. 667 A subscriber that wishes to apply a maximum notification time period 668 between the notifications in a subscription includes a "force" Event 669 header parameter in the SUBSCRIBE request, indicating in seconds the 670 desired force value. The value of this parameter is an integral 671 number of seconds in decimal. 673 The main consequence for the subscriber when applying the force 674 mechanism is that it can receive a notification even if nothing has 675 changed in the current state of the notifier. 677 There is work [I-D.ietf-sip-subnot-etags] ongoing to only send a 678 reference in a notification if nothing has changed. 680 5.2.2. Notifier Behavior 682 In general, the way in which a notifier processes SUBSCRIBE requests 683 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 685 A notifier that supports the event-force extension extracts the value 686 of the "force" Event header parameter, and uses it as the suggested 687 maximum time allowed between two notifications. This value can be 688 adjusted by the notifier based on its local policy or other 689 properties. 691 The notifier MUST reflect back the possibly adjusted force value in a 692 "force" Subscription-State header field parameter of the subsequent 693 NOTIFY requests. 695 A compliant notifier MUST generate notifications whenever the time 696 since the most recent notification exceeds the value in the "force" 697 parameter. The NOTIFY request then MUST contain the current state in 698 its entirety, just like after a subscription refresh. 700 Retransmissions of NOTIFY requests are not affected by the force, 701 i.e., the force only applies to the generation of new transactions. 702 In other words, the force is reset only after the previous 703 transaction has completed. 705 6. Operation of Event Average 707 6.1. Negotiating the Use of Average 709 A subscriber that wishes to apply an average cadence at which 710 notifications are desired in a subscription constructs a SUBSCRIBE 711 request that includes a proposed average interval in an "average" 712 Event header field parameter. 714 A compliant notifier will reflect back the possibly adjusted average 715 interval in an "average" Subscription-State header field parameter of 716 the subsequent NOTIFY requests. The indicated average value is 717 adopted by the notifier, and the notification rate is adjusted 718 accordingly. 720 A notifier that does not understand the event-average extension will 721 not reflect the "average" parameter in the NOTIFY requests; the 722 absence of this parameter serves as a hint to the subscriber that no 723 averaging is supported by the notifier. 725 A subscriber that wishes to remove a average from notifications 726 constructs a SUBSCRIBE request that does not include an "average" 727 Event header field parameter. 729 6.2. Calculating the Average Interval 731 The formula used to vary the absolute pacing in a way that will meet 732 the average requested over the period is given in equation (1): 734 timeout = (average ^ 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: The value of the "average" parameter conveyed in the 740 "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 the case both the Throttle and the Average are used in the same 752 subscription the formula used to dynamically calculate the timeout is 753 given in equation (2): 755 timeout = MAX[throttle, (average ^ 2) * count / period] (2) 757 throttle: The value of the "threshold" parameter conveyed in the 758 "Event" header field, in seconds. 760 The formula in (2) makes sure that for all the possible value of 761 throttle and average, with average > throttle, the timeout never 762 results in a lower value than throttle. 764 6.3. Setting the Average 766 6.3.1. Subscriber Behavior 768 In general, the way in which a subscriber generates SUBSCRIBE 769 requests and processes NOTIFY requests is according to RFC 3265 770 [RFC3265]. 772 A subscriber that wishes to apply an average cadence at which 773 notifications are desired in a subscription includes a "average" 774 Event header parameter in the SUBSCRIBE request, indicating in 775 seconds the desired average value. The value of this parameter is an 776 integral number of seconds in decimal. 778 The main consequence for the subscriber when applying the average 779 mechanism is that it can receive a notification even if nothing has 780 changed in the current state of the notifier. 782 There is work [I-D.ietf-sip-subnot-etags] ongoing to only send a 783 reference in a notification if nothing has changed. 785 6.3.2. Notifier Behavior 787 In general, the way in which a notifier processes SUBSCRIBE requests 788 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 790 A notifier that supports the event-average extension extracts the 791 value of the "average" Event header parameter, and uses it to 792 calculate the maximum time allowed between two transactions as 793 defined in Section 6.2. This value can be adjusted by the notifier 794 based on its local policy or other properties. 796 The notifier MUST reflect back the possibly adjusted average value in 797 a "average" Subscription-State header field parameter of the 798 subsequent NOTIFY requests. 800 A compliant notifier MUST generate notifications whenever the time 801 since the most recent notification exceeds the value calculated using 802 the formula defined in Section 6.2. 804 The Average mechanism is implemented as follows: 806 1) When a subscription is first created, the notifier creates a 807 record that keeps track of the number of notifications that have 808 been sent in the "period". This record is initialized to contain 809 a history of having sent one message every "average" seconds for 810 the "period". 812 2) The "timeout" value is calculated according to the equation given 813 in section Section 6.2. 815 3) If the timeout period passes without a NOTIFY request being sent 816 in the subscription, then the current resource state is sent 817 (subject to any filtering associated with the subscription). 819 4) Whenever a NOTIFY request is sent (regardless of whether due to a 820 timeout or a state change), the notifier updates the notification 821 history record, recalculates the value of "timeout," and returns 822 to step 3. 824 Retransmissions of NOTIFY requests are not affected by the timeout, 825 i.e., the timeout only applies to the generation of new transactions. 826 In other words, the timeout is reset only after the previous 827 transaction has completed. 829 7. Syntax 831 This section describes the syntax extensions required for the 832 throttle, force and average mechanisms. 834 7.1. "throttle", "force" and "average" Header Field Parameters 836 The "throttle", "force" and "average" parameters are added to the 837 rule definitions of the Event header field and the Subscription-State 838 header field in the SIP Events [RFC3265] grammar. Usage of this 839 parameter is described in section Section 4.2. 841 7.2. Augmented BNF Definitions 843 This section describes the Augmented BNF [RFC5234] definitions for 844 the new syntax elements. Note that we derive here from the ruleset 845 present in SIP Events [RFC3265], adding additional alternatives to 846 the alternative sets of "event-param" and "subexp-params" defined 847 therein. 849 event-param =/ throttle-param 850 subexp-params =/ throttle-param 851 throttle-param = "throttle" EQUAL delta-seconds 853 event-param =/ force-param 854 subexp-params =/ force-param 855 throttle-param = "force" EQUAL delta-seconds 857 event-param =/ average-param 858 subexp-params =/ average-param 859 throttle-param = "average" EQUAL delta-seconds 861 8. IANA Considerations 863 This specification registers three new SIP header field parameters, 864 defined by the following information which is to be added to the 865 Header Field Parameters and Parameter Values sub-registry under 866 http://www.iana.org/assignments/sip-parameters. 868 Predefined 869 Header Field Parameter Name Values Reference 870 -------------------- --------------- ---------- --------- 871 Event throttle No [RFCxxxx] 872 Subscription-State throttle No [RFCxxxx] 873 Event force No [RFCxxxx] 874 Subscription-State force No [RFCxxxx] 875 Event average No [RFCxxxx] 876 Subscription-State average No [RFCxxxx] 878 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 879 this specification, when assigned.) 881 9. Security Considerations 883 Naturally, the security considerations listed in SIP events 884 [RFC3265], which the throttle mechanism extends, apply in entirety. 885 In particular, authentication and message integrity SHOULD be applied 886 to subscriptions with the event-throttle extension. 888 10. Acknowledgements 890 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 891 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 892 Khartabil and Dale Worley for support and/or review of this work. 894 Thanks to Brian Rosen for the idea of the "force" and "average" 895 mechanisms, and to Adam Roach for the work on the averaging 896 algorithm. 898 11. References 900 11.1. Normative References 902 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 903 Requirement Levels", BCP 14, RFC 2119, March 1997. 905 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 906 A., Peterson, J., Sparks, R., Handley, M., and E. 907 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 908 June 2002. 910 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 911 Event Notification", RFC 3265, June 2002. 913 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 914 Initiation Protocol (SIP) Event Notification Extension for 915 Resource Lists", RFC 4662, August 2006. 917 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 918 Specifications: ABNF", STD 68, RFC 5234, January 2008. 920 11.2. Informative References 922 [I-D.ietf-geopriv-loc-filters] 923 Mahy, R. and B. Rosen, "A Document Format for Filtering 924 and Reporting Location Notications in the Presence 925 Information Document Format Location Object (PIDF-LO)", 926 draft-ietf-geopriv-loc-filters-03 (work in progress), 927 November 2008. 929 [I-D.ietf-sip-subnot-etags] 930 Niemi, A., "An Extension to Session Initiation Protocol 931 (SIP) Events for Conditional Event Notification", 932 draft-ietf-sip-subnot-etags-03 (work in progress), 933 July 2008. 935 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 936 Liu, Z., and J. Rosenberg, "Signaling Compression 937 (SigComp)", RFC 3320, January 2003. 939 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 940 Package for Registrations", RFC 3680, March 2004. 942 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 943 Indication Event Package for the Session Initiation 944 Protocol (SIP)", RFC 3842, August 2004. 946 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 947 Initiation Protocol (SIP)", RFC 3856, August 2004. 949 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 950 Package for the Session Initiation Protocol (SIP)", 951 RFC 3857, August 2004. 953 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 954 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 955 November 2004. 957 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 958 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 960 Authors' Addresses 962 Aki Niemi 963 Nokia 964 P.O. Box 407 965 NOKIA GROUP, FIN 00045 966 Finland 968 Phone: +358 50 389 1644 969 Email: aki.niemi@nokia.com 971 Krisztian Kiss 972 Nokia 973 313 Fairchild Dr 974 Mountain View, CA 94043 975 US 977 Phone: +1 650 391 5969 978 Email: krisztian.kiss@nokia.com 979 Salvatore Loreto 980 Ericsson 981 Hirsalantie 11 982 Jorvas 02420 983 Finland 985 Email: salvatore.loreto@ericsson.com