idnits 2.17.1 draft-ietf-sipcore-event-rate-control-01.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 916 has weird spacing: '...n-State min-...' == Line 918 has weird spacing: '...n-State max-...' == Line 920 has weird spacing: '...n-State aver...' -- The document date (October 28, 2009) is 5293 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 798, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 920, but not defined == Unused Reference: 'RFC3261' is defined on line 951, 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-07 == Outdated reference: A later version (-04) exists of draft-ietf-sipcore-subnot-etags-02 Summary: 2 errors (**), 0 flaws (~~), 9 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: May 1, 2010 S. Loreto 6 Ericsson 7 October 28, 2009 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-01 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 May 1, 2010. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Definitions and Document Conventions . . . . . . . . . . . . . 5 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Use Case for limiting the maximum rate of notifications . 5 59 3.2. Use Case for setting a minimum rate for notifications . . 6 60 3.3. Use Case for specifying the average rate of 61 notifications . . . . . . . . . . . . . . . . . . . . . . 7 62 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.5. The maximum rate mechanism for Resource List Server . . . 9 64 3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 10 65 4. Operation of the maximum rate mechanism . . . . . . . . . . . 11 66 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 11 67 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 12 68 4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 13 69 4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 14 70 4.4.1. Partial State Notifications . . . . . . . . . . . . . 14 71 4.4.2. Full State Notifications . . . . . . . . . . . . . . . 14 72 4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14 73 5. Operation of the minimum rate mechanism . . . . . . . . . . . 15 74 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 15 75 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 16 76 6. Operation of the average rate mechanism . . . . . . . . . . . 16 77 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16 78 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17 79 6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 18 80 7. Usage of "min-interval", "max-interval" and 81 "average-interval" in a combination . . . . . . . . . . . . . 19 82 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 8.1. "min-interval", "max-interval" and "average-interval" 84 Header Field Parameters . . . . . . . . . . . . . . . . . 20 85 8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 20 86 8.3. Event header field usage in responses to the NOTIFY 87 request . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 93 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 97 1. Introduction 99 The SIP events framework [RFC3265] defines a generic framework for 100 subscriptions to and notifications of events related to SIP systems. 101 This framework defines the methods SUBSCRIBE and NOTIFY, and 102 introduces the concept of an event package, which is a concrete 103 application of the SIP events framework to a particular class of 104 events. 106 One of the things the SIP events framework mandates is that each 107 event package specification defines an absolute maximum on the rate 108 at which notifications are allowed to be generated by a single 109 notifier. Such a limit is provided in order to reduce network 110 congestion. 112 All of the existing event package specifications include a maximum 113 notification rate recommendation, ranging from once in every five 114 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 116 Per the SIP events framework, each event package specification is 117 also allowed to define additional throttle mechanisms which allow the 118 subscriber to further limit the rate of event notification. So far 119 none of the event package specifications have defined such a 120 mechanism. 122 The resource list extension [RFC4662] to the SIP events framework 123 also deals with rate limiting of event notifications. The extension 124 allows a subscriber to subscribe to a heterogeneous list of resources 125 with a single SUBSCRIBE request, rather than having to install a 126 subscription for each resource separately. The event list 127 subscription also allows rate limiting, or throttling of 128 notifications, by means of the Resource List Server (RLS) buffering 129 notifications of resource state changes, and sending them in batches. 130 However, the event list mechanism provides no means for the 131 subscriber to set the interval for the throttling; it is strictly an 132 implementation decision whether batching of notifications is 133 supported, and by what means. 135 This document defines an extension to the SIP events framework 136 defining the following three "Event" header field parameters that 137 allow a subscriber to set a Minimum, a Maximum and an Average rate of 138 event notifications generated by the notifier: 140 min-interval: specifies a minimum notification time period between 141 two notifications, in seconds. 143 max-interval: specifies a maximum notification time period between 144 two notifications, in seconds. Whenever the time since the most 145 recent notification exceeds the value in the "max-interval" 146 parameter, then the current state would be sent in its entirety, 147 just like after a subscription refresh. 149 average-interval: specifies an average cadence at which 150 notifications are desired, in seconds. It works similar to the 151 "max-interval" parameter, except that it will reduce the frequency 152 at which notifications are sent if several have already been sent 153 recently. 155 The requirements and model are further discussed in Section 3. All 156 those mechanisms are simply timer values that indicates the minimum, 157 maximum and average time period allowed between two notifications. 158 As a result of those mechanism, a compliant notifier will adjust the 159 rate at which it generates notifications. 161 These mechanisms are applicable to any event subscription, both 162 single event subscription and event list subscription. 164 2. Definitions and Document Conventions 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119] and 169 indicate requirement levels for compliant implementations. 171 Indented passages such as this one are used in this document to 172 provide additional information and clarifying text. They do not 173 contain normative protocol behavior. 175 3. Overview 177 3.1. Use Case for limiting the maximum rate of notifications 179 A presence client in a mobile device contains a list of 100 buddies 180 or presentities. In order to decrease the processing and network 181 load of watching 100 presentities, the presence client has employed a 182 Resource List Server (RLS) with the list of buddies, and therefore 183 only needs a single subscription to the RLS in order to receive 184 notification of the presence state of the resource list. 186 In order to control the buffer policy of the RLS, the presence client 187 sets a maximum rate ("min-interval" parameter), i.e. a minimum time 188 interval between two notifications. Alternatively, the presence 189 client could set the maximum rate for the resource list via a list 190 manipulation interface, e.g., using the XML Configuration Access 191 Protocol (XCAP) [RFC4825]. 193 The RLS will buffer notifications that do not comply with the maximum 194 rate and batch all of the buffered state changes together in a single 195 notification only when allowed by the maximum rate. The maximum rate 196 applies to the overall resource list, which means that there is a 197 hard cap imposed by the maximum rate to the amount of traffic the 198 presence client can expect to receive. 200 For example, with a "min-interval" of 20 seconds, the presence 201 application can expect to receive a notification at a minimum of 202 every 20 seconds. 204 The presence client can also modify the "min-interval" parameter 205 during the lifetime of the subscription. For example, if the User 206 Interface (UI) of the application shows inactivity for a period of 207 time, it can simply pause the notifications by setting the "min- 208 interval" parameter to the subscription expiration time, while still 209 keeping the subscription alive. When the user becomes active again, 210 the presence client can resume the stream of notifications by re- 211 setting the "min-interval" parameter to the earlier used value. 213 Currently, a subscription refresh is needed in order to update the 214 maximum rate. However, this is highly inefficient, since each 215 refresh automatically generates a (full-state) notification 216 carrying the latest resource state. There is work 217 [I-D.ietf-sipcore-subnot-etags] ongoing to solve these 218 inefficiencies. 220 3.2. Use Case for setting a minimum rate for notifications 222 A location application is monitoring the movement of a target. 224 In order to decrease the processing and network load, the location 225 application has made a subscription with a set of location filters 226 [I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for 227 example, to send an update only when the target has moved at least n 228 meters. However, the application is also interested to receive the 229 current state periodically even if the state of the target has not 230 changed enough to satisfy any of the trigger criteria, i.e. has not 231 moved at least n meters within the period. 233 In order to control the actual state, the location application sets a 234 minimum rate ("max-interval" parameter), i.e. a maximum time interval 235 between two notifications. 237 The location application can also modify the "max-interval" parameter 238 during the lifetime of the subscription. When the subscription to 239 the movement of a target is made, the notifier does not typically 240 have the location information available. Thus, the first 241 notification might be empty, or certain values might be absent. An 242 important use case is placing constraints on when complete state 243 should be provided after creating the subscription. The "max- 244 interval" parameter indicates to the notifier the time when to 245 generate a notification containing complete state information. Once 246 state is acquired and the second notification is sent, the subscriber 247 updates or changes the "max-interval" parameter to a more sensible 248 value. This update can be performed in the 200 OK response to the 249 NOTIFY request that contains the complete state information. 251 3.3. Use Case for specifying the average rate of notifications 253 The previous mechanisms introduce a static and instantaneous rate 254 control. However there are some applications that would work better 255 with an adaptive rate control. This section illustrates the tracking 256 scenario. 258 A tracking application is monitoring a target. 260 In order to decrease the processing and network load, the tracking 261 application wants to make a subscription that dynamically increases 262 the interval between notifications if the target has sent out several 263 notifications recently. 265 In order to set an adaptive rate control, the application defines a 266 average cadence ("average-interval" parameter) at which notifications 267 are desired. The "average-interval" parameter value is used by the 268 notifier to dynamically calculate the maximum time allowed between 269 two subscriptions. In order to dynamically calculate the maximum, 270 the Notifier takes into consideration the frequency at which 271 notifications have been sent recently. 273 This type of rate control allows the notifier to dynamically increase 274 or decrease the Notification frequency. 276 The tracking application can also modify the "average-interval" 277 parameter during the lifetime of the subscription. 279 3.4. Requirements 280 REQ1: The subscriber must be able to set the minimum time period 281 ("min-interval" parameter) between two notifications in a 282 specific subscription. 284 REQ2: The subscriber must be able to set the maximum time period 285 ("max-interval" parameter) between two notifications in a 286 specific subscription. 288 REQ3: The subscriber must be able to set an average cadence 289 ("average-interval" parameter) at which notifications are 290 desired in a specific subscription. 292 REQ4: It must be possible to apply all together, or in any 293 combination, the "min-interval", "max-interval" and "average- 294 interval" mechanisms in a specific subscription. 296 REQ5: It must be possible to use of the different rate control 297 mechanisms in subscriptions to any events. 299 REQ6: It must be possible to use the different rate control 300 mechanisms together with any other event filtering 301 mechanisms. 303 REQ7: The notifier must be allowed to use a policy in which the 304 minimum time period between two notifications is adjusted 305 from the value given by the subscriber. 307 For example, due to congestion reasons, local policy at 308 the notifier could temporarily dictate a policy that in 309 effect increases the subscriber-configured minimum time 310 period between two notifications. 312 REQ8: The different rate control mechanisms must discuss corner 313 cases for setting the time periods between two notifications. 314 At a minimum, the mechanisms must include discussion of the 315 situation resulting from a minimum, maximum or average time 316 period which exceeds the subscription duration, and should 317 provide mechanisms for avoiding this situation. 319 REQ9: The different rate control mechanisms must be possible to be 320 installed, modified, or removed in the course of an active 321 subscription. 323 REQ10: The different rate control mechanisms must allow for the 324 application of authentication and integrity protection 325 mechanisms to subscriptions invoking that mechanism. 327 Note that Section 10 contains further discussion on the security 328 implications of the different rate control mechanisms. 330 3.5. The maximum rate mechanism for Resource List Server 332 When applied to a list subscription, the maximum rate mechanism has 333 some additional considerations. Specifically, the maximum rate 334 applies to the aggregate notification stream resulting from the list 335 subscription, rather than explicitly controlling the notification of 336 each of the implied constituent events. Moreover, the list event 337 notifier can use the maximum rate mechanism on its own to control the 338 rate of the individual subscriptions to avoid overflowing its buffer. 340 The notifier is responsible for sending out event notifications upon 341 state changes of the subscribed resource. We can model the notifier 342 as consisting of three components: the event state resource(s), the 343 Resource List Server (RLS) (or any other notifier), a notification 344 buffer, and finally the subscriber, or watcher of the event state, as 345 shown in Figure 1. 347 +--------+ 348 | Event | 349 +--------+ |Resource| +--------+ 350 | Event | +--------+ | Event | 351 |Resource| | |Resource| 352 +---.=---+ | +---=----+ 353 `-.. | _.--' 354 ``-._ | _.--' 355 +'--'--'-+ 356 |Resource| 357 | List | 358 | Server | 359 +---.----+ 360 | 361 | 362 )--+---( 363 | | .------------. 364 |Buffer|<======'min-interval| 365 | | `------------' 366 )--.---( 367 | 368 | 369 .---+---. 370 | Event | 371 |Watcher| 372 `-------' 374 Figure 1: Model for the Resource List Server (RLS) Supporting 375 Throttling 377 In short, the RLS reads event state changes from the event state 378 resource, either by creating a back end subscription, or by other 379 means; it packages them into event notifications, and submits them 380 into the output buffer. The rate at which this output buffer drains 381 is controlled by the subscriber via the maximum rate mechanism. When 382 a set of notifications are batched together, the way in which 383 overlapping resource state is handled depends on the type of the 384 resource state: 386 In theory, there are many buffer policies that the notifier could 387 implement. However, we only concentrate on two practical buffer 388 policies in this specification, leaving additional ones for 389 further study and out of the scope of this work. These two buffer 390 policies depend on the mode in which the notifier is operating. 392 Full-state: Last (most recent) full state notification of each 393 resource is sent out, and all others in the buffer are discarded. 394 This policy applies to those event packages that carry full-state 395 notifications. 397 Partial-state: The state deltas of each buffered partial 398 notification per resource are merged, and the resulting 399 notification is sent out. This policy applies to those event 400 packages that carry partial-state notifications. 402 3.6. Basic Operation 404 A subscriber that wants to limit the rate of event notification in a 405 specific event subscription does so by including a "min-interval" 406 Event header parameter as part of the SUBSCRIBE request. The "min- 407 interval" value indicates the minimum time allowed between 408 transmission of two consecutive notifications in a subscription. 410 Note that the witnessed time between two consecutive received 411 notifications may not conform to the "min-interval" value for a 412 number of reasons. For example, network jitter and 413 retransmissions may result in the subscriber receiving the 414 notifications with smaller intervals than the "min-interval" value 415 recommends. 417 A subscriber that wants to have a maximum notification time period in 418 a specific event subscription does so by including a "max-interval" 419 Event header parameter as part of the SUBSCRIBE request. The "max- 420 interval" value indicates the maximum time allowed between 421 transmission of two consecutive notifications in a subscription. 423 A subscriber that wants to have an average cadence for the 424 notifications in a specific event subscription does so by including a 425 "average-interval" Event header parameter as part of the SUBSCRIBE 426 request. 428 A subscriber that wants to update a previously agreed event rate 429 control parameter does so by including the updated "min-interval", 430 "max-interval" or "average-interval" Event header parameter as part 431 of a subsequent SUBSCRIBE request or a 200-class response to the 432 NOTIFY request. 434 A notifier that supports the different rate control mechanisms will 435 comply with the value given in "min-interval", "max-interval" and 436 "average-interval" parameters and adjust its rate of notification 437 accordingly. However, if the notifier needs to lower the 438 subscription expiration value or a local policy or other 439 implementation-determined constraint at the notifier can not satisfy 440 the rate control request, then the notifier can adjust opportunely 441 the subscriber requested rate control. 443 Rate controlled notifications will have exactly the same properties 444 as the ones without rate control, with the exception that they will 445 be generated within the timing constraints requested. 447 4. Operation of the maximum rate mechanism 449 4.1. Subscriber Behavior 451 In general, the way in which a subscriber generates SUBSCRIBE 452 requests and processes NOTIFY requests is according to RFC 3265 453 [RFC3265]. 455 A subscriber that wishes to apply a maximum rate to notifications in 456 a subscription MUST construct a SUBSCRIBE request that includes a 457 minimum time interval between two consecutive notifications included 458 in the "min-interval" Event header field parameter. The value of 459 this parameter is an integral number of seconds in decimal. 461 Subscribers implementing the maximum rate mechanism MUST include an 462 Event header field in any 200-class responses to NOTIFY requests. 464 A subscriber that wishes to update the previously agreed maximum rate 465 of notifications MUST include the updated "min-interval" Event header 466 field parameter in a subsequent SUBSCRIBE request or a 200-class 467 response to the NOTIFY request. 469 A subscriber that wishes to remove the maximum rate control from 470 notifications MUST indicate so by not including a "min-interval" 471 Event header field parameter in a subsequent SUBSCRIBE request or a 472 200-class response to the NOTIFY request. 474 There are two main consequences for the subscriber when applying the 475 maximum rate mechanism: state transitions may be lost, and event 476 notifications may be delayed. If either of these side effects 477 constitute a problem to the application that is to utilize event 478 notifications, developers are instructed not to use the mechanism. 480 4.2. Notifier Behavior 482 In general, the way in which a notifier processes SUBSCRIBE requests 483 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 485 A notifier that supports the maximum rate mechanism MUST extract the 486 value of the "min-interval" Event header parameter from a SUBSCRIBE 487 request or a 200-class response to the NOTIFY request and use it as 488 the suggested time allowed between two notifications. This value can 489 be adjusted by the notifier, as defined in Section 4.3. 491 A compliant notifier MUST reflect back the possibly adjusted minimum 492 time interval in a "min-interval" Subscription-State header field 493 parameter of the subsequent NOTIFY requests. The indicated "min- 494 interval" value is adopted by the notifier, and the notification rate 495 is adjusted accordingly. 497 A notifier that does not understand this extension will not reflect 498 the "min-interval" Subscription-State header field parameter in the 499 NOTIFY requests; the absence of this parameter serves as a hint to 500 the subscriber that no rate control is supported by the notifier. 502 A compliant notifier MUST NOT generate notifications more frequently 503 than the maximum rate allows for, except when generating the 504 notification either upon receipt of a SUBSCRIBE request (the first 505 notification), when the subscription state is changing from "pending" 506 to "active" state or upon termination of the subscription (the last 507 notification). Such notifications reset the timer for the next 508 notification, even though they do not need to abide by it. 510 When a local policy dictates a maximum rate for notifications, a 511 notifier will not generate notifications more frequently than the 512 local policy maximum rate, even if the subscriber is not asking for 513 maximum rate control. The notifier MAY inform the subscriber about 514 such local policy maximum rate using the "min-interval" Subscription- 515 State header field parameter included in the subsequent NOTIFY 516 requests. 518 Retransmissions of NOTIFY requests are not affected by the maximum 519 rate mechanism, i.e., the maximum rate mechanism only applies to the 520 generation of new transactions. In other words, the maximum rate 521 mechanism does not in any way break or modify the normal 522 retransmission mechanism. 524 4.3. Selecting the maximum rate 526 Special care needs to be taken when selecting the "min-interval" 527 value. Using the "min-interval" syntax it is possible to insist both 528 very short and very long intervals between notifications. 530 For example, the maximum rate could potentially set a minimum time 531 value between notifications that exceeds the subscription expiration 532 value. Such a configuration would effectively quench the notifier, 533 resulting in exactly two notifications to be generated. If the 534 subscriber requests a "min-interval" value greater than the 535 subscription expiration, the notifier MUST lower the "min-interval" 536 value and set it to the expiration time left. According to RFC 3265 537 [RFC3265] the notifier may also shorten the subscription expiry 538 anytime during an active subscription. For such cases, the notifier 539 MUST also lower the "min-interval" value and set it to the reduced 540 expiration time. 542 In some cases it makes sense to pause the notification stream on an 543 existing subscription dialog on a temporary basis without terminating 544 the subscription, e.g. due to inactivity on the application UI. 545 Whenever a subscriber discovers the need to perform the notification 546 pause operation, it SHOULD set the "min-interval" value to the 547 remaining subscription expiration value. This results in receiving 548 no further notifications until the subscription expires, renewed or 549 notifications are resumed by the subscriber. 551 The notifier MAY decide to adjust the proposed maximum rate value 552 based on its local policy or other implementation-determined 553 constraints. The notifier MAY also choose a higher "min-interval" 554 value than the subscriber proposed one, e.g., because of static 555 configuration given by local policy. 557 The notifier MUST include the adjusted "min-interval" value in the 558 Subscription-State header field's "min-interval" parameter in each of 559 the NOTIFY requests. In addition, different event packages MAY 560 define additional constraints to the allowed "min-interval" 561 intervals. Such constraints are out of the scope of this 562 specification. 564 4.4. Buffer Policy Description 566 4.4.1. Partial State Notifications 568 With partial notifications, the notifier will always need to keep 569 both a copy of the current full state of the resource F, as well as 570 the last successfully communicated full state view F' of the resource 571 in a specific subscription. The construction of a partial 572 notification then involves creating a difference of the two states, 573 and generating a notification that contains that difference. 575 When the maximum rate mechanism is applied to the subscription, it is 576 important that F' is replaced with F only when the difference of F 577 and F' was already included in a partial state notification to the 578 subscriber allowed by the maximum rate mechanism. Additionally, the 579 notifier implementation SHOULD check to see that the size of an 580 accumulated partial state notification is smaller than the full 581 state, and if not, the notifier SHOULD send the full state 582 notification instead. 584 4.4.2. Full State Notifications 586 With full state notifications, the notifier only needs to keep the 587 full state of the resource, and when that changes, send the resulting 588 notification over to the subscriber. 590 When the maximum rate mechanism is applied to the subscription, the 591 notifier receives the state changes of the resource, and generates a 592 notification. If there is a pending notification, the notifier 593 simply replaces that notification with the new notification, 594 discarding the older state. 596 4.5. Estimated Bandwidth Savings 598 It is difficult to estimate the total bandwidth savings accrued by 599 using the maximum rate mechanism over a subscription, since such 600 estimates will vary depending on the usage scenarios. However, it is 601 easy to see that given a subscription where several full state 602 notifications would have normally been sent in any given interval set 603 by the "min-interval" parameter, only a single notification is sent 604 during the same interval when using the maximum rate mechanism, 605 yielding bandwidth savings of several times the notification size. 607 With partial-state notifications, drawing estimates is further 608 complicated by the fact that the states of consecutive updates may or 609 may not overlap. However, even in the worst case scenario, where 610 each partial update is to a different part of the full state, a rate 611 controlled notification merging all of these n partial states 612 together should at a maximum be the size of a full-state update. In 613 this case, the bandwidth savings are approximately n times the size 614 of the header fields of the NOTIFY request. 616 It is also true that there are several compression schemes available 617 that have been designed to save bandwidth in SIP, e.g., SigComp 618 [RFC3320] and TLS compression [RFC3943]. However, such compression 619 schemes are complementary rather than competing mechanisms to the 620 maximum rate mechanism. After all, they can both be applied 621 simultaneously, and in such a way that the compound savings are as 622 good as the sum of applying each one alone. 624 5. Operation of the minimum rate mechanism 626 5.1. Subscriber Behavior 628 In general, the way in which a subscriber generates SUBSCRIBE 629 requests and processes NOTIFY requests is according to RFC 3265 630 [RFC3265]. 632 A subscriber that wishes to apply a minimum rate to notifications in 633 a subscription MUST construct a SUBSCRIBE request that includes a 634 maximum time interval between two consecutive notifications included 635 in the "max-interval" Event header field parameter. The value of 636 this parameter is an integral number of seconds in decimal. 638 Subscribers implementing the minimum rate mechanism MUST include an 639 Event header field in any 200-class responses to NOTIFY requests. 641 A subscriber that wishes to update the previously agreed minimum rate 642 of notifications MUST include the updated "max-interval" Event header 643 field parameter in a subsequent SUBSCRIBE request or a 200-class 644 response to the NOTIFY request. 646 A subscriber that wishes to remove the minimum rate control from 647 notifications MUST indicate so by not including a "max-interval" 648 Event header field parameter in a subsequent SUBSCRIBE request or a 649 200-class response to the NOTIFY request. 651 The main consequence for the subscriber when applying the minimum 652 rate mechanism is that it can receive a notification even if nothing 653 has changed in the current state of the notifier. 655 There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a 656 reference in a notification if nothing has changed. 658 5.2. Notifier Behavior 660 In general, the way in which a notifier processes SUBSCRIBE requests 661 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 663 A notifier that supports the minimum rate mechanism MUST extract the 664 value of the "max-interval" Event header parameter from a SUBSCRIBE 665 request or a 200-class response to the NOTIFY request and use it as 666 the suggested maximum time allowed between two notifications. 668 The notifier MAY decide to adjust the proposed minimum rate value 669 based on its local policy or other implementation-determined 670 constraints. A compliant notifier MUST reflect back the possibly 671 adjusted maximum time interval in a "max-interval" Subscription-State 672 header field parameter of the subsequent NOTIFY requests. The 673 indicated "max-interval" value is adopted by the notifier, and the 674 notification rate is adjusted accordingly. 676 A notifier that does not understand this extension, will not reflect 677 the "max-interval" Subscription-State header field parameter in the 678 NOTIFY requests; the absence of this parameter serves as a hint to 679 the subscriber that no rate control is supported by the notifier. 681 A compliant notifier MUST generate notifications whenever the time 682 since the most recent notification exceeds the value in the "max- 683 interval" parameter. Depending on the event package and subscriber 684 preferences indicated in the SUBSCRIBE request, the NOTIFY request 685 MUST contain either the current full state or the partial state 686 showing the difference between the current state and the last 687 successfully communicated state. 689 Retransmissions of NOTIFY requests are not affected by the minimum 690 rate mechanism, i.e., the minimum rate mechanism only applies to the 691 generation of new transactions. In other words, the minimum rate 692 mechanism does not in any way break or modify the normal 693 retransmission mechanism. 695 6. Operation of the average rate mechanism 697 6.1. Subscriber Behavior 699 In general, the way in which a subscriber generates SUBSCRIBE 700 requests and processes NOTIFY requests is according to RFC 3265 701 [RFC3265]. 703 A subscriber that wishes to apply an average rate to notifications in 704 a subscription MUST construct a SUBSCRIBE request that includes a 705 proposed average time interval between two consecutive notifications 706 included in a "average-interval" Event header field parameter. The 707 value of this parameter is an integral number of seconds in decimal. 709 Subscribers implementing the minimum rate mechanism MUST include an 710 Event header field in any 200-class responses to NOTIFY requests. 712 A subscriber that wishes to update the previously agreed average rate 713 of notifications MUST include the updated "average-interval" Event 714 header field parameter in a subsequent SUBSCRIBE request or a 200- 715 class response to the NOTIFY request. 717 A subscriber that wishes to remove the average rate control from 718 notifications MUST indicate so by not including a "average-interval" 719 Event header field parameter in a subsequent SUBSCRIBE request or a 720 200-class response to the NOTIFY request. 722 The main consequence for the subscriber when applying the average 723 rate mechanism is that it can receive a notification even if nothing 724 has changed in the current state of the notifier. 726 There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a 727 reference in a notification if nothing has changed. 729 6.2. Notifier Behavior 731 In general, the way in which a notifier processes SUBSCRIBE requests 732 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 734 A notifier that supports the average rate mechanism MUST extract the 735 value of the "average-interval" Event header parameter from a 736 SUBSCRIBE request or a 200-class response to the NOTIFY request and 737 use it to calculate the maximum time allowed between two transactions 738 as defined in Section 6.3. 740 The notifier MAY decide to adjust the proposed average time interval 741 based on its local policy or other implementation-determined 742 constraints. A compliant notifier MUST reflect back the possibly 743 adjusted average time interval in an "average-interval" Subscription- 744 State header field parameter of the subsequent NOTIFY requests. The 745 indicated "average-interval" value is adopted by the notifier, and 746 the notification rate is adjusted accordingly. 748 A notifier that does not understand this extension will not reflect 749 the "average-interval" Subscription-State header parameter in the 750 NOTIFY requests; the absence of this parameter serves as a hint to 751 the subscriber that no rate control is supported by the notifier. 753 A compliant notifier MUST generate notifications whenever the time 754 since the most recent notification exceeds the value calculated using 755 the formula defined in Section 6.3. 757 The average rate mechanism is implemented as follows: 759 1) When a subscription is first created, the notifier creates a 760 record that keeps track of the number of notifications that have 761 been sent in the "period". This record is initialized to contain 762 a history of having sent one message every "average-interval" 763 seconds for the "period". 765 2) The "timeout" value is calculated according to the equation given 766 in Section 6.3. 768 3) If the timeout period passes without a NOTIFY request being sent 769 in the subscription, then the current resource state is sent 770 (subject to any filtering associated with the subscription). 772 4) Whenever a NOTIFY request is sent (regardless of whether due to a 773 timeout or a state change), the notifier updates the notification 774 history record, recalculates the value of "timeout," and returns 775 to step 3. 777 Retransmissions of NOTIFY requests are not affected by the timeout, 778 i.e., the timeout only applies to the generation of new transactions. 779 In other words, the timeout does not in any way break or modify the 780 normal retransmission mechanism. 782 6.3. Calculating the timeout 784 The formula used to vary the absolute pacing in a way that will meet 785 the average rate requested over the period is given in equation (1): 787 timeout = (average-interval ^ 2) * count / period (1) 789 The output of the formula, "timeout", is the time to the next 790 notification, expressed in seconds. The formula has three inputs: 792 average-interval: The value of the "average-interval" parameter 793 conveyed in the Event header field, in seconds. 795 period: The rolling average period, in seconds. A suggested 796 reasonable period is 60 seconds. 798 [OPEN ISSUE] Is the period value something we should be able to 799 tune, or we can simply specify a reasonable period? 801 count: The number of notifications that have been sent during the 802 last "period" of seconds. 804 In case both the maximum rate and the average rate mechanisms are 805 used in the same subscription the formula used to dynamically 806 calculate the timeout is given in equation (2): 808 timeout = MAX[min-interval, (average-interval ^ 2) * count / period] (2) 810 min-interval: The value of the "min-interval" parameter conveyed in 811 the Event header field, in seconds. 813 The formula in (2) makes sure that for all the possible values of the 814 "min-interval" and "average-interval" parameters, with "average- 815 interval" > "min-interval", the timeout never results in a lower 816 value than the value of the "min-interval" parameter. 818 7. Usage of "min-interval", "max-interval" and "average-interval" in a 819 combination 821 Applications can subscribe to an event package using all the rate 822 control mechanisms individually, or in combination; in fact there is 823 no technical incompatibility among them. However there are some 824 combinations of the different rate control mechanisms that make 825 little sense to be used together. This section lists all the 826 combinations that are possible to insert in a subscription; the 827 utility to use each combination in a subscription is also analyzed. 829 min-interval and max-interval: this combination allows to reduce the 830 notification frequency rate, but at the same time assures the 831 reception of a notification every time the most recent 832 notification exceeds a specified interval. 834 A subscriber SHOULD choose a "max-interval" value higher than the 835 "min-interval" value, otherwise the notifier MUST adjust the 836 subscriber provided "max-interval" value to a value equivalent or 837 higher than the "min-interval" value. 839 min-interval and average-interval: it works in a similar way as the 840 combination above, but with the difference that the interval at 841 which notifications are assured changes dynamically. 843 A subscriber SHOULD choose a "average-interval" value higher than 844 the "min-interval" value, otherwise the notifier MUST adjust the 845 subscriber provided "average-interval" value to a value equivalent 846 or higher than the "min-interval" value. 848 max-interval and average-interval: as both the parameters are 849 designed as minimum rate mechanisms, this combination makes sense 850 only in some corner cases. 852 A subscriber SHOULD choose a "max-interval" value higher than the 853 "average-interval" value, otherwise the notifier MUST NOT consider 854 the "max-interval" value. 856 min-interval, max-interval and average-interval: this combination 857 makes little sense to be used. 859 8. Syntax 861 This section describes the syntax extensions required for the 862 different rate control mechanisms. 864 8.1. "min-interval", "max-interval" and "average-interval" Header Field 865 Parameters 867 The "min-interval", "max-interval" and "average-interval" parameters 868 are added to the rule definitions of the Event header field and the 869 Subscription-State header field in the SIP Events [RFC3265] grammar. 870 Usage of this parameter is described in Section 4, Section 5 and 871 Section 6. 873 8.2. Augmented BNF Definitions 875 This section describes the Augmented BNF [RFC5234] definitions for 876 the new syntax elements. Note that we derive here from the ruleset 877 present in SIP Events [RFC3265], adding additional alternatives to 878 the alternative sets of "event-param" and "subexp-params" defined 879 therein. 881 event-param =/ min-interval-param 882 subexp-params =/ min-interval-param 883 min-interval-param = "min-interval" EQUAL delta-seconds 885 event-param =/ max-interval-param 886 subexp-params =/ max-interval-param 887 max-interval-param = "max-interval" EQUAL delta-seconds 889 event-param =/ average-interval-param 890 subexp-params =/ average-interval-param 891 average-interval-param = "average-interval" EQUAL delta-seconds 893 8.3. Event header field usage in responses to the NOTIFY request 895 Implementations using the extensions described in this document MUST 896 include an Event header field in any 200-class responses to NOTIFY 897 requests. This table expands the table described in Section 7.2 of 898 SIP Events [RFC3265] allowing the Event header field to appear in a 899 200-class response to a NOTIFY request. 901 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 902 ----------------------------------------------------------------- 903 Event 2xx - - - - - - - - m 905 9. IANA Considerations 907 This specification registers three new SIP header field parameters, 908 defined by the following information which is to be added to the 909 Header Field Parameters and Parameter Values sub-registry under 910 http://www.iana.org/assignments/sip-parameters. 912 Predefined 913 Header Field Parameter Name Values Reference 914 -------------------- --------------- ---------- --------- 915 Event min-interval No [RFCxxxx] 916 Subscription-State min-interval No [RFCxxxx] 917 Event max-interval No [RFCxxxx] 918 Subscription-State max-interval No [RFCxxxx] 919 Event average-interval No [RFCxxxx] 920 Subscription-State average-interval No [RFCxxxx] 922 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 923 this specification, when assigned.) 925 10. Security Considerations 927 Naturally, the security considerations listed in SIP events 928 [RFC3265], which the rate control mechanisms described in this 929 document extends, apply in entirety. In particular, authentication 930 and message integrity SHOULD be applied to subscriptions with this 931 extension. 933 11. Acknowledgments 935 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 936 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 937 Khartabil, Dale Worley, Martin Thomson and Byron Campen for support 938 and/or review of this work. 940 Thanks to Brian Rosen for the idea of the minimum and average rate 941 mechanisms, and Adam Roach for the work on the averaging algorithm 942 and other feedback. 944 12. References 946 12.1. Normative References 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 952 A., Peterson, J., Sparks, R., Handley, M., and E. 953 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 954 June 2002. 956 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 957 Event Notification", RFC 3265, June 2002. 959 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 960 Initiation Protocol (SIP) Event Notification Extension for 961 Resource Lists", RFC 4662, August 2006. 963 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 964 Specifications: ABNF", STD 68, RFC 5234, January 2008. 966 12.2. Informative References 968 [I-D.ietf-geopriv-loc-filters] 969 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 970 Location Notifications in the Session Initiation Protocol 971 (SIP)", draft-ietf-geopriv-loc-filters-07 (work in 972 progress), October 2009. 974 [I-D.ietf-sipcore-subnot-etags] 975 Niemi, A., "An Extension to Session Initiation Protocol 976 (SIP) Events for Conditional Event Notification", 977 draft-ietf-sipcore-subnot-etags-02 (work in progress), 978 April 2009. 980 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 981 Liu, Z., and J. Rosenberg, "Signaling Compression 982 (SigComp)", RFC 3320, January 2003. 984 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 985 Package for Registrations", RFC 3680, March 2004. 987 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 988 Indication Event Package for the Session Initiation 989 Protocol (SIP)", RFC 3842, August 2004. 991 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 992 Initiation Protocol (SIP)", RFC 3856, August 2004. 994 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 995 Package for the Session Initiation Protocol (SIP)", 996 RFC 3857, August 2004. 998 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 999 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 1000 November 2004. 1002 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 1003 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 1005 Authors' Addresses 1007 Aki Niemi 1008 Nokia 1009 P.O. Box 407 1010 NOKIA GROUP, FIN 00045 1011 Finland 1013 Phone: +358 50 389 1644 1014 Email: aki.niemi@nokia.com 1015 Krisztian Kiss 1016 Nokia 1017 313 Fairchild Dr 1018 Mountain View, CA 94043 1019 US 1021 Phone: +1 650 391 5969 1022 Email: krisztian.kiss@nokia.com 1024 Salvatore Loreto 1025 Ericsson 1026 Hirsalantie 11 1027 Jorvas 02420 1028 Finland 1030 Email: salvatore.loreto@ericsson.com