Subject: [Sipping] Comment on I-D ACTION:draft-niemi-sipping-event-throttle-reqs-02.tx

From: [email-masked]
Date: Fri, 4 Jul 2003 14:13:01 +0300

Hi,

I have a comment on the model section rather than the requirements :)

I was ok with the model until I looked at the example. I don't like the idea of delayed notification, especially in the case of presence. I much prefer to receive up to date limited info (lossy model) rather than stale info. I.e. buffer size of 1.

Others might have a different preference depending on the type of event. Example is geoloc; I might want to see the towns/cities you are driving through while crossing Europe by car. Delayed notifications in this case are ok.

Example where the lossy model is favourable is message waiting indication where I don't want to receive notification every time I have a new message in my inbox, but I want to receive notifications on hourly basis telling me how many messaging I now have waiting. 

Perhaps this is a subscriber option and a requirement is needed to address it: A subscribe SHOULD? be able to choose the model associated with the subscription.

Unrelated:

Have you considered a model where the trigger is just the timer and not timer + whatever is in the buffer. Continuing your trip through Europe: I want to receive notifications of your geoloc every hour regardless of your position (if it has changed or not). So I set the throttle to one hour and notifications are sent every hour, even if the buffer is empty.

Regards,
Hisham

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: [email-masked]
Date: Tue, 8 Jul 2003 16:03:38 +0300

Hi Hisham,

Inline.

 > -----Original Message-----
 > From: ext [email-masked] 
 > [mailto:[email-masked]]
 > Sent: 04 July, 2003 14:13
 > To: [email-masked]
 > Cc: Niemi Aki (NMP/Helsinki)
 > Subject: [Sipping] Comment on I-D
 > ACTION:draft-niemi-sipping-event-throttle-reqs-02.tx
 > 
 > 
 > Hi,
 > 
 > I was ok with the model until I looked at the example. I 
 > don't like the idea of delayed notification, especially in 
 > the case of presence. I much prefer to receive up to date 
 > limited info (lossy model) rather than stale info. I.e. 
 > buffer size of 1.

I agree both are equally good use cases, and I suspect there are several more. I chose the other one because it seemed easier to construct in a use-case format. Of course we could add a use case or two, but I doubt that would shed any more light to the requirements we already have.

Is this needed? If people feel strongly about including a stronger set of use-cases, I certainly can add another one.
 
 > Others might have a different preference depending on the 
 > type of event. Example is geoloc; I might want to see the 
 > towns/cities you are driving through while crossing Europe 
 > by car. Delayed notifications in this case are ok.

Right.
 
 > Example where the lossy model is favourable is message 
 > waiting indication where I don't want to receive 
 > notification every time I have a new message in my inbox, 
 > but I want to receive notifications on hourly basis telling 
 > me how many messaging I now have waiting. 

This is also true. Although I would still call both models lossy, since in the former one you lose accuracy in the form of delayed notifications; in the latter there is actual loss of information.

 > Perhaps this is a subscriber option and a requirement is 
 > needed to address it: A subscribe SHOULD? be able to choose 
 > the model associated with the subscription.

This is something that also came up in Dean's comments earlier. The problem I have with this is the potential complexity involved in such a requirement. There are at least the "delay" model and the "drop" model, but also any combination of them, also depending on what the notifier local policy dictates. 

For example, in a scenario where the notifier buffer is large (but finite), it can run the delay model only up until the buffer actually runs out, at which point the policy would actually be forced from delaying notifications to dropping them.

So I would say no. The model by which the notifier treats notifications in its buffer, and the properties of the buffer are implementation and package specific.

 > Unrelated:
 > 
 > Have you considered a model where the trigger is just the 
 > timer and not timer + whatever is in the buffer. Continuing 
 > your trip through Europe: I want to receive notifications of 
 > your geoloc every hour regardless of your position (if it 
 > has changed or not). So I set the throttle to one hour and 
 > notifications are sent every hour, even if the buffer is empty.

Yes, and I'm not sure it falls into throttling's territory. The throttling policy sets a minimum time period between two notifications, and this would be setting the *maximum time* between two notifications.

Also, I think there are other, potentially simpler ways to accomplish this - either by setting the subscription refresh rate at one hour, or by polling once an hour. 

Cheers,
Aki