Event Throttle Requirements draftniemisippingeventthrottlereqs01 Aki Niemi aki nieminokia
- Slides: 5
Event Throttle Requirements draft-niemi-sipping-event-throttle-reqs-01 Aki Niemi aki. niemi@nokia. com
Contents • The model • Requirements • Issues
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
Requirements 1. 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. 2. The subscriber MUST be able to indicate that it requires the use of a throttle mechanism in the subscription. 3. The notifier MUST be able to indicate that it does not support the use of a throttle mechanism in the subscription. 4. It MUST be possible to use throttle mechanism in subscriptions to all events. 5. It MUST be possible to use throttle mechanism together with any event filtering mechanism. 6. 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. 7. Authentication and integrity protection SHOULD be applied to subscriptions that apply the throttle mechanism.
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?
