idnits 2.17.1 draft-niemi-sipping-event-throttle-reqs-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2003) is 7600 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) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '2') (Obsoleted by RFC 6665) == Outdated reference: A later version (-04) exists of draft-ietf-sipping-mwi-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Niemi 3 Internet-Draft Nokia 4 Expires: December 29, 2003 June 30, 2003 6 Requirements for Limiting the Rate of Event Notifications 7 draft-niemi-sipping-event-throttle-reqs-02 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on December 29, 2003. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 All event packages are required to specify a maximum rate at which 38 event notifications are generated by a single notifier. Such a limit 39 is provided in order to reduce network congestion. In addition to the 40 fixed limits introduced by specific event packages, further 41 mechanisms for limiting the rate of event notification are also 42 allowed to be defined by event package specifications but none have 43 been specified so far. This memo discusses the requirements for a 44 throttle mechanism that allows a subscriber to further limit the rate 45 of event notification. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Event Throttle Model . . . . . . . . . . . . . . . . . . . . . 3 52 4. Example Use Case . . . . . . . . . . . . . . . . . . . . . . . 4 53 4.1 Pre-conditions . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4.2 Normal Flow . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4.3 Post-conditions . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 8. Changes to "draft-niemi-sipping-event-throttle-reqs-01" . . . 6 60 9. Changes to "draft-niemi-sipping-event-throttle-reqs-00" . . . 7 61 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 62 Normative References . . . . . . . . . . . . . . . . . . . . . 7 63 Informative References . . . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 65 Intellectual Property and Copyright Statements . . . . . . . . 9 67 1. Introduction 69 The SIP events framework described in RFC 3265 [2] mandates that each 70 event package specification defines an absolute maximum on the rate 71 at which notifications are allowed to be generated by a single 72 notifier. Such a limit is provided in order to reduce network 73 congestion. 75 All of the existing event package specifications include a maximum 76 notification rate recommendation, ranging from once in every five 77 seconds [3], [4], [5] to once per second [6]. 79 Per the SIP events framework, each event package specification is 80 also allowed to define additional throttling mechanisms which allow 81 the subscriber to further limit the rate of event notification. So 82 far none of the event package specifications have defined such 83 throttling mechanisms. 85 This memo discusses the requirements for a generic throttling 86 mechanism, which allows the subscriber to limit the rate of event 87 notifications. It is intended that the throttle mechanism is not 88 event package specific, but commonly available to be used with all 89 event subscriptions. 91 2. Conventions 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in BCP 14, RFC 2119 [1], 96 and indicate requirement priorities. 98 3. Event Throttle Model 100 A throttle is defined as a protocol element that establishes a 101 throttling policy at the notifier. This policy simply indicates the 102 minimum time period allowed between two notifications. In practice, 103 this throttling policy only extends the default policy of each event 104 package, making it subscriber-configurable. 106 Using notations from traffic theory, we can model the notifier as a 107 statistical multiplexer with an input rate of Ci (i = 1,...,n), and 108 an output rate of C <= C1 + ... + Cn. Typically, the statistical 109 multiplexer is lossy, with a finite buffer size. The loss probability 110 of the statistical multiplexer can be decreased by enlarging this 111 buffer. Figure 1 illustrates the model. 113 C1 |\ 114 1 ---------| \ 115 ---------| \ C 116 ---------| ||||O---------- 1 117 ---------| / 118 n ---------| / 119 Cn |/ 121 Figure 1: Notifier modeled as a statistical multiplexer 123 In event notification, there is typically only a single input 124 connection, characterized by the event package, and consisting of a 125 stream of event notification packets. Properties of the buffer, such 126 as buffer size, policy (e.g., FIFO, LIFO), and packet treatment in 127 lossy conditions, are all implementation and event package specific. 129 A valid buffer model is a LIFO (Last In First Out) buffer with a 130 size of one notification. Out of all buffered notifications, only 131 the latest one is ever sent to the subscriber. Another equally 132 valid buffer model might be one that has a near infinite buffer 133 size. In that case, it is enough that the output rate C exceeds 134 the aggregate average rate of all the inputs. Under lossy 135 conditions, notifications might be dropped or their state merged, 136 depending on the event package. 138 The main implication of this model for event throttles is that they 139 are lossy. Either some state changes are lost, or some level of 140 accuracy in notifications is lost. The former will affect state 141 changes that occur more frequent than what the throttling policy 142 allows; and the latter will affect notifications of "stateless" 143 nature, e.g., accuracy of buffered location updates decreases. 145 4. Example Use Case 147 There are many applications that potentially would make use of a 148 throttle mechanism. This chapter only illustrates one possible use 149 case, in which a device uses the event throttling mechanism to limit 150 the amount of traffic it may receive. 152 4.1 Pre-conditions 154 A presence application in Lisa's device contains a list of 100 155 presentities. In order to decrease the processing and network load of 156 watching 100 presentities, Lisa's presence application has included 157 an event throttle to each of the subscriptions, to limit the maximum 158 rate at which notifications are to be generated to once per 20 159 seconds. 161 4.2 Normal Flow 163 o Heikki is one of the presentities Lisa is wathcing. Heikki's 164 presence agent conforms to the throttling policy requested by 165 Lisa's presence application. 167 o Heikki changes his location, which results in a presence 168 notification to be sent to Lisa. 170 o Heikki's location changes again, and now very fast. His presence 171 agent receives outgoing presence notification much more frequently 172 than what the throttling policy allows it to generate 173 notifications out to Lisa. The notifications are buffered. 175 o Lisa receives presence updates conforming to the set throttling 176 policy. 178 o Now Heikki's movements stabilize, and his location remains stable. 180 4.3 Post-conditions 182 The throttled subscriptions even out rapid changes in presence 183 status. Lisa still receives all of the buffered presence 184 notifications. Her understanding of Heikki's presence status is 185 temporarily different from Heikki's current real-time status, but as 186 the buffered notifications get exhausted, will eventually converge to 187 the real-time status. 189 5. Requirements 191 REQ1: The subscriber MUST be able to set using a throttle mechanism 192 the minimum time period between two notifications in a specific 193 subscription. 195 REQ2: The subscriber MUST be able to indicate that it requires the 196 notifier to comply with the suggested throttling policy in a 197 specific subscription. 199 REQ3: The notifier MUST be able to indicate that it does not support 200 the use of a throttle mechanism in the subscription. 202 REQ4: It MUST be possible to use the throttle mechanism in 203 subscriptions to all events. 205 REQ5: It MUST be possible to use the throttle mechanism together with 206 any event filtering mechanism. 208 REQ6: The notifier MUST be allowed to use a throttling policy in 209 which the minimum time period between two notifications is 210 longer than the one given by the subscriber. 212 For example, due to congestion reasons, local policy at the 213 notifier could temporarily dictate a throttling policy that 214 in effect increases the subscriber-configured minimum time 215 period between two notifications. 217 REQ7: The throttle mechanism MUST provide a reasonable resolution for 218 setting the minimum period between two notifications. At a 219 minimum, the throttling mechanism MUST include discussion of 220 the situation resulting from a minimum time period which 221 exceeds the subscription duration, and SHOULD provide 222 mechanisms for avoiding this situation. 224 REQ8: A throttle mechanism MUST allow for the application of 225 authentication and integrity protection mechanisms to 226 subscriptions invoking that mechanism. 228 Note that Section 6 contains further discussion on the security 229 implications of the throttle mechanism. 231 6. Security Considerations 233 Naturally all of the security considerations for event subscriptions 234 and notifications also apply to subscriptions and notifications that 235 use the throttle mechanism. In addition, using the event throttle 236 mechanism may introduce some new security issues to consider. 237 However, there are no additional requirements regarding security at 238 this stage. 240 7. Open Issues 242 This chapter lists the main open issues within this document. 244 o Is the model comprehensive? 246 o Is this work mature enough to be handed a WG work item status? 248 8. Changes to "draft-niemi-sipping-event-throttle-reqs-01" 250 Changes from the last version were: 252 o Refined the model based on feedback. 254 o Clarified language and terminology used in the requirements, based 255 on feedback. 257 9. Changes to "draft-niemi-sipping-event-throttle-reqs-00" 259 Changes from the previous version include: 261 o Added the chapter describing the model for event throttles. 263 o Reworded the requirements to reflect the model discussion 265 o Added acknowledgements, changelog, and open issues sections 267 10. Acknowledgements 269 The author would like to thank Tim Moran, Jonathan Rosenberg, Hisham 270 Khartabil, Juha Kalliokulju, Paul Kyzivat, Henning Schulzrinne and 271 Dean Willis for their valuable comments. 273 Normative References 275 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 276 Levels", BCP 14, RFC 2119, March 1997. 278 Informative References 280 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 281 Notification", RFC 3265, June 2002. 283 [3] Rosenberg, J., "A Presence Event Package for the Session 284 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 285 in progress), January 2003. 287 [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 288 Package for Registrations", draft-ietf-sipping-reg-event-00 289 (work in progress), October 2002. 291 [5] Rosenberg, J., "A Watcher Information Event Template-Package for 292 the Session Initiation Protocol (SIP)", 293 draft-ietf-simple-winfo-package-05 (work in progress), January 294 2003. 296 [6] Mahy, R., "A Message Summary and Message Waiting Indication 297 Event Package for the Session Initiation Protocol (SIP)", 298 draft-ietf-sipping-mwi-02 (work in progress), March 2003. 300 Author's Address 302 Aki Niemi 303 Nokia 304 P.O. Box 321 305 NOKIA GROUP, FIN 00045 306 Finland 308 Phone: +358 50 389 1644 309 EMail: aki.niemi@nokia.com 311 Intellectual Property Statement 313 The IETF takes no position regarding the validity or scope of any 314 intellectual property or other rights that might be claimed to 315 pertain to the implementation or use of the technology described in 316 this document or the extent to which any license under such rights 317 might or might not be available; neither does it represent that it 318 has made any effort to identify any such rights. Information on the 319 IETF's procedures with respect to rights in standards-track and 320 standards-related documentation can be found in BCP-11. Copies of 321 claims of rights made available for publication and any assurances of 322 licenses to be made available, or the result of an attempt made to 323 obtain a general license or permission for the use of such 324 proprietary rights by implementors or users of this specification can 325 be obtained from the IETF Secretariat. 327 The IETF invites any interested party to bring to its attention any 328 copyrights, patents or patent applications, or other proprietary 329 rights which may cover technology that may be required to practice 330 this standard. Please address the information to the IETF Executive 331 Director. 333 Full Copyright Statement 335 Copyright (C) The Internet Society (2003). All Rights Reserved. 337 This document and translations of it may be copied and furnished to 338 others, and derivative works that comment on or otherwise explain it 339 or assist in its implementation may be prepared, copied, published 340 and distributed, in whole or in part, without restriction of any 341 kind, provided that the above copyright notice and this paragraph are 342 included on all such copies and derivative works. However, this 343 document itself may not be modified in any way, such as by removing 344 the copyright notice or references to the Internet Society or other 345 Internet organizations, except as needed for the purpose of 346 developing Internet standards in which case the procedures for 347 copyrights defined in the Internet Standards process must be 348 followed, or as required to translate it into languages other than 349 English. 351 The limited permissions granted above are perpetual and will not be 352 revoked by the Internet Society or its successors or assignees. 354 This document and the information contained herein is provided on an 355 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 356 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 357 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 358 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 359 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 361 Acknowledgement 363 Funding for the RFC Editor function is currently provided by the 364 Internet Society.