idnits 2.17.1 draft-ietf-sipcore-event-rate-control-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 906 has weird spacing: '...n-State min-...' == Line 908 has weird spacing: '...n-State max-...' == Line 910 has weird spacing: '...n-State aver...' -- The document date (January 08, 2010) is 5184 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 787, but not defined == Missing Reference: 'RFCxxxx' is mentioned on line 910, but not defined == Unused Reference: 'RFC3261' is defined on line 941, 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-09 == Outdated reference: A later version (-04) exists of draft-ietf-sipcore-subnot-etags-03 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: July 12, 2010 S. Loreto 6 Ericsson 7 January 08, 2010 9 Session Initiation Protocol (SIP) Event Notification Extension for 10 Notification Rate Control 11 draft-ietf-sipcore-event-rate-control-02 13 Abstract 15 This document specifies mechanisms for adjusting the rate of Session 16 Initiation Protocol (SIP) event notifications. These mechanisms can 17 be applied in subscriptions to all SIP event packages. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on July 12, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definitions and Document Conventions . . . . . . . . . . . . . 4 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Use Case for limiting the maximum rate of notifications . 4 63 3.2. Use Case for setting a minimum rate for notifications . . 5 64 3.3. Use Case for specifying the average rate of 65 notifications . . . . . . . . . . . . . . . . . . . . . . 6 66 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.5. The maximum rate mechanism for Resource List Server . . . 7 68 3.6. Basic Operation . . . . . . . . . . . . . . . . . . . . . 9 69 4. Operation of the maximum rate mechanism . . . . . . . . . . . 10 70 4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 10 71 4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 11 72 4.3. Selecting the maximum rate . . . . . . . . . . . . . . . . 11 73 4.4. Buffer Policy Description . . . . . . . . . . . . . . . . 12 74 4.4.1. Partial State Notifications . . . . . . . . . . . . . 12 75 4.4.2. Full State Notifications . . . . . . . . . . . . . . . 13 76 4.5. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 13 77 5. Operation of the minimum rate mechanism . . . . . . . . . . . 14 78 5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 14 79 5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 14 80 6. Operation of the average rate mechanism . . . . . . . . . . . 15 81 6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 15 82 6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 16 83 6.3. Calculating the timeout . . . . . . . . . . . . . . . . . 17 84 7. Usage of "min-interval", "max-interval" and 85 "average-interval" in a combination . . . . . . . . . . . . . 18 86 8. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 8.1. "min-interval", "max-interval" and "average-interval" 88 Header Field Parameters . . . . . . . . . . . . . . . . . 19 89 8.2. Augmented BNF Definitions . . . . . . . . . . . . . . . . 19 90 8.3. Event header field usage in responses to the NOTIFY 91 request . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 93 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 95 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 96 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 97 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 100 1. Introduction 102 The SIP events framework [RFC3265] defines a generic framework for 103 subscriptions to and notifications of events related to SIP systems. 104 This framework defines the methods SUBSCRIBE and NOTIFY, and 105 introduces the concept of an event package, which is a concrete 106 application of the SIP events framework to a particular class of 107 events. 109 One of the things the SIP events framework mandates is that each 110 event package specification defines an absolute maximum on the rate 111 at which notifications are allowed to be generated by a single 112 notifier. Such a limit is provided in order to reduce network 113 congestion. 115 All of the existing event package specifications include a maximum 116 notification rate recommendation, ranging from once in every five 117 seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842]. 119 Per the SIP events framework, each event package specification is 120 also allowed to define additional throttle mechanisms which allow the 121 subscriber to further limit the rate of event notification. So far 122 none of the event package specifications have defined such a 123 mechanism. 125 The resource list extension [RFC4662] to the SIP events framework 126 also deals with rate limiting of event notifications. The extension 127 allows a subscriber to subscribe to a heterogeneous list of resources 128 with a single SUBSCRIBE request, rather than having to install a 129 subscription for each resource separately. The event list 130 subscription also allows rate limiting, or throttling of 131 notifications, by means of the Resource List Server (RLS) buffering 132 notifications of resource state changes, and sending them in batches. 133 However, the event list mechanism provides no means for the 134 subscriber to set the interval for the throttling; it is strictly an 135 implementation decision whether batching of notifications is 136 supported, and by what means. 138 This document defines an extension to the SIP events framework 139 defining the following three "Event" header field parameters that 140 allow a subscriber to set a Minimum, a Maximum and an Average rate of 141 event notifications generated by the notifier: 143 min-interval: specifies a minimum notification time period between 144 two notifications, in seconds. 146 max-interval: specifies a maximum notification time period between 147 two notifications, in seconds. 149 average-interval: specifies an average cadence at which 150 notifications are desired, in seconds. 152 The requirements and model are further discussed in Section 3. All 153 those mechanisms are simply timer values that indicates the minimum, 154 maximum and average time period allowed between two notifications. 155 As a result of those mechanism, a compliant notifier will adjust the 156 rate at which it generates notifications. 158 These mechanisms are applicable to any event subscription, both 159 single event subscription and event list subscription. 161 2. Definitions and Document Conventions 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119] and 166 indicate requirement levels for compliant implementations. 168 Indented passages such as this one are used in this document to 169 provide additional information and clarifying text. They do not 170 contain normative protocol behavior. 172 3. Overview 174 3.1. Use Case for limiting the maximum rate of notifications 176 A presence client in a mobile device contains a list of 100 buddies 177 or presentities. In order to decrease the processing and network 178 load of watching 100 presentities, the presence client has employed a 179 Resource List Server (RLS) with the list of buddies, and therefore 180 only needs a single subscription to the RLS in order to receive 181 notification of the presence state of the resource list. 183 In order to control the buffer policy of the RLS, the presence client 184 sets a maximum rate ("min-interval" parameter), i.e. a minimum time 185 interval between two notifications. Alternatively, the presence 186 client could set the maximum rate for the resource list via a list 187 manipulation interface, e.g., using the XML Configuration Access 188 Protocol (XCAP) [RFC4825]. 190 The RLS will buffer notifications that do not comply with the maximum 191 rate and batch all of the buffered state changes together in a single 192 notification only when allowed by the maximum rate. The maximum rate 193 applies to the overall resource list, which means that there is a 194 hard cap imposed by the maximum rate to the amount of traffic the 195 presence client can expect to receive. 197 For example, with a "min-interval" of 20 seconds, the presence 198 application can expect to receive a notification at a minimum of 199 every 20 seconds. 201 The presence client can also modify the "min-interval" parameter 202 during the lifetime of the subscription. For example, if the User 203 Interface (UI) of the application shows inactivity for a period of 204 time, it can simply pause the notifications by setting the "min- 205 interval" parameter to the subscription expiration time, while still 206 keeping the subscription alive. When the user becomes active again, 207 the presence client can resume the stream of notifications by re- 208 setting the "min-interval" parameter to the earlier used value. 210 Currently, a subscription refresh is needed in order to update the 211 maximum rate. However, this is highly inefficient, since each 212 refresh automatically generates a (full-state) notification 213 carrying the latest resource state. There is work 214 [I-D.ietf-sipcore-subnot-etags] ongoing to solve these 215 inefficiencies. 217 3.2. Use Case for setting a minimum rate for notifications 219 A location application is monitoring the movement of a target. 221 In order to decrease the processing and network load, the location 222 application has made a subscription with a set of location filters 223 [I-D.ietf-geopriv-loc-filters] that specify trigger criterias, for 224 example, to send an update only when the target has moved at least n 225 meters. However, the application is also interested in receiving the 226 current state periodically even if the state of the target has not 227 changed enough to satisfy any of the trigger criteria, i.e. has not 228 moved at least n meters within the period. 230 In order to control the actual state, the location application sets a 231 minimum rate ("max-interval" parameter), i.e. a maximum time interval 232 between two notifications. 234 The location application can also modify the "max-interval" parameter 235 during the lifetime of the subscription. When the subscription to 236 the movement of a target is made, the notifier does not typically 237 have the location information available. Thus, the first 238 notification might be empty, or certain values might be absent. An 239 important use case is placing constraints on when complete state 240 should be provided after creating the subscription. The "max- 241 interval" parameter indicates to the notifier the time when to 242 generate a notification containing complete state information. Once 243 state is acquired and the second notification is sent, the subscriber 244 updates or changes the "max-interval" parameter to a more sensible 245 value. This update can be performed in the 200 OK response to the 246 NOTIFY request that contains the complete state information. 248 3.3. Use Case for specifying the average rate of notifications 250 The previous mechanisms introduce a static and instantaneous rate 251 control. However there are some applications that would work better 252 with an adaptive rate control. This section illustrates the tracking 253 scenario. 255 A tracking application is monitoring a target. 257 In order to decrease the processing and network load, the tracking 258 application wants to make a subscription that dynamically increases 259 the interval between notifications if the target has sent out several 260 notifications recently. 262 In order to set an adaptive rate control, the application defines a 263 average cadence ("average-interval" parameter) at which notifications 264 are desired. The "average-interval" parameter value is used by the 265 notifier to dynamically calculate the maximum time allowed between 266 two subscriptions. In order to dynamically calculate the maximum, 267 the Notifier takes into consideration the frequency at which 268 notifications have been sent recently. 270 This type of rate control allows the notifier to dynamically increase 271 or decrease the Notification frequency. 273 The tracking application can also modify the "average-interval" 274 parameter during the lifetime of the subscription. 276 3.4. Requirements 278 REQ1: The subscriber must be able to set the minimum time period 279 ("min-interval" parameter) between two notifications in a 280 specific subscription. 282 REQ2: The subscriber must be able to set the maximum time period 283 ("max-interval" parameter) between two notifications in a 284 specific subscription. 286 REQ3: The subscriber must be able to set an average cadence 287 ("average-interval" parameter) at which notifications are 288 desired in a specific subscription. 290 REQ4: It must be possible to apply all together, or in any 291 combination, the "min-interval", "max-interval" and "average- 292 interval" mechanisms in a specific subscription. 294 REQ5: It must be possible to use of the different rate control 295 mechanisms in subscriptions to any events. 297 REQ6: It must be possible to use the different rate control 298 mechanisms together with any other event filtering 299 mechanisms. 301 REQ7: The notifier must be allowed to use a policy in which the 302 minimum time period between two notifications is adjusted 303 from the value given by the subscriber. 305 For example, due to congestion reasons, local policy at 306 the notifier could temporarily dictate a policy that in 307 effect increases the subscriber-configured minimum time 308 period between two notifications. 310 REQ8: The different rate control mechanisms must discuss corner 311 cases for setting the time periods between two notifications. 312 At a minimum, the mechanisms must include discussion of the 313 situation resulting from a minimum, maximum or average time 314 period which exceeds the subscription duration, and should 315 provide mechanisms for avoiding this situation. 317 REQ9: The different rate control mechanisms must be possible to be 318 installed, modified, or removed in the course of an active 319 subscription. 321 REQ10: The different rate control mechanisms must allow for the 322 application of authentication and integrity protection 323 mechanisms to subscriptions invoking that mechanism. 325 Note that Section 10 contains further discussion on the security 326 implications of the different rate control mechanisms. 328 3.5. The maximum rate mechanism for Resource List Server 330 When applied to a list subscription, the maximum rate mechanism has 331 some additional considerations. Specifically, the maximum rate 332 applies to the aggregate notification stream resulting from the list 333 subscription, rather than explicitly controlling the notification of 334 each of the implied constituent events. Moreover, the list event 335 notifier can use the maximum rate mechanism on its own to control the 336 rate of the individual subscriptions to avoid overflowing its buffer. 338 The notifier is responsible for sending out event notifications upon 339 state changes of the subscribed resource. We can model the notifier 340 as consisting of three components: the event state resource(s), the 341 Resource List Server (RLS) (or any other notifier), a notification 342 buffer, and finally the subscriber, or watcher of the event state, as 343 shown in Figure 1. 345 +--------+ 346 | Event | 347 +--------+ |Resource| +--------+ 348 | Event | +--------+ | Event | 349 |Resource| | |Resource| 350 +---.=---+ | +---=----+ 351 `-.. | _.--' 352 ``-._ | _.--' 353 +'--'--'-+ 354 |Resource| 355 | List | 356 | Server | 357 +---.----+ 358 | 359 | 360 )--+---( 361 | | .------------. 362 |Buffer|<======'min-interval| 363 | | `------------' 364 )--.---( 365 | 366 | 367 .---+---. 368 | Event | 369 |Watcher| 370 `-------' 372 Figure 1: Model for the Resource List Server (RLS) Supporting 373 Throttling 375 In short, the RLS reads event state changes from the event state 376 resource, either by creating a back end subscription, or by other 377 means; it packages them into event notifications, and submits them 378 into the output buffer. The rate at which this output buffer drains 379 is controlled by the subscriber via the maximum rate mechanism. When 380 a set of notifications are batched together, the way in which 381 overlapping resource state is handled depends on the type of the 382 resource state: 384 In theory, there are many buffer policies that the notifier could 385 implement. However, we only concentrate on two practical buffer 386 policies in this specification, leaving additional ones for 387 further study and out of the scope of this work. These two buffer 388 policies depend on the mode in which the notifier is operating. 390 Full-state: Last (most recent) full state notification of each 391 resource is sent out, and all others in the buffer are discarded. 392 This policy applies to those event packages that carry full-state 393 notifications. 395 Partial-state: The state deltas of each buffered partial 396 notification per resource are merged, and the resulting 397 notification is sent out. This policy applies to those event 398 packages that carry partial-state notifications. 400 3.6. Basic Operation 402 A subscriber that wants to limit the rate of event notification in a 403 specific event subscription does so by including a "min-interval" 404 Event header parameter as part of the SUBSCRIBE request. The "min- 405 interval" value indicates the minimum time allowed between 406 transmission of two consecutive notifications in a subscription. 408 Note that the witnessed time between two consecutive received 409 notifications may not conform to the "min-interval" value for a 410 number of reasons. For example, network jitter and 411 retransmissions may result in the subscriber receiving the 412 notifications with smaller intervals than the "min-interval" value 413 recommends. 415 A subscriber that wants to have a maximum notification time period in 416 a specific event subscription does so by including a "max-interval" 417 Event header parameter as part of the SUBSCRIBE request. The "max- 418 interval" value indicates the maximum time allowed between 419 transmission of two consecutive notifications in a subscription. 421 A subscriber that wants to have an average cadence for the 422 notifications in a specific event subscription does so by including a 423 "average-interval" Event header parameter as part of the SUBSCRIBE 424 request. 426 A subscriber that wants to update a previously agreed event rate 427 control parameter does so by including the updated "min-interval", 428 "max-interval" or "average-interval" Event header parameter as part 429 of a subsequent SUBSCRIBE request or a 200-class response to the 430 NOTIFY request. 432 A notifier that supports the different rate control mechanisms will 433 comply with the value given in "min-interval", "max-interval" and 434 "average-interval" parameters and adjust its rate of notification 435 accordingly. However, if the notifier needs to lower the 436 subscription expiration value or a local policy or other 437 implementation-determined constraint at the notifier can not satisfy 438 the rate control request, then the notifier can adjust opportunely 439 the subscriber requested rate control. 441 Rate controlled notifications will have exactly the same properties 442 as the ones without rate control, with the exception that they will 443 be generated within the timing constraints requested. 445 4. Operation of the maximum rate mechanism 447 4.1. Subscriber Behavior 449 In general, the way in which a subscriber generates SUBSCRIBE 450 requests and processes NOTIFY requests is according to RFC 3265 451 [RFC3265]. 453 A subscriber that wishes to apply a maximum rate to notifications in 454 a subscription MUST construct a SUBSCRIBE request that includes a 455 minimum time interval between two consecutive notifications included 456 in the "min-interval" Event header field parameter. The value of 457 this parameter is an integral number of seconds in decimal. 459 A subscriber that wishes to update the previously agreed maximum rate 460 of notifications MUST include the updated "min-interval" Event header 461 field parameter in a subsequent SUBSCRIBE request or a 200-class 462 response to the NOTIFY request. 464 A subscriber that wishes to remove the maximum rate control from 465 notifications MUST indicate so by not including a "min-interval" 466 Event header field parameter in a subsequent SUBSCRIBE request or a 467 200-class response to the NOTIFY request. 469 There are two main consequences for the subscriber when applying the 470 maximum rate mechanism: state transitions may be lost, and event 471 notifications may be delayed. If either of these side effects 472 constitute a problem to the application that is to utilize event 473 notifications, developers are instructed not to use the mechanism. 475 4.2. Notifier Behavior 477 In general, the way in which a notifier processes SUBSCRIBE requests 478 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 480 A notifier that supports the maximum rate mechanism MUST extract the 481 value of the "min-interval" Event header parameter from a SUBSCRIBE 482 request or a 200-class response to the NOTIFY request and use it as 483 the suggested time allowed between two notifications. This value can 484 be adjusted by the notifier, as defined in Section 4.3. 486 A compliant notifier MUST reflect back the possibly adjusted minimum 487 time interval in a "min-interval" Subscription-State header field 488 parameter of the subsequent NOTIFY requests. The indicated "min- 489 interval" value is adopted by the notifier, and the notification rate 490 is adjusted accordingly. 492 A notifier that does not understand this extension will not reflect 493 the "min-interval" Subscription-State header field parameter in the 494 NOTIFY requests; the absence of this parameter serves as a hint to 495 the subscriber that no rate control is supported by the notifier. 497 A compliant notifier MUST NOT generate notifications more frequently 498 than the maximum rate allows for, except when generating the 499 notification either upon receipt of a SUBSCRIBE request (the first 500 notification), when the subscription state is changing from "pending" 501 to "active" state or upon termination of the subscription (the last 502 notification). Such notifications reset the timer for the next 503 notification, even though they do not need to abide by it. 505 When a local policy dictates a maximum rate for notifications, a 506 notifier will not generate notifications more frequently than the 507 local policy maximum rate, even if the subscriber is not asking for 508 maximum rate control. The notifier MAY inform the subscriber about 509 such local policy maximum rate using the "min-interval" Subscription- 510 State header field parameter included in the subsequent NOTIFY 511 requests. 513 Retransmissions of NOTIFY requests are not affected by the maximum 514 rate mechanism, i.e., the maximum rate mechanism only applies to the 515 generation of new transactions. In other words, the maximum rate 516 mechanism does not in any way break or modify the normal 517 retransmission mechanism. 519 4.3. Selecting the maximum rate 521 Special care needs to be taken when selecting the "min-interval" 522 value. Using the "min-interval" syntax it is possible to insist both 523 very short and very long intervals between notifications. 525 For example, the maximum rate could potentially set a minimum time 526 value between notifications that exceeds the subscription expiration 527 value. Such a configuration would effectively quench the notifier, 528 resulting in exactly two notifications to be generated. If the 529 subscriber requests a "min-interval" value greater than the 530 subscription expiration, the notifier MUST lower the "min-interval" 531 value and set it to the expiration time left. According to RFC 3265 532 [RFC3265] the notifier may also shorten the subscription expiry 533 anytime during an active subscription. For such cases, the notifier 534 MUST also lower the "min-interval" value and set it to the reduced 535 expiration time. 537 In some cases it makes sense to pause the notification stream on an 538 existing subscription dialog on a temporary basis without terminating 539 the subscription, e.g. due to inactivity on the application UI. 540 Whenever a subscriber discovers the need to perform the notification 541 pause operation, it SHOULD set the "min-interval" value to the 542 remaining subscription expiration value. This results in receiving 543 no further notifications until the subscription expires, renewed or 544 notifications are resumed by the subscriber. 546 The notifier MAY decide to adjust the proposed maximum rate value 547 based on its local policy or other implementation-determined 548 constraints. The notifier MAY also choose a higher "min-interval" 549 value than the subscriber proposed one, e.g., because of static 550 configuration given by local policy. 552 The notifier MUST include the adjusted "min-interval" value in the 553 Subscription-State header field's "min-interval" parameter in each of 554 the NOTIFY requests. In addition, different event packages MAY 555 define additional constraints to the allowed "min-interval" 556 intervals. Such constraints are out of the scope of this 557 specification. 559 4.4. Buffer Policy Description 561 4.4.1. Partial State Notifications 563 With partial notifications, the notifier will always need to keep 564 both a copy of the current full state of the resource F, as well as 565 the last successfully communicated full state view F' of the resource 566 in a specific subscription. The construction of a partial 567 notification then involves creating a difference of the two states, 568 and generating a notification that contains that difference. 570 When the maximum rate mechanism is applied to the subscription, it is 571 important that F' is replaced with F only when the difference of F 572 and F' was already included in a partial state notification to the 573 subscriber allowed by the maximum rate mechanism. Additionally, the 574 notifier implementation SHOULD check to see that the size of an 575 accumulated partial state notification is smaller than the full 576 state, and if not, the notifier SHOULD send the full state 577 notification instead. 579 4.4.2. Full State Notifications 581 With full state notifications, the notifier only needs to keep the 582 full state of the resource, and when that changes, send the resulting 583 notification over to the subscriber. 585 When the maximum rate mechanism is applied to the subscription, the 586 notifier receives the state changes of the resource, and generates a 587 notification. If there is a pending notification, the notifier 588 simply replaces that notification with the new notification, 589 discarding the older state. 591 4.5. Estimated Bandwidth Savings 593 It is difficult to estimate the total bandwidth savings accrued by 594 using the maximum rate mechanism over a subscription, since such 595 estimates will vary depending on the usage scenarios. However, it is 596 easy to see that given a subscription where several full state 597 notifications would have normally been sent in any given interval set 598 by the "min-interval" parameter, only a single notification is sent 599 during the same interval when using the maximum rate mechanism, 600 yielding bandwidth savings of several times the notification size. 602 With partial-state notifications, drawing estimates is further 603 complicated by the fact that the states of consecutive updates may or 604 may not overlap. However, even in the worst case scenario, where 605 each partial update is to a different part of the full state, a rate 606 controlled notification merging all of these n partial states 607 together should at a maximum be the size of a full-state update. In 608 this case, the bandwidth savings are approximately n times the size 609 of the header fields of the NOTIFY request. 611 It is also true that there are several compression schemes available 612 that have been designed to save bandwidth in SIP, e.g., SigComp 613 [RFC3320] and TLS compression [RFC3943]. However, such compression 614 schemes are complementary rather than competing mechanisms to the 615 maximum rate mechanism. After all, they can both be applied 616 simultaneously, and in such a way that the compound savings are as 617 good as the sum of applying each one alone. 619 5. Operation of the minimum rate mechanism 621 5.1. Subscriber Behavior 623 In general, the way in which a subscriber generates SUBSCRIBE 624 requests and processes NOTIFY requests is according to RFC 3265 625 [RFC3265]. 627 A subscriber that wishes to apply a minimum rate to notifications in 628 a subscription MUST construct a SUBSCRIBE request that includes a 629 maximum time interval between two consecutive notifications included 630 in the "max-interval" Event header field parameter. The value of 631 this parameter is an integral number of seconds in decimal. 633 A subscriber that wishes to update the previously agreed minimum rate 634 of notifications MUST include the updated "max-interval" Event header 635 field parameter in a subsequent SUBSCRIBE request or a 200-class 636 response to the NOTIFY request. 638 A subscriber that wishes to remove the minimum rate control from 639 notifications MUST indicate so by not including a "max-interval" 640 Event header field parameter in a subsequent SUBSCRIBE request or a 641 200-class response to the NOTIFY request. 643 The main consequence for the subscriber when applying the minimum 644 rate mechanism is that it can receive a notification even if nothing 645 has changed in the current state of the notifier. 647 There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a 648 reference in a notification if nothing has changed. 650 5.2. Notifier Behavior 652 In general, the way in which a notifier processes SUBSCRIBE requests 653 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 655 A notifier that supports the minimum rate mechanism MUST extract the 656 value of the "max-interval" Event header parameter from a SUBSCRIBE 657 request or a 200-class response to the NOTIFY request and use it as 658 the suggested maximum time allowed between two notifications. 660 The notifier MAY decide to adjust the proposed minimum rate value 661 based on its local policy or other implementation-determined 662 constraints. A compliant notifier MUST reflect back the possibly 663 adjusted maximum time interval in a "max-interval" Subscription-State 664 header field parameter of the subsequent NOTIFY requests. The 665 indicated "max-interval" value is adopted by the notifier, and the 666 notification rate is adjusted accordingly. 668 A notifier that does not understand this extension, will not reflect 669 the "max-interval" Subscription-State header field parameter in the 670 NOTIFY requests; the absence of this parameter serves as a hint to 671 the subscriber that no rate control is supported by the notifier. 673 A compliant notifier MUST generate notifications whenever the time 674 since the most recent notification exceeds the value in the "max- 675 interval" parameter. Depending on the event package and subscriber 676 preferences indicated in the SUBSCRIBE request, the NOTIFY request 677 MUST contain either the current full state or the partial state 678 showing the difference between the current state and the last 679 successfully communicated state. 681 Retransmissions of NOTIFY requests are not affected by the minimum 682 rate mechanism, i.e., the minimum rate mechanism only applies to the 683 generation of new transactions. In other words, the minimum rate 684 mechanism does not in any way break or modify the normal 685 retransmission mechanism. 687 6. Operation of the average rate mechanism 689 6.1. Subscriber Behavior 691 In general, the way in which a subscriber generates SUBSCRIBE 692 requests and processes NOTIFY requests is according to RFC 3265 693 [RFC3265]. 695 A subscriber that wishes to apply an average rate to notifications in 696 a subscription MUST construct a SUBSCRIBE request that includes a 697 proposed average time interval between two consecutive notifications 698 included in a "average-interval" Event header field parameter. The 699 value of this parameter is an integral number of seconds in decimal. 701 A subscriber that wishes to update the previously agreed average rate 702 of notifications MUST include the updated "average-interval" Event 703 header field parameter in a subsequent SUBSCRIBE request or a 200- 704 class response to the NOTIFY request. 706 A subscriber that wishes to remove the average rate control from 707 notifications MUST indicate so by not including a "average-interval" 708 Event header field parameter in a subsequent SUBSCRIBE request or a 709 200-class response to the NOTIFY request. 711 The main consequence for the subscriber when applying the average 712 rate mechanism is that it can receive a notification even if nothing 713 has changed in the current state of the notifier. 715 There is work [I-D.ietf-sipcore-subnot-etags] ongoing to only send a 716 reference in a notification if nothing has changed. 718 6.2. Notifier Behavior 720 In general, the way in which a notifier processes SUBSCRIBE requests 721 and generates NOTIFY requests is according to RFC 3265 [RFC3265]. 723 A notifier that supports the average rate mechanism MUST extract the 724 value of the "average-interval" Event header parameter from a 725 SUBSCRIBE request or a 200-class response to the NOTIFY request and 726 use it to calculate the maximum time allowed between two transactions 727 as defined in Section 6.3. 729 The notifier MAY decide to adjust the proposed average time interval 730 based on its local policy or other implementation-determined 731 constraints. A compliant notifier MUST reflect back the possibly 732 adjusted average time interval in an "average-interval" Subscription- 733 State header field parameter of the subsequent NOTIFY requests. The 734 indicated "average-interval" value is adopted by the notifier, and 735 the notification rate is adjusted accordingly. 737 A notifier that does not understand this extension will not reflect 738 the "average-interval" Subscription-State header parameter in the 739 NOTIFY requests; the absence of this parameter serves as a hint to 740 the subscriber that no rate control is supported by the notifier. 742 A compliant notifier MUST generate notifications whenever the time 743 since the most recent notification exceeds the value calculated using 744 the formula defined in Section 6.3. 746 The average rate mechanism is implemented as follows: 748 1) When a subscription is first created, the notifier creates a 749 record that keeps track of the number of notifications that have 750 been sent in the "period". This record is initialized to contain 751 a history of having sent one message every "average-interval" 752 seconds for the "period". 754 2) The "timeout" value is calculated according to the equation given 755 in Section 6.3. 757 3) If the timeout period passes without a NOTIFY request being sent 758 in the subscription, then the current resource state is sent 759 (subject to any filtering associated with the subscription). 761 4) Whenever a NOTIFY request is sent (regardless of whether due to a 762 timeout or a state change), the notifier updates the notification 763 history record, recalculates the value of "timeout," and returns 764 to step 3. 766 Retransmissions of NOTIFY requests are not affected by the timeout, 767 i.e., the timeout only applies to the generation of new transactions. 768 In other words, the timeout does not in any way break or modify the 769 normal retransmission mechanism. 771 6.3. Calculating the timeout 773 The formula used to vary the absolute pacing in a way that will meet 774 the average rate requested over the period is given in equation (1): 776 timeout = (average-interval ^ 2) * count / period (1) 778 The output of the formula, "timeout", is the time to the next 779 notification, expressed in seconds. The formula has three inputs: 781 average-interval: The value of the "average-interval" parameter 782 conveyed in the Event header field, in seconds. 784 period: The rolling average period, in seconds. A suggested 785 reasonable period is 60 seconds. 787 [OPEN ISSUE] Is the period value something we should be able to 788 tune, or we can simply specify a reasonable period? 790 count: The number of notifications that have been sent during the 791 last "period" of seconds. 793 In case both the maximum rate and the average rate mechanisms are 794 used in the same subscription the formula used to dynamically 795 calculate the timeout is given in equation (2): 797 timeout = MAX[min-interval, (average-interval ^ 2) * count / period] (2) 799 min-interval: The value of the "min-interval" parameter conveyed in 800 the Event header field, in seconds. 802 The formula in (2) makes sure that for all the possible values of the 803 "min-interval" and "average-interval" parameters, with "average- 804 interval" > "min-interval", the timeout never results in a lower 805 value than the value of the "min-interval" parameter. 807 7. Usage of "min-interval", "max-interval" and "average-interval" in a 808 combination 810 Applications can subscribe to an event package using all the rate 811 control mechanisms individually, or in combination; in fact there is 812 no technical incompatibility among them. However there are some 813 combinations of the different rate control mechanisms that make 814 little sense to be used together. This section lists all the 815 combinations that are possible to insert in a subscription; the 816 utility to use each combination in a subscription is also analyzed. 818 min-interval and max-interval: this combination allows to reduce the 819 notification frequency rate, but at the same time assures the 820 reception of a notification every time the most recent 821 notification exceeds a specified interval. 823 A subscriber SHOULD choose a "max-interval" value higher than the 824 "min-interval" value, otherwise the notifier MUST adjust the 825 subscriber provided "max-interval" value to a value equivalent or 826 higher than the "min-interval" value. 828 min-interval and average-interval: it works in a similar way as the 829 combination above, but with the difference that the interval at 830 which notifications are assured changes dynamically. 832 A subscriber SHOULD choose a "average-interval" value higher than 833 the "min-interval" value, otherwise the notifier MUST adjust the 834 subscriber provided "average-interval" value to a value equivalent 835 or higher than the "min-interval" value. 837 max-interval and average-interval: as both the parameters are 838 designed as minimum rate mechanisms, this combination makes sense 839 only in some corner cases. 841 A subscriber SHOULD choose a "max-interval" value higher than the 842 "average-interval" value, otherwise the notifier MUST NOT consider 843 the "max-interval" value. 845 min-interval, max-interval and average-interval: this combination 846 makes little sense to be used. 848 8. Syntax 850 This section describes the syntax extensions required for the 851 different rate control mechanisms. 853 8.1. "min-interval", "max-interval" and "average-interval" Header Field 854 Parameters 856 The "min-interval", "max-interval" and "average-interval" parameters 857 are added to the rule definitions of the Event header field and the 858 Subscription-State header field in the SIP Events [RFC3265] grammar. 859 Usage of this parameter is described in Section 4, Section 5 and 860 Section 6. 862 8.2. Augmented BNF Definitions 864 This section describes the Augmented BNF [RFC5234] definitions for 865 the new syntax elements. Note that we derive here from the ruleset 866 present in SIP Events [RFC3265], adding additional alternatives to 867 the alternative sets of "event-param" and "subexp-params" defined 868 therein. 870 event-param =/ min-interval-param 871 subexp-params =/ min-interval-param 872 min-interval-param = "min-interval" EQUAL delta-seconds 874 event-param =/ max-interval-param 875 subexp-params =/ max-interval-param 876 max-interval-param = "max-interval" EQUAL delta-seconds 878 event-param =/ average-interval-param 879 subexp-params =/ average-interval-param 880 average-interval-param = "average-interval" EQUAL delta-seconds 882 8.3. Event header field usage in responses to the NOTIFY request 884 This table expands the table described in Section 7.2 of SIP Events 885 [RFC3265] allowing the Event header field to appear in a 200-class 886 response to a NOTIFY request. Implementations supporting the 887 functionality to update the previously agreed minimum, maximum or 888 average rate of notifications in a 200-class response to the NOTIFY 889 request MUST support the inclusion of the Event header field. 891 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 892 ----------------------------------------------------------------- 893 Event 2xx - - - - - - - - o 895 9. IANA Considerations 897 This specification registers three new SIP header field parameters, 898 defined by the following information which is to be added to the 899 Header Field Parameters and Parameter Values sub-registry under 900 http://www.iana.org/assignments/sip-parameters. 902 Predefined 903 Header Field Parameter Name Values Reference 904 -------------------- --------------- ---------- --------- 905 Event min-interval No [RFCxxxx] 906 Subscription-State min-interval No [RFCxxxx] 907 Event max-interval No [RFCxxxx] 908 Subscription-State max-interval No [RFCxxxx] 909 Event average-interval No [RFCxxxx] 910 Subscription-State average-interval No [RFCxxxx] 912 (Note to the RFC Editor: please replace "xxxx" with the RFC number of 913 this specification, when assigned.) 915 10. Security Considerations 917 Naturally, the security considerations listed in SIP events 918 [RFC3265], which the rate control mechanisms described in this 919 document extends, apply in entirety. In particular, authentication 920 and message integrity SHOULD be applied to subscriptions with this 921 extension. 923 11. Acknowledgments 925 Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander 926 Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham 927 Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston 928 and Michael Procter for support and/or review of this work. 930 Thanks to Brian Rosen for the idea of the minimum and average rate 931 mechanisms, and Adam Roach for the work on the averaging algorithm 932 and other feedback. 934 12. References 936 12.1. Normative References 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, March 1997. 941 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 942 A., Peterson, J., Sparks, R., Handley, M., and E. 943 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 944 June 2002. 946 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 947 Event Notification", RFC 3265, June 2002. 949 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 950 Initiation Protocol (SIP) Event Notification Extension for 951 Resource Lists", RFC 4662, August 2006. 953 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 954 Specifications: ABNF", STD 68, RFC 5234, January 2008. 956 12.2. Informative References 958 [I-D.ietf-geopriv-loc-filters] 959 Mahy, R., Rosen, B., and H. Tschofenig, "Filtering 960 Location Notifications in the Session Initiation Protocol 961 (SIP)", draft-ietf-geopriv-loc-filters-09 (work in 962 progress), December 2009. 964 [I-D.ietf-sipcore-subnot-etags] 965 Niemi, A. and D. Willis, "An Extension to Session 966 Initiation Protocol (SIP) Events for Conditional Event 967 Notification", draft-ietf-sipcore-subnot-etags-03 (work in 968 progress), November 2009. 970 [RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., 971 Liu, Z., and J. Rosenberg, "Signaling Compression 972 (SigComp)", RFC 3320, January 2003. 974 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 975 Package for Registrations", RFC 3680, March 2004. 977 [RFC3842] Mahy, R., "A Message Summary and Message Waiting 978 Indication Event Package for the Session Initiation 979 Protocol (SIP)", RFC 3842, August 2004. 981 [RFC3856] Rosenberg, J., "A Presence Event Package for the Session 982 Initiation Protocol (SIP)", RFC 3856, August 2004. 984 [RFC3857] Rosenberg, J., "A Watcher Information Event Template- 985 Package for the Session Initiation Protocol (SIP)", 986 RFC 3857, August 2004. 988 [RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol 989 Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, 990 November 2004. 992 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 993 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 995 Authors' Addresses 997 Aki Niemi 998 Nokia 999 P.O. Box 407 1000 NOKIA GROUP, FIN 00045 1001 Finland 1003 Phone: +358 50 389 1644 1004 Email: aki.niemi@nokia.com 1006 Krisztian Kiss 1007 Nokia 1008 313 Fairchild Dr 1009 Mountain View, CA 94043 1010 US 1012 Phone: +1 650 391 5969 1013 Email: krisztian.kiss@nokia.com 1015 Salvatore Loreto 1016 Ericsson 1017 Hirsalantie 11 1018 Jorvas 02420 1019 Finland 1021 Email: salvatore.loreto@ericsson.com