slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Event Throttle draft-niemi-sipping-event-throttle-08 PowerPoint Presentation
Download Presentation
Event Throttle draft-niemi-sipping-event-throttle-08

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

1 Views Download Presentation
Download Presentation

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. 74th IETF, San Francisco March 2009 Event Throttledraft-niemi-sipping-event-throttle-08

  2. Version -08 Recap Throttle = minimum notification time period between two notifications Force = maximum notification time period between two notifications Average = adaptive rate control, an average cadence at which notifications are desired Updates in -08 Several clarifications implemented based on first round of reviews of the -07 version (Brian Rosen, Hisham Khartabil, Dale Worley)

  3. Open Issue 1: retransmission of NOTIFY vs. new transaction Generic guideline Throttle/force/average should not interfere with the retransmission mechanism Problem Subscriber thinks the transaction is over and expecting a forced NOTIFY but it won’t receive it if retransmission of previous NOTIFY is still ongoing Possible solution Allow to send out the next NOTIFY while there is still a retransmission of a previous NOTIFY (i.e. allow to start the throttle/force/average timer at the time of sending the NOTIFY) Issues: It may violate a particular package's rules on overlapping NOTIFYs It may break partial notifications It may create package dependent solution Proposal The draft will not specify the exact method for when to start the throttle/force/average timer for the next NOTIFY “Retransmissions of NOTIFY requests are not affected by the throttle/force/average, i.e., the throttle/force/average only applies to the generation of new transactions. In other words, the throttle/force/average does not in any way break or modify the normal retransmission mechanism.”

  4. Open Issue 2: average formula Current formula to calculate timeout for "average“ timeout = (average ^ 2) * count / period period: rolling average period count: number of notifications sent during the last "period“ Brian Rosen suggested using moving average Suggested formula by Dale Worley (exponential-smoothing): timeout = (1 + alpha - beta) * (last timeout value) - alpha * (interval since last notification)+ beta * average alpha and beta are the smoothing parameters What’s the consensus from the WG?

  5. Other comments Are integral seconds sufficient? Tenths of a second, finer grain? Required by location work? "hidden" throttling Notifier can apply throttling without the subscriber requesting it (local policy) Mechanism in this draft can be used to inform the subscriber about the existence of throttling local policy at the notifier Better naming for the parameters throttle → rate-max force → rate-min average → rate-average Cleaner split between normative and non-normative text Section 3 non-normative Section 4 normative

  6. Status Pre-WGLC completed for -08 version Several comments, good feedback received Way forward: Adopt as a WG item? Resolve open issues in next version Start WGLC right after?