Subject: RE: [Sipping] Event notification rate limiting requirements

From: [email-masked]
Date: Mon, 27 Jan 2003 15:28:26 +0200

> -----Original Message-----
> From: Niemi Aki (NMP/Helsinki) 
> Sent: Monday, January 27, 2003 2:59 PM
> To: Khartabil Hisham (NMP/Helsinki); [email-masked]'
> Cc: [email-masked]'
> Subject: RE: [Sipping] Event notification rate limiting requirements
> 
> 
> I'm still confused... Hey, it's Monday so bear with me ;)
> 
> > I guess I confused myself as well as others.
> > 
> > Yes, lower rate means higher period of time between notifies.
> > 
> > I was talking about subscribers increasing the rate to a 
> > number that is higher than the server's allowed maximum. If 
> > the server has a rate limit of the typical once per 5 
> > seconds, the subscriber must not be able to increase this 
> > rate to, say, 5 times per 5 seconds. 
> > 
> > So the requirement is: The notifier must be able to reject a 
> > subscription containing a rate limit higher that is local 
> > configured maximum.
> 
> My point was that there is no need to reject such a limit, as 
> long as the notifier MUST be allowed to use a lower rate. So 
> the notifier may accept, and still abide by its own internal 
> default policy of 1 notification per 5 seconds. The 
> subscriber is still happy, since its max rate is not 
> exceeded. Such a throttle will be utterly useless, but won't 
> break anything...

Looking at the registration solution; a registrar can lower the expiration time and therefore increase the rate of registration requests. The registrar must not increase the expiration time, i.e. registrar cannot lower the rate of registration and must reject with 423.

I don't have strong feeling either way. Any other opinions?

>  
> > You are talking about the subscriber lowering that rate to a 
> > ridiculously low rate as to once per hour. I think this is ok 
> > and no need to reject those types of requests.
> 
> Except if the effects of such a filter become worse than for 
> example, polling at the same frequency.

Polling, aka fetching, has an extra subscribe/200 that can be avoided with this mechanism.

I used this example in a separate discussion and I'll use it again here: If Aki was driving down from Lapland to Helsinki, I'm interested to get his presence info once every hour or so. By subscribing to his presence and limiting the rate of notifications to 1 per hour is a good thing. I get the notifications automatically. I don't have to manually subscribe every hour and waste bandwidth.

The only scenario where I think a subscription with rate limit may be rejected is when the rate allows 0 notifies to be sent with the subscription duration. I.e. Subscription duration is 1 hour and rate limit is once per 2 hours. I think this scenario is worse than fetching (It might be ok to accept the subscription and only generate the first notify).

Regards,
Hisham

> 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: Henning Schulzrinne <[email-masked]>
Date: Mon, 27 Jan 2003 08:51:51 -0500

> I used this example in a separate discussion and I'll use it again
> here: If Aki was driving down from Lapland to Helsinki, I'm
> interested to get his presence info once every hour or so. By
> subscribing to his presence and limiting the rate of notifications to
> 1 per hour is a good thing. I get the notifications automatically. I
> don't have to manually subscribe every hour and waste bandwidth.

There are two classes of notifications: stateless and stateful. Presence 
(closed/busy) is stateful, in that it persists at the receiver until the 
next announcement. Location is stateless - the accuracy of estimation of 
the variable just decreases as the rate of updates decreases. In many 
cases, physical constraints limit the error. If I know you are in a land 
vehicle, I can draw a circle around a last position report that 
increases its radius at around 70 mph and have high confidence that the 
entity hasn't suddenly gone into hyperspace.

It's relatively easy to ratelimit the latter, much harder to ratelimit 
the former.

> 
> The only scenario where I think a subscription with rate limit may be
> rejected is when the rate allows 0 notifies to be sent with the
> subscription duration. I.e. Subscription duration is 1 hour and rate
> limit is once per 2 hours. I think this scenario is worse than
> fetching (It might be ok to accept the subscription and only generate
> the first notify).
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 Jan 2003 11:36:46 -0500

inline.

Henning Schulzrinne wrote:
 >> subscribing to his presence and limiting the rate of notifications
 >> to 1 per hour is a good thing. I get the notifications
 >> automatically. I don't have to manually subscribe every hour and
 >> waste bandwidth.
 >
 >
 > There are two classes of notifications: stateless and stateful.
 > Presence (closed/busy) is stateful, in that it persists at the
 > receiver until the next announcement. Location is stateless - the
 > accuracy of estimation of the variable just decreases as the rate of
 > updates decreases. In many cases, physical constraints limit the
 > error. If I know you are in a land vehicle, I can draw a circle
 > around a last position report that increases its radius at around 70
 > mph and have high confidence that the entity hasn't suddenly gone
 > into hyperspace.
 >
 > It's relatively easy to ratelimit the latter, much harder to
 > ratelimit the former.

True. Inevitably the result of the rate-limiting will be inaccurate or
obsolete information for longer periods of time. I think that is the
consequence of asking for lower notification rates. Is there any other
choice?

Aki Niemi wrote:
 >> number that is higher than the server's allowed maximum. If the
 >> server has a rate limit of the typical once per 5 seconds, the
 >> subscriber must not be able to increase this rate to, say, 5 times
 >> per 5 seconds.
 >>
 > My point was that there is no need to reject such a limit, as long as
 > the notifier MUST be allowed to use a lower rate. So the notifier may
 > accept, and still abide by its own internal default policy of 1
 > notification per 5 seconds. The subscriber is still happy, since its
 > max rate is not exceeded. Such a throttle will be utterly useless,
 > but won't break anything.

Indeed. In fact, the server needs to support the peak notification rate 
for the presentity anyway. Thats because their may be subscribers who 
don't even have rate limiting, and in that case, they get the regular rate.

The only case where this doesnt hold is the "stateless" data, such as 
location, that Hennign mentions above. IN that case, there is no natural 
notification rate of the data. It changes infinitely fast 
(theoretically). So, the server has its own maximum rate that it will 
send notifications at. In such a case, does the subscriber need to know 
that its requested rate won't be honored, and it willg et a lower rate? 
Perhaps. It depends on the application of the location data. If its 
being used in some kind of tracking application, the lower rate may be 
insufficient.

However, one could say the same about presence genreally. I might have 
some application where I NEED to know the presence of your cell phone, 
and if I dont get it, the subscription is useless. That would require 
some kind of presence-require mechanism. I would rather lump all of 
these together and deal with them in the future if a true need arises.

So, to summarize my ramble, I do not think at this time that there is a 
need to reject a subscription because the requested rate is too high.

-Jonathan R.

-- 
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: Henning Schulzrinne <[email-masked]>
Date: Fri, 31 Jan 2003 15:32:14 -0500

> consequence of asking for lower notification rates. Is there any other

In practice, I suspect that people will use rate-limiting for things 
like location information where reducing the rate reduces the accuracy 
in some predictable fashion, rather than where one 'throttled' 
notification turns the information from useful to completely misleading.

However, we can leave this up to the subscriber and the implementation. 
In many cases, the better thing is to provide several different 
subscriptions, e.g., one that tracks my detailed presence state (do not 
disturb, individual media reachability, etc.), another one that 
basically only tells me if (sum of all OPEN) has changed from zero to 
some positive number. (A poor man's version of a filter.)
Henning