Subject: Re: [Sipping] Update to event throttles

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 Mar 2005 04:38:41 -0500

I'm inclined to say that I don't find this a terribly pressing problem. 
We don't have any real networks for whom subscribers are being 
overwhelmed with notifications, for which this would be the ideal way to 
deal with it (compared to compression or filters, both of which reduce 
the amount of data).

The mechanism seems reasonable as a bare-minimum kind of thing. The big 
issue in my mind remains, which is that you can often do a better job by 
dropping content based on semantic understanding of what it is. Also, 
its not clear that a minimum interval, as opposed to average, is all 
that important. Its hard to specify a decent algorithm here because we 
don't have real-life use cases yet for the data that is proving 
problematic. For example, if the problem ends up being that one of the 
RPID values is changing much more often than anyone had intended (for 
example a cool-new-box ends up measuring your mood from biometrics and 
places it into a <mood> element), you would get much better overall 
results by just filtering out <mood>.

As a detail, the draft talks about using the option tag in a Require; 
there is little benefit to that, similar to the norefersub case we have 
discussed.

-Jonathan R.

Aki Niemi wrote:

> All,
> 
> I was about to abandon this draft for good, but lately I have been 
> getting offline queries and interest in this work, so I thought I'd 
> better pick it up.
> 
> So I've made an update to the event throttle draft based on list 
> discussion here at SIPPING plus one comment on the sip-implementors. 
> Here's a short list of the changes:
> 
> - Fixed typos
> 
> - Improved the ABNF definitions
> 
> - Added an IANA considerations section (with both header field parameter 
> and option tag registration information)
> 
> - Rewrote the model description
> 
> - Added discussion and analysis of estimated bandwidth savings
> 
> - Added a chapter that offers some more description of how the notifier 
> handles the different buffer policies
> 
> Until it appears in the archives, you can pick up a copy here:
> 
> http://people.nokia.net/~aki/drafts/draft-niemi-sipping-event-throttle-02.txt 
> 
> http://people.nokia.net/~aki/drafts/draft-niemi-sipping-event-throttle-02.html 
> 
> 
> I think there is at least one major open issue left, which is whether or 
> not we want to describe the notifier's buffer policy in more detail than 
> what the draft currently has. I am a little reluctant to adding this, 
> but if folks see this as necessary, I can sketch a proposal and send it 
> to the list before Minneapolis.
> 
> Process-wise, I would be willing to move forward here in the 
> Experimental track, but I think the SIP change process requires a 
> Standards Track RFC to register an option-tag.
> 
> Thoughts, comments?
> 
> Cheers,
> Aki
> 
> _______________________________________________
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.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: Aki Niemi <[email-masked]>
Date: Fri, 11 Mar 2005 17:31:43 +0200

Inline.

> deal with it (compared to compression or filters, both of which reduce 

I agree that the mechanism represents a good deal of forward thinking at 
this point. Then again I don't see that we have to wait until this 
becomes a problem before we solve it. We have, for example, the 
experimental track in the standards process, which I believe is also 
useful for this sort of scenarios.

The developers I've talked to like the throttle draft. Compared to the 
filters, for example, the benefit compared to implementation complexity 
seems much bigger to them.

We have to remember that a fully conformant implementation of the 
presence specs already has to implement a throttle, with the minimum 
time between notifications being 5 seconds. What my draft does is merely 
make that parameter a configurable one.

> results by just filtering out <mood>.

The point is you don't want to completely filter out <mood>; you want to 
limit the amount of updates to <mood>.

So, I don't understand the argument. This is not a better way - just 
different. And the throttle mechanism is also an optional mechanism and 
no-one is forced to implement it.

> there is little benefit to that, similar to the norefersub case we have 

Ok. I wasn't part of that hallway discussion and didn't immediately get 
the summary either. Ideally, this would be part of RFC 3265 already, so 
no negotiation would be needed.

The draft also talks about the options that a UA has if the presence 
server doesn't understand the extension. For example, it could poll the 
resource state instead of subscribing to it.

Cheers,
Aki

---

From: Arjun Roychowdhury <[email-masked]>
Date: Mon, 14 Mar 2005 12:50:10 -0500

Aki,
would like to voice my support on the simplistic approach of your draft.

On one hand, its a given that its not a complete solution and Paul's
suggestion tends to be more complete. However, *specifically* for the
mobile handset market, a feature rich XML body parsing, though
complete, may not really be warranted. Every time I propose a new
feature for these devices, I keep getting reminded about the
importance of battery power for these devices.

I like your header approach - and yes, complete filtering may or may
not be acceptable depending on what event you are filtering.

<evil-talk>
Also, putting this in the header helps network proxies legally
modify/insert the threshold parameter on behalf of the endpoint,
especially in cases where the server knows the nature of the network
the endpoint is currently visiting in. It makes the endpoint code
simpler too.
Oh no, wait, this adds intelligence back to the network.
</evil-talk>

regds
arjun

On Fri, 11 Mar 2005 17:31:43 +0200, Aki Niemi <[email-masked]> wrote:

-- 
Arjun Roychowdhury

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Mar 2005 13:04:32 -0500

I'm not sure I buy the "simple" approach as being workable in the cases 
that have been raised.

Suppose you have a 100 buddies and are on a slow wireless link. How do 
you restrict the rate enough to help and still have anything that is 
worthwhile? Some of your buddies may be transitioning betweeen open and 
closed with some frequency, and you need to see that transition so you 
know when to contact them. Others may simply be moving around a lot and 
updating their location. You don't need that so much.

Also, the techniques may differ depending on whether you generate all 
the subscriptions from the endpoint, or from a buddylist server. If from 
a server, then the status of all your buddies will be coming down on one 
subscription. If so, then a simple rate limiting may not be at all helpful.

I would suggest that in a case like this you may want to prioritize 
which buddies you hear about. So you hear about your close friends 
first, and hear about others only if there is bandwidth remaining. I 
think that is better handled by some kind of adaptive filter.

	Paul

---

From: Arjun Roychowdhury <[email-masked]>
Date: Mon, 14 Mar 2005 13:57:02 -0500

Paul,
no question that an adaptive filtering mechanism is more powerful. I
am just trying to think if one can propose a mechanism that does not
need me to parse a rich xml definition all the time.

Is it possible to have both a header and a body solution ? The header
will limit itself to top level event package throttling, while a body
may be provided to add more detail.

The issue, I often see in the mobile handset world is that the usual
concept of 'generality over efficiency' is a harder sell, since the
devices are relatively more limited in capacity/power than, say, a
wired IP phone with an AC adaptor. Therefore, one does need to
evaluate the frequency of ulitization of the additional
features for this market space.

Even though memory power has gone up, battery power in relation is
still a significant bottleneck (not to mention price point
competitiveness which drives to a great degree what goes into a
phone).

 I personally believe rate limiting based on event packages is a
reasonable solution. If we extend the problem space to theoretical
limits, it does look weaker. However, how many people really view 100
online buddies in their mobile phones (an address book may have 100
people, but buddy lists are usually less than 30, for the average
joe).

If my buddy is really moving at such a high speed between networks, I
am not sure if I really need to be updated that often, since even if I
did get a real-time status, its likely by the time I made contact, the
status would have moved on to
something else. Therefore, I am not sure if this example really
negates the effectiveness of event-throttling, since  the point of
throttling is to introduce delays of notification.

Sitting at my desktop, I would love to see if Paul just came online or
not at that very moment. However that may not be a requirement when I
am on my mobile phone. Even if I do get to know paul is free, 20
seconds after he really gets free, there is still a good chance I can
catch you before you leave for the next meeting.

Therefore, event throttling is indeed a tradeoff.

Another useful feature, I feel, is for a closed network to be able to
participate in the decision of even throttling thresholds both from a
perspective of bandwidth management and complexity management on
behalf of the device. The event framework gives app server developers
an open license to add all sorts of 'cool-information' features which
the teen population would love to subscribe to - and they don't really
know or care what crowds the network and what does not.

regds
arjun
-- 
Arjun Roychowdhury
Flextronics Software Systems