Event Throttle Requirements

1
Event Throttle Requirements

• draft-niemi-sipping-event-throttle-reqs-01
• Aki Niemi
• aki.niemi_at_nokia.com

2
Contents

• The model
• Requirements
• Issues

3
The Model

• Notifier quarantines outgoing notifications
• Quarantine period is configurable by the
  subscriber
• Local policy still applies
• Notification treatment inside the quarantine is
  not specified
• Package specific e.g., replace, merge,
  aggregate, etc.
• Implies lossy behavior
• Information (transitions, state) is lost
• Strict throttles
• Quarantine is always held
• Leaky-bucket throttles
• Allows for bursts

4
Requirements

• The subscriber MUST be able to limit using a
  throttle mechanism the maximum rate at which the
  notifier is allowed to generate notifications in
  a subscription.
• The subscriber MUST be able to indicate that it
  requires the use of a throttle mechanism in the
  subscription.
• The notifier MUST be able to indicate that it
  does not support the use of a throttle mechanism
  in the subscription.
• It MUST be possible to use the throttle mechanism
  in subscriptions to all events.
• It MUST be possible to use the throttle mechanism
  together with any event filtering mechanism.
• The notifier MUST be allowed to use a maximum
  rate lower than the one given by the subscriber.
  For example, local policy could dictate an even
  lower rate of notification than what the
  subscriber requires.
• Authentication and integrity protection SHOULD be
  applied to subscriptions that apply the throttle
  mechanism.

5
Issues

• Is the model accurate and appropriate?
• Do we need both the leaky-bucket and the strict
  throttle models, or is only one of them enough?
• Is it OK to leave handling of notifications in
  the qarantine out-of-scope?
• Any requirements for the treatment?
• Are throttles important and useful enough to
  continue the work?
• WG item, charter?