[sr-dev] Throttling NOTIFY requests from presence

[Klaus Darilion]

On 29.03.2012 23:19, Peter Dunkley wrote:
> Hi,
>
> RFC 3856 section 6.10 states: "A PA SHOULD NOT generate notifications for
> a single presentity at a rate of more than once every five seconds."

I wonder if this is useful. E.g. a user tries to call somebody, but the 
target is busy. Thus, the call will last maybe 3 seconds having the 
dialog states: trying, proceeding, early, terminated.

How is it supposed to work? It just sends trying, but no the others? Or 
will they be queued, so only trying, and 5 seconds later, terminated is 
sent?

>
> I would like to add this to the presence module (making the rate
> configurable).
>
> I have an idea as to how I would like to do it:
> - Add a last notified time-stamp field to each presentity
> - Add a updated since last notified flag field to each presentity
> - Add a notify required flag field to each active_watcher
>
> - When a presentity is updated the last notified time-stamp is checked.
> If the time is far enough in the past the notifies are sent and the
> time-stamp is updated.  If enough time has not passed the updated since
> flag is set for the presentity and the notify required flag is set for all
> active_watchers of that presentity.
> - When a presentity is subscribed to (this includes re-subscribes) the
> last notified time-stamp is checked.  If the time is far enough in the
> past the (single) notify is sent and the time-stamp is updated.  If enough
> time has not passed the updated since flag is set for the presentity and
> the notify required flag is set for this active_watcher record.

RFC3265 states that a NOTIFY MUST sent immediately after every SUBSCRIBE.

> - A timer (the minimum time between subscribes - default 5 seconds) is
> run.  On expiry a query is done on the presentity table for presentities
> that have been updated _AND_ the last notified time is more than the
> minimum time ago.  For each of these presentities, a query is done on the
> active_watchers for watchers of that presentity that have the notify
> required flag set.  Notifies containing the presentities are then sent to
> the watchers waiting on them.
>
> This should ensure that no presentity notifies more than it should, while
> ensuring that all changes are (eventually) sent out, and all subscribes
> result in a notify (eventually) being sent.  Eventually being typically
> within 5 seconds and in under 10 seconds in the worst case (assuming the
> default setting of 5 seconds).
>
> Can anyone see any problems with this?

I wonder why you delay NOTIFYs for (re)SUBSCRIBEs? On (re)SUBSCRIBEs 
just NOTIFY with last published state and do not set the "notify 
required" flag. Then it may happen that the minimum NOTIFY interval is 
not maintained the first few seconds after a (re)SUBSCRIBE but IMO this 
is not that bad and enables immediate notification after every 
(re)SUBSCRIBE.

> Are there any objections to me implementing this?

Make it configurable :-) E.g. setting "minimum_notification_delay" to 0 
disables the feature.

It may also increase DB load and cause more race-conditions (to be 
resolved with DB-transactions) due to more DB lookups.

E.g. what if the timer finds a presentity for which NOTIFYs needs to be 
sent and - while iterating over all the presentities - a new PUBLISH is 
received which triggers immediate NOTIFY. It may happen that both 
processes manipulate the active watchers table at the same time (notify 
required flag).

> In theory running a (5 second) timer could make presence "lumpy" in the
> same way RLS is (see my previous email).  However, if this proves to be
> the case I believe the same mechanism I have proposed for RLS can be used
> here.

Why run the timer only every 5 seconds? Run it every second (or 100ms) 
then it should not be lumpy anymore.

regards
Klaus