Event Throttle Requirements draft-niemi-sipping-event-throttle-reqs-01 Aki Niemi

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 the throttle mechanism in subscriptions to all events. 5.It MUST be possible to use the 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?