1 Notification Rate Control draft-ietf-sipcore-event-rate-control th IETF, Maastricht July 2010

2 Notification Rate Control Maximum Rate of Notifications The subscriber limits the rate of notifications – Notifications cannot be generated more frequent than every “min-interval” seconds Notifications need to be buffered if they are faster than the maximum rate Minimum Rate of Notifications The subscriber forces the notifier to issue notifications at every “max-interval” seconds even if there are no state changes requiring to issue a notification Average Rate of Notifications Adaptive variant of the minimum rate mechanism where the notifier can increase or decrease the notification frequency based on the recent number of notifications sent out in the last “period” of seconds

3 Version -04 Addresses AD review comments from Robert Sparks and comments from Janet P Gunn: Added text that prevents a subscriber from generating Event header fields in 200 OK responses to NOTIFY requests mid- subscription if the new header field parameters were not negotiated in the most recent SUBSCRIBE request Added security considerations on integrity protection for the Event header field included in the 200 OK response to the NOTIFY request Added a reference to the security considerations listed in RFC 5263 (partial notifications) Clarified the relation of “period” and “average-interval” for the average rate mechanism: "period" MUST be greater than "average- interval" Other text clarifications, corrections and editorials

4 Event header field in 200 OK to NOTIFY (1/2) History The draft already specifies new header field parameters for the Event header field Based on GEOPRIV input, a new use case was added to the minimum and average rate mechanisms to allow the subscriber to change the notification rate mid-subscription It was convenient to introduce the Event header field with the new parameters already defined for the SUBSCRIBE request to convey the same information in a 200 OK response to the NOTIFY request

5 Event header field in 200 OK to NOTIFY (2/2) Can we generally take advantage of the Event header field in responses? At least, we need to specify more details about the Event header field in responses – resulting in updating 3265 instead of extending it: Use of the Event header field in responses other than 200 OKs to NOTIFY requests is undefined / not allowed Any of the other parameters currently defined for the Event header field do NOT have a meaning if copied from the NOTIFY request into its 200 OK response Event package can't be changed between the NOTIFY request and its 200 OK response Update needed in the IANA registry for the Event header field definition to reference this document

6 Other open comments Improve the description of the average rate mechanism Align the description of the use case and requirements with the algorithm definition and detailed behavior Change the name to “adaptive minimum rate mechanism” (specify it as the adaptive variant of the minimum rate mechanism) Analogous to the “adaptive minimum rate mechanism”, should we also define an “adaptive maximum rate mechanism”? Algorithm that dynamically calculates the minimum time allowed between two notifications Consistent usage of minimum/maximum/average rate mechanisms in section titles, other nits & corrections