1 / 6

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

aki.niemi@nokia.com krisztian.kiss@nokia.com salvatore.loreto@ericsson.com 74th IETF, San Francisco March 2009. Event Throttle draft-niemi-sipping-event-throttle-08. Version -08. Recap Throttle = minimum notification time period between two notifications

madridj
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. aki.niemi@nokia.com krisztian.kiss@nokia.com salvatore.loreto@ericsson.com 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?

More Related