Subject: [Sipping] Event notification rate limiting requirements

From: [email-masked]
Date: Fri, 24 Jan 2003 11:20:59 +0200

Hi All,

In IETF55 it was agreed that the filtering requirements need to be package specific, while rate limiting might be generic across all packages.

There is now a new draft available that discusses the requirements for a generic event notification rate limiting mechanism, or event throttle mechanism:

http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttle-reqs-00.txt

One issue that has come up is that there are scenarios, where throttles in fact need to be closely combined with event filters. For example, assigning specific throttles to notifications from specific presentities in a presence-list event requires that a single event subscription applies several different throttles.

So the main question is: should there be a generic throttle mechanism, or are throttles event-package or filter-specific? Or do we in fact need both types?

Any 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 25 Jan 2003 00:10:53 -0500

Thanks for writing this up.

It seems to me that the main issue is, as you point out, how this 
relates to filters. The question really is, how is it that the notifier 
reduces the notification rate to the desired limit? I can see a few 
choices here:

1. the notifier implements a simple, package-independent algorithm that 
merely drops notifications that would cause the notification rate to be 
exceeded.

2. the notifier implements a vendor-proprietary algorithm that 
selectively discards notifications in an intelligent, package-specific 
way, meeting the desired notification rate limit.

3. the notifier implements a subscriber-provided filter, and its up to 
the definition of this filter to make sure that the rate is kept low enough

4. the notifier implements a subscriber-provided filter, and if the 
resulting notification rate is still not below the limit, it implements 
1 or 2 above.

Approach 1 is a mistake, I think. You need to intelligently filter in 
order to still provide a useful service (approach 2). In the case of 
buddy list presence, for example, the PA may choose an algorithm which 
round-robins through the buddy list, selecting the next buddy whose 
state has changed since the last notification to the watcher, and sends 
their state to the watcher. THis guarantees that no buddy is "starved" 
in terms of getting its updates through to the watcher.

I would tend to think that approach 2 (having the client provide just 
the rate, and having the server implement a proprietary algorithm to 
meet it) is useful, as is supplying a filter to limit the rate, along 
with the orthogonal combination of the two.

A few comments on the requirements:

>  REQ3: The subscriber SHOULD be allowed to indicate support for the
>          throttle mechanism without requiring it.

what is the point of this requiremetn?

>  REQ8: The notifier MUST be allowed to use a maximum rate lower than
>          the one given by the subscriber.

is this implying some kind of rate negotiation mechanism, akin to the 
Expires value in registrations? If so, there are some more requirements 
you need, such as conveying the final maximum rate back to the client.

Is the assumption that the rate is a limit on the peak transmission 
rate, or is it a leaky-bucket style limit which provides an average 
maximum but allows for small bursts?

-Jonathan R.

[email-masked] wrote:
 > Hi All,
 >
 > In IETF55 it was agreed that the filtering requirements need to be
 > package specific, while rate limiting might be generic across all
 > packages.
 >
 > There is now a new draft available that discusses the requirements
 > for a generic event notification rate limiting mechanism, or event
 > throttle mechanism:
 >
 > http://www.ietf.org/internet-drafts/draft-niemi-sipping-event-throttl-
 > e-reqs-00.txt
 >
 > One issue that has come up is that there are scenarios, where
 > throttles in fact need to be closely combined with event filters. For
 > example, assigning specific throttles to notifications from specific
 > presentities in a presence-list event requires that a single event
 > subscription applies several different throttles.
 >
 > So the main question is: should there be a generic throttle
 > mechanism, or are throttles event-package or filter-specific? Or do
 > we in fact need both types?
 >
 > Any 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.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 26 Jan 2003 20:00:36 -0500

> maximum but allows for small bursts?

This is important! For instance, I believe the limit on presence 
notifications is currently 5 seconds. Now suppose you have a phone that 
changes presence state to indicate "On the Phone". This means that there 
are two presence changes per call. Now limiting calls to one every 10 
seconds may be reasonable. But saying that you must wait 5 seconds after 
completing one call before answering another (or reporting it) isn't so 
reasonable.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Jan 2003 08:41:20 -0500

Complexity can get out of hand pretty quickly here. Once you have a 
leaky bucket with queueing, you have to start worrying about removing 
pending announcements that cancel each other. No point sending 'on the 
phone' 30 minutes later if the person has long since ceased talking, 
particularly since the user interface may not be able to tell whether 
this notification is still current or not, particularly after you 
gateway into other systems.

If you just drop notifications, you can get 'stuck' in the wrong state, 
like 'talking on the phone', for very long periods of time.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Jan 2003 09:54:24 -0500

Replying to a bunch of comments:

My point is that a single number, strictly enforced, isn't sufficient to 
achieve this. In general it may be rare for a call to last less than 30 
seconds, so I am satisfied to limit to an average rate of no more than 2 
notifications per 30 seconds. But limiting to one notification per 15 
seconds may be unacceptable, because in general it means 15 seconds of 
idle time before another call.

Hisham's approach has a fatal flaw. Suppose I want to call you, but you 
are on the phone most of the time - you take 30 second breaks between 30 
minute phone calls. At what rate must you accept notifications in order 
to have a chance to get a call through to me? If there is no averaging, 
you probably have to set your rate at no less than 4/minute (15 seconds) 
to have a chance. But you don't want to be getting them at that rate 
continuously.

Perhaps it is sufficient to specify this as two numbers: N/T. (Than is, 
N notifications per time interval T.) At least that seems sufficient for 
this case. And it isn't inordinately complex to implement.

So, as a client you will in general get better results with (X*N)/(X*T) 
than with N/T, at the cost of some potential bursts of X messages. In my 
example an X of 2 is sufficient because the presentity is alternating 
between two states.

	Paul

[email-masked] wrote:
 > We have to have a number here that doesn't jeopardise a service but 
also doesn't wake watchers susceptible to DoS attacks.

[email-masked] wrote:
 >
 > I agree. But isn't then the use of a throttle mechanism ill-adviced, 
if one requires more frequent updates than what a throttled subscription 
would give?

[email-masked] wrote:
> One would think that there is only one notify in the queue that gets replaced by an update to, for example, presence of a presentity.
> 
> If I am "on the phone" for 20 mins (which results in another presence state change to "available" after that), but my watcher is notified every 30 mins. Then I would expect the presence service to send the newest notify which carries the info that I'm available.
> 
> -5 mins - "available"
> <-- NOTIFY to watcher "available"
> 0 mins - "on the phone"
> 20 mins - "available"
> 30 mins - "available"
> <-- NOTIFY to watcher "available"
> 
> You don't want to queue and send all notifies, just the most recent one at the time of sending a notify.