Event Throttle draft-niemi-sipping-event-throttle-07

1
Event Throttledraft-niemi-sipping-event-throttle-
07

• aki.niemi_at_nokia.com
• krisztian.kiss_at_nokia.com
• salvatore.loreto_at_ericsson.com
• 73th IETF, Minneapolis
• November 2008

2
Motivation

• RFC3265 requires that
• Each event package defines an absolute maximum on
  the rate at which notifications are allowed to be
  generated by a single notifier
• 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-f
  ilters
• 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?