Subject: [Simple] Filtering & Throttling paradox

From: <[email-masked]>
Date: Fri, 10 Mar 2006 14:15:26 +0100

Accordingly to draft-niemi-sipping-event-throttle-03, throttling is the
last component that processes the outgoing notifications. Thus, event
notification filtering is executed before throttling. (See also e.g.
OMA-TS-Presence_SIMPLE-V1_0-20051122-C.)

Now consider this situation:

1. The user subscribes to someone's presence document. The subscriber
sends some filter with triggers in the SUBSCRIBE message body. Initial
notification (N1) is sent, as always.

2. The presence document changes, so new notification (N2) is prepared.
Triggers are evaluated against N1 and N2. Suppose the triggers are
passed and N2 has to be sent to the subscriber. However, before the
notification N2 is really sent to the subscriber, it is held for a while
in the throttling component.

3. A new presence document change appears, so next notification (N3) is
prepared. Now suppose that N3 is such notification that causes the
triggers' evaluation:
   - to pass, if evaluating triggers against N2 and N3, and
   - not to pass, if evaluating triggers against N1 and N3.

If we decide N3 to be sent because the triggers' evaluation against N2
and N3 tells us so, N3 arrives to the throttling component and causes N2
to be discarded and not-delivered to the subscriber. Thus, it was wrong
in the triggers' evaluation to compute them against N2 and N3 since N2
was not the really last notification sent to the subscriber. The last
notification sent was obviously N1.

In the other hand, if we decide N3 not to be sent because the triggers'
evaluation against N1 and N3 tells us so, we are wrong too because in
that case N2 is sent after a short time from the throttling component,
thus N1 was not the very last notification sent, as N2 was.

Both cases lead into a contradiction. So, it is impossible to have
working throttling and event notification filtering together in a way as
defined in draft-niemi-sipping-event-throttle-03 and
draft-ietf-simple-filter-format-05.

Concrete example:

1. Alice's presence document: <mood>happy</mood>
2. Bob subscribes with filter containing these triggers (ORed): T1 -
changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry'
3. Alice's presence document changes to: <mood>tired</mood>
4. The notification to Bob has to be sent, however it is caught by the
throttling component.
5. Alice's presence document changes again to: <mood>angry</mood>
6. Do we have to send the notification to Bob?

I think, the answer to the question given in paragraph 6 is 'yes' since
we have to deliver the user the most recent information. However, the
example shows the complexity of the proposed filtering behaviour. It
rises up the question of rationality of such proposal and it increases
the importance of the following questions:

- What are the benefits of such approach, that the triggering is
computed against the "last previously sent notification"? What is the
motivation of such approach?

- Why not to change it to the "last change in presentity's presence
information"? Such modification would solve many many issues - there
will be no need to store any additional information per each
subscription, such paradoxes as discussed above would not appear while
the most usual use-cases would be covered as well...

BR,

Michal Burda

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Sean Leahy" <[email-masked]>
Date: Fri, 10 Mar 2006 14:16:00 +0000

I am not an authority on this but your suggestion "last change in 
presentity's presence information" seems to confuse 'changed from to' with 
'changed to'.

I would suggest that If N2 is discarded and not-delivered, the record 
should show that it was not delivered or (more likely) that the last 
delivered value of the triggered element was as in N1. i.e. the record of 
what was last delivered should be able to take account of all blockages 
including throttling.

The result would be:

1. Alice's presence document: <mood>happy</mood>
2. Bob subscribes with filter containing these triggers: T1 -
changed from 'happy' to 'tired', T2 - changed from 'tired' to 'angry'
3. Alice's presence document changes to: <mood>tired</mood>
4. The notification to Bob has to be sent, however it is caught by the
throttling component.
5. Alice's presence document changes again to: <mood>angry</mood>
6. N3 (angry) is sent to Bob only if N2 (tired) is sent to Bob.
7. If N2 (tired) is not sent, neither (angry nor tired) is sent.

However, If Bob/Bob's client had anticipated this possibility, the filter 
could have been set to : 

T1 - changed from 'happy' to 'tired', T2 - changed from 'tired' to 
'angry', T3 - changed from ''happy' to 'angry' <which is quite possible>

or simply:

 T1 - changed to 'tired', T2 - changed to 'angry'.

As long as the result is predictable from the requirements, there will 
always a responsibility on the client to subscribe appropriately.

Regards,
Sean

<[email-masked]>
10/03/2006 13:15

        To:     <[email-masked]>
        cc: 
        Subject:        [Simple] Filtering & Throttling paradox

Concrete example:

BR,

Michal Burda