1 Event Throttle draft-niemi-sipping-event-throttle th IETF, Minneapolis November 2008

2 Motivation RFC3265 requires that: 1.Each event package defines an absolute maximum on the rate at which notifications are allowed to be generated by a single notifier 2.Each package may further define a throttle mechanism which allows subscribers to further limit the rate of notification The original goal of this document has been to solve problem #2 in a generic way -00 version submitted ~5 years ago Long semi-dormant state

3 Recent history Recent discussions around draft-ietf-geopriv-loc-filters Triggered interest in this document Resulted in new requirements: Minimum and Average rate of event notifications -07 version includes mechanisms for Minimum, Maximum and Average rate of event notifications

4 Throttle Maximum rate of event notifications Throttle = minimum notification time period between two notifications, in seconds Use case Decrease application processing and network load

5 Force Minimum rate of event notifications Force = maximum notification time period between two notifications, in seconds Use case Location application is monitoring the movement of a target Location filter requires to send an update only when the target has moved at least "x" meters But, application prefers periodic updates even if the target has not moved more than "x" meters in a second

6 Average Adaptive rate control An average cadence at which notifications are desired, in seconds Use case Same as force But, application prefers to reduce frequency of notifications if several notifications were already sent recently Decreases application processing and network load

7 Negotiation Subscriber suggests throttle/force/average interval in SUBSCRIBE Event header field parameter Notifier will reflect back the possibly adjusted throttle/force/average interval Subscription-State header field parameter The subscriber can dynamically change the throttle/force/average interval during the lifetime of the subscription Depending on user activity and network load

8 Notifier behavior Throttle The notifier does not generate notifications more frequent than the throttle interval In case of partial-state notifications, buffered partial notifications have to be merged Force When the time since the most recent notification exceeds the value of "force", the current state is sent Average The notifier dynamically calculates the maximum time between two notifications based on suggested average interval - simple formula is given

9 Discussion Open issue: formula to calculate timeout for "average" timeout = (average ^ 2) * count / period period: rolling average period count: number of notifications sent during the last "period" Should we able to tune "period"? Questions? Adopt as a WG item? Ready to move it to SIP WG?