Subject: [Sipping] How to control drop algorithms for throttling

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 13 Nov 2003 18:30:26 -0500

This mail is a followup to some comments I made during sipping today 
on the event throttling work.

Once we add throttling capabilities to the SIP event framework, we end 
up with a lossy system. Some notifications will be dropped, and others 
will be transmitted. The problem is that all notifications are not 
created equally. If the notififer drops notifications at random, will 
the resulting stream of notifications meet the needs of the watcher? 
Can we do better than simply dropping notifications randomly?

Some possible things we might do:

1. instead of dropping notifications, the notifier buffers them. If it 
receives another notification within the next M seconds, it drops the 
older one, and sends the newer one. This would allow you to control 
the rate through delays. I suspect that many applications will have a 
better sense of the utility of the presence data as a function of age. 
Do we want the mechanism to support this?

2. the watcher could provide a filter type of document in the 
subscription. This filter could indicate that certain transitions are 
more important than others. For example, in the case of presence, it 
might say that transitions of the <basic> status are more important 
than transitions of the <placetype> from RPID. The notifier could use 
these to preferentially drop certain notifications over others. Do we 
want the mechanism to support this?

3. If we don't use the concepts of (1) and (2), is there any value in 
applying algorithms like RED to the systems (I dont think so, but its 
worth considering).

4. Do we want to specify that each package should have a 
considerations section about how to use throttling? In particular, 
what will be the typical impact on service for various loss rates? Or, 
  which components of a document should a client ask to have dropped 
(assuming the filtering of (2)).

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 13 Nov 2003 20:13:59 -0500

Jonathan,

I pretty much agree with you - especially on the need for a throttling 
considerations section. Ultimately, I think this means that the notifier 
application must participate in the throttling in order to ensure that 
the right thing is done.

In some cases it might make the most sense to simply terminate the 
subscription rather than provide a deceptive view. (So that when an 
event was discarded, at the next permissible time the server would 
simply send a notification terminating the subscription.)

	Paul

Jonathan Rosenberg wrote:
> This mail is a followup to some comments I made during sipping today on 
> the event throttling work.
> 
> the resulting stream of notifications meet the needs of the watcher? Can 
> we do better than simply dropping notifications randomly?
> 
> older one, and sends the newer one. This would allow you to control the 
> rate through delays. I suspect that many applications will have a better 
> sense of the utility of the presence data as a function of age. Do we 
> might say that transitions of the <basic> status are more important than 
> transitions of the <placetype> from RPID. The notifier could use these 
> to preferentially drop certain notifications over others. Do we want the 
> mechanism to support this?
> 
> 4. Do we want to specify that each package should have a considerations 
> section about how to use throttling? In particular, what will be the 
> typical impact on service for various loss rates? Or,  which components 
> of a document should a client ask to have dropped (assuming the 
> filtering of (2)).
> 
> 
> Thanks,
> Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 13 Nov 2003 22:49:44 -0500

There are different types of notifications, at least two:

(C) systems where changes are naturally bounded (continuous)

(D) changes where they are not (discrete)

Geo information is an example of the first one. In that case, it makes 
sense to simply restrict updates to some time period or some significant 
change. After all, I can be pretty sure that the offset from the last 
update is less than the speed of sound times the distance, now that the 
Concorde is no longer in service. (Use on Startrek may differ.)

In some cases, I suspect that people will have low-frequency background 
status updates and not care about brief 'transients' (leave office to 
visit cafeteria for coffee), but rather ask for an explicit status 
update if they want to ask somebody something, for example. After all, 
unless the watcher is a busybody with nothing else to do, he won't watch 
every move of every presentity in detail.

Indeed, I wonder if users will really want to get continuous updates on 
their buddy list members. I may want some general sense of how many of 
my colleagues are around and I may want to quickly determine whether a 
particular colleague is around right now, but clicking on the name seems 
perfectly fine for that, without getting the detailed updates on the 
person's cell phone idle time every five minutes.

Paul Kyzivat wrote:

>> what will be the typical impact on service for various loss rates? 
>> Or,  which components of a document should a client ask to have 
>> dropped (assuming the filtering of (2)).
>>
>>
>> Thanks,
>> Jonathan R.
> 
> 
>