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

From: [email-masked]
Date: Thu, 20 Nov 2003 12:30:52 +0200

Hi Henning,

Inline.

 > 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.

I think you just spelled out a key use case for filtering. If I have 500 buddies in my buddy list, plus restricted screen real estate, there might only be room for a simple icon to show per buddy. However, without being able to control the content of notifications, I would still get the full presence of each buddy at all times. 

Throttling would be able to lower the aggregate rate of those 500 subscriptions, but what you really want to do is control the amount of content, focusing on the key things you can show to the user in this buddy list view. The mechanism for that is filtering.

Cheers,
Aki
 
 > Paul Kyzivat wrote:
 > 
 > > 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.
 > >>
 > >> 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.
 > > 
 > > 
 > > 
 > > _______________________________________________
 > > 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
 > 
 > _______________________________________________
 > 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
 > 

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Thu, 20 Nov 2003 09:46:55 -0500

[email-masked] wrote:

>> 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.
> 
> I think you just spelled out a key use case for filtering. If I have
> 500 buddies in my buddy list, plus restricted screen real estate,
> there might only be room for a simple icon to show per buddy.
> However, without being able to control the content of notifications,
> I would still get the full presence of each buddy at all times.

My earlier message goes further than that: in many cases, even filtered 
delivery is too much useless information. Having a quick 
SUBSCRIBE/unsubscribe on demand will work better, with no additional 
filtering effort.

This obviously does not negate the need for filtering.

We do seem to agree that pure blind notification dropping according to 
some arbitrary rate threshold is probably the method least likely to be 
useful in practice, except for the continuous-update cases that I 
mentioned before.

> 
> Throttling would be able to lower the aggregate rate of those 500
> subscriptions, but what you really want to do is control the amount
> of content, focusing on the key things you can show to the user in
> this buddy list view. The mechanism for that is filtering.