List Info

Thread: Filtering & Throttling paradox




Filtering & Throttling paradox
user name
2006-03-10 13:15:26
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
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )