idnits 2.17.1 draft-niemi-sipping-event-throttle-reqs-01.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 (February 27, 2003) is 7728 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-01 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: August 28, 2003 February 27, 2003 6 Requirements for Limiting the Rate of Event Notifications 7 draft-niemi-sipping-event-throttle-reqs-01 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 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 28, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 All event packages are required to specify a maximum rate at which 39 event notifications are generated by a single notifier. Such a limit 40 is provided in order to reduce network congestion. In addition to 41 the fixed limits introduced by specific event packages, further 42 mechanisms for limiting the rate of event notification are also 43 allowed to be defined by event package specifications but none have 44 been specified so far. This memo discusses the requirements for a 45 throttle mechanism that allows a subscriber to further limit the rate 46 of event notification. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Event Throttle Model . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Example Use Case . . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 Normative References . . . . . . . . . . . . . . . . . . . . . . 6 58 Informative References . . . . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 60 A. Changes to draft-niemi-sipping-event-throttle-reqs-00 . . . . . 7 61 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 62 Intellectual Property and Copyright Statements . . . . . . . . . 8 64 1. Introduction 66 The SIP events framework described in RFC 3265 [2] mandates that each 67 event package specification defines an absolute maximum on the rate 68 at which notifications are allowed to be generated by a single 69 notifier. Such a limit is provided in order to reduce network 70 congestion. 72 All of the existing event package specifications include a maximum 73 notification rate recommendation, ranging from once in every five 74 seconds [3], [4], [5] to once per second [6]. 76 Per the SIP events framework, each event package specification is 77 also allowed to define additional throttling mechanisms which allow 78 the subscriber to further limit the rate of event notification. So 79 far none of the event package specifications have defined such 80 throttling mechanisms. 82 This memo discusses the requirements for a generic throttling 83 mechanism, which allows the subscriber to limit the rate of event 84 notifications. It is intended that the throttle mechanism is not 85 event package specific, but commonly available to be used with all 86 event subscriptions. 88 2. Conventions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in BCP 14, RFC 2119 [1]. 94 3. Event Throttle Model 96 The model assumed for the event throttle mechanism is similar to the 97 one described in [6]. In it, the notifier employs a quarantine for 98 outgoing notifications, in which outgoing notifications are kept for 99 a certain amount of time before they are actually sent out to the 100 subscriber. In general, the policy by which queueing notifications 101 inside the quarantine are treated is not specified. For example, an 102 incoming notification might simply replace an existing notification 103 [6], or the quarantine could merge the states of all of the 104 quarantined notifications. 106 The throttle mechanism is intended to enable the quarantine period to 107 be configured by the subscriber. Further, the quarantine can be 108 strict, or can also employ a leaky-bucket style algorithm, in which 109 on average the quarantine period might hold, but occasional bursts 110 might also be allowed. 112 OPEN ISSUE: Do we want to consider both models for event 113 throttles, or is only the strict limit really usable? 115 The main implication of this model for event throttles is that they 116 are lossy. Either some state changes are lost, or some level of 117 accuracy in notifications is lost. The former will affect state 118 changes that occur more frequent than what the throttled rate 119 defines; and the latter will affect notifications of "stateless" 120 nature, e.g., location updates within a quarantine period will be 121 lost. 123 4. Example Use Case 125 There are many applications that potentially would make use of a 126 throttle mechanism. This chapter only illustrates one possible use 127 case, in which a mobile device uses the event throttling mechanism to 128 limit the amount of traffic it may receive. 130 A mobile application is watching the state of 100 presentities each 131 generating notifications at a maximum rate of once per five seconds. 132 Assuming that the arrival times of notifications are evenly 133 distributed, this will result in a maximum notification frequency of: 135 f = 100 * (1 / 5s) = 100 / 5 Hz = 20 Hz 137 experienced by the mobile. The same watcher subscribing using a 138 throttle mechanism to limit the maximum rate at which notifications 139 are to be generated to once per 20 seconds can expect a maximum 140 notification frequency of: 142 f = 100 * (1 / 20s) = 100 / 20 Hz = 5 Hz 144 thus resulting in 75% reduction in the maximum rate of incoming 145 presence notifications. 147 Note that the actual rate of notification is the sum of many 148 factors, and this example only makes a very broad assumption on 149 the absolute maximum rate at which the notifications might be 150 generated. 152 5. Requirements 154 REQ1: The subscriber MUST be able to limit using a throttle mechanism 155 the maximum rate at which the notifier is allowed to generate 156 notifications in a subscription. 158 REQ2: The subscriber MUST be able to indicate that it requires the 159 use of a throttle mechanism in the subscription. 161 REQ3: The notifier MUST be able to indicate that it does not support 162 the use of a throttle mechanism in the subscription. 164 REQ4: It MUST be possible to use the throttle mechanism in 165 subscriptions to all events. 167 REQ5: It MUST be possible to use the throttle mechanism together with 168 any event filtering mechanism. 170 REQ6: The notifier MUST be allowed to use a maximum rate lower than 171 the one given by the subscriber. For example, local policy 172 could dictate an even lower rate of notification than what the 173 subscriber requires. 175 REQ7: Authentication and integrity protection SHOULD be applied to 176 subscriptions that apply the throttle mechanism. 178 Note that Section 6 contains further discussion on the security 179 implications of the throttle mechanism. 181 6. Security Considerations 183 Naturally all of the security considerations for event subscriptions 184 and notifications also apply to subscriptions and notifications that 185 use the throttle mechanism. In addition, using the event throttle 186 mechanism introduces some new security issues to consider: 188 The throttle mechanism might allow a subscriber to set a very low 189 maximum notification rate - one that possibly exceeds the 190 subscription expiration. Such a limit inserted by a malicious 191 third party would result in very few if any notifications to be 192 generated, which could be perceived as theft of service to the 193 subscriber. 195 Similarly, the throttle mechanism might allow the subscriber to 196 set a very high maximum rate of notification that possibly is 197 higher than the default recommended rate of notification. Such a 198 high rate inserted by a malicious third party could result in 199 denial of service of the notifier due to performance issues. 201 Using the throttle mechanism potentially allows a subscriber to 202 increase the number of active subscriptions due to the decrease in 203 the maximum rate of notifications generated by a single notifier. 204 If a malicious third party is able to remove the throttle from the 205 subscriptions, the subscriber might be flooded with notifications. 207 All of the above problems can be avoided by ensuring that the 208 integrity and authenticity of subscriptions is protected by applying 209 relevant security measures. 211 7. Open Issues 213 This chapter lists the main open issues within this document. 215 ISSUE1: Is the offered model accurate and appropriate? 217 ISSUE2: Within the model, do we have a need to enable both the 218 leaky-bucket and the strict rate limiting models at the same 219 time, or is only one of them enough? 221 ISSUE3: Is it enough to leave the handling of notifications in the 222 qarantine out-of-scope, or are there requirements for that 223 as well that should be captured by this document 225 ISSUE4: Are the threats listed in the security section really valid 227 ISSUE5: Is the added value of event throttles enough to merit their 228 standardization? 230 Normative References 232 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 233 Levels", BCP 14, RFC 2119, March 1997. 235 Informative References 237 [2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 238 Notification", RFC 3265, June 2002. 240 [3] Rosenberg, J., "A Presence Event Package for the Session 241 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 242 in progress), January 2003. 244 [4] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 245 Package for Registrations", draft-ietf-sipping-reg-event-00 246 (work in progress), October 2002. 248 [5] Rosenberg, J., "A Watcher Information Event Template-Package for 249 the Session Initiation Protocol (SIP)", 250 draft-ietf-simple-winfo-package-05 (work in progress), January 251 2003. 253 [6] Mahy, R., "A Message Summary and Message Waiting Indication 254 Event Package for the Session Initiation Protocol (SIP)", 255 draft-ietf-sipping-mwi-01 (work in progress), November 2002. 257 Author's Address 259 Aki Niemi 260 Nokia 261 P.O. Box 321 262 NOKIA GROUP, FIN 00045 263 Finland 265 Phone: +358 50 389 1644 266 EMail: aki.niemi@nokia.com 268 Appendix A. Changes to draft-niemi-sipping-event-throttle-reqs-00 270 Changes to this version include: 272 o Added the chapter describing the model for event throttles. 274 o Reworded the requirements to reflect the model discussion 276 o Added acknowledgements, changelog, and open issues sections 278 Appendix B. Acknowledgements 280 The author would like to thank Tim Moran, Jonathan Rosenberg, Hisham 281 Khartabil, Juha Kalliokulju, Paul Kyzivat and Henning Schulzrinne for 282 their valuable comments. 284 Intellectual Property Statement 286 The IETF takes no position regarding the validity or scope of any 287 intellectual property or other rights that might be claimed to 288 pertain to the implementation or use of the technology described in 289 this document or the extent to which any license under such rights 290 might or might not be available; neither does it represent that it 291 has made any effort to identify any such rights. Information on the 292 IETF's procedures with respect to rights in standards-track and 293 standards-related documentation can be found in BCP-11. Copies of 294 claims of rights made available for publication and any assurances of 295 licenses to be made available, or the result of an attempt made to 296 obtain a general license or permission for the use of such 297 proprietary rights by implementors or users of this specification can 298 be obtained from the IETF Secretariat. 300 The IETF invites any interested party to bring to its attention any 301 copyrights, patents or patent applications, or other proprietary 302 rights which may cover technology that may be required to practice 303 this standard. Please address the information to the IETF Executive 304 Director. 306 Full Copyright Statement 308 Copyright (C) The Internet Society (2003). All Rights Reserved. 310 This document and translations of it may be copied and furnished to 311 others, and derivative works that comment on or otherwise explain it 312 or assist in its implementation may be prepared, copied, published 313 and distributed, in whole or in part, without restriction of any 314 kind, provided that the above copyright notice and this paragraph are 315 included on all such copies and derivative works. However, this 316 document itself may not be modified in any way, such as by removing 317 the copyright notice or references to the Internet Society or other 318 Internet organizations, except as needed for the purpose of 319 developing Internet standards in which case the procedures for 320 copyrights defined in the Internet Standards process must be 321 followed, or as required to translate it into languages other than 322 English. 324 The limited permissions granted above are perpetual and will not be 325 revoked by the Internet Society or its successors or assignees. 327 This document and the information contained herein is provided on an 328 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 329 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 330 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 331 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 332 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 334 Acknowledgement 336 Funding for the RFC Editor function is currently provided by the 337 Internet Society.