Subject: [Sipping] Throttling Work

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Jul 2008 12:29:04 +0300

Folks,

we have an official SIPPING draft listing the requirements for the
throttling work:

http://tools.ietf.org/html/draft-ietf-sipping-event-throttle-reqs-00

However, for a number of reasons, work on solutions did not fully take
off. In any case, we have the following individual draft:

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

Now, it seems that interest in this work is coming back. OMA seems to
need this and there are individual drafts in other WGs attempting to do
something similar:

http://www.ietf.org/internet-drafts/draft-polk-sip-location-get-00.txt

We would like to get discussions on the list on this topic in order to
judge the level of interest within the SIPPING community and come up
with a way forward.

Thanks,

Gonzalo
SIPPING co-chair
_______________________________________________
Sipping mailing list  https://www.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: Salvatore Loreto <[email-masked]>
Date: Thu, 24 Jul 2008 14:20:01 +0300

Hi,

I fully agree on the fact that we should work on it and define a 
mechanism that
let throttle and even pause a event notification.
In fact there is a need not only in OMA but as Gonzalo has pointed out also
in other IETF wgs like geopriv.

moreover other then the niemi-sipping-event-throttle draft
there is also another draft: vakil-sipping-notify-pause that in some way 
overlap
the work in the throttle draft, in fact it define an extension to pause 
but not to throttle
an event notification.

regards
Sal

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 24 Jul 2008 14:25:59 +0300

Gonzalo,

why isn't draft-niemi-sipping-event-throttle a WG item or even an RFC yet?

Ciao
Hannes

Salvatore Loreto wrote:
> there is also another draft: vakil-sipping-notify-pause that in some 
> way overlap
> the work in the throttle draft, in fact it define an extension to 
> pause but not to throttle
> an event notification.
>
> regards
> Sal
>
> Gonzalo Camarillo wrote:
>> Folks,
>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 24 Jul 2008 14:48:53 +0300

Hi,

a mixture of objections from some folks and lack of energy from others. 
  I hope we can this time progress this and define a single mechanism to 
do this.

Cheers,

Gonzalo

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Jul 2008 13:52:57 -0500

>http://www.ietf.org/internet-drafts/draft-polk-sip-location-get-00.txt

The ID above has several filter options in it (8 to date, actually).

Only Filter#6 within draft-polk-sip-location-get-00.txt appears to be 
directly related to draft-ietf-sipping-event-throttle-reqs-00.

Given that there are filter documents in not 1, but at least 4 WGs, 
this ID got by me - as with a quick review, "throttling" does not 
mean "once every n intervals of time", as I viewed throttling as 'you 
need to slow down how many you want to send, implicitly building up a 
backlog'.

Forgiveness is asked - as I do not wish to duplicate existing work.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jul 2008 15:08:54 -0400

Gonzalo,

In the past, while agreeing with the objective, I have had problems with 
the mechanisms. But draft-niemi-sipping-event-throttle-06.txt seems 
pretty good to me.

I doubt this is the last word on the subject, but it seems like a 
reasonable first step.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 24 Jul 2008 18:22:40 -0400

Aki pointed us to this draft in discussions within geopriv on the notion of
a filter to control the rate at which updates to location occur in a
presence subscription or other event package.  He specifically was talking
about using throttle instead of the mechanism proposed in
draft-ietf-geopriv-loc-filter2-02

It was noted that we have a requirement for a minimum update rate as well as
a maximum.

A typical problem we are trying to solve is "send me a new PIDF with
location when the target moves by 10 meters, but don't send more that 10
updates per minute.  Also, even if the target doesn't move by 10 meters,
send me at least an update every minute".

Aki believed that throttle was the right mechanism to specify the rate part
of that.

I am somewhat skeptical, but none-the-less open to thinking about using
throttle for that purpose.

We need a way to control event notification in that matter.  If we do agree
throttle is the way to do that, then I'm interested in making sure the
mechanism gets standardized.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gonzalo Camarillo
> Sent: Thursday, July 24, 2008 5:29 AM
> To: sipping
> Cc: Mary Barnes
> Subject: [Sipping] Throttling Work
> 
> Folks,
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 24 Jul 2008 18:00:49 -0500

>mechanism gets standardized.

ditto on the reasoning, an on the requirement and making sure this 
gets solved for

[either I wasn't told about his throttle ID or I wasn't paying 
attention at the time, which is why this doc didn't get referenced in 
draft-polk-sip-location-get-00]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jul 2008 19:46:10 -0400

Why would you require an update even if nothing has changed?

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Thu, 24 Jul 2008 19:07:52 -0500

Is there some reason Aki's draft is not in the tracker?

On Jul 24, 2008, at 6:00 PM, James M. Polk wrote:

> attention at the time, which is why this doc didn't get referenced  
> in draft-polk-sip-location-get-00]
>
>
>> Brian
>>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Jul 2008 09:00:05 +0300

Hi Robert,

it is just a failure in the tracker system. As you can see in the 
history in the draft, the tracker moves it automatically to "dead" every 
time the draft expires. When a new version is submitted, the tracker 
resurrects the draft, also automatically (i.e., it moves it out of the 
dead state). However, the tracker failed to do so the last time the 
draft was refreshed, for some reason:

https://datatracker.ietf.org/idtracker/draft-niemi-sipping-event-throttle/

In any case, since the text of the draft is available at the IETF site 
anyway, this is no big deal.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Jul 2008 09:02:58 +0300

Hi James,

> Forgiveness is asked - as I do not wish to duplicate existing work.

Believe me: you are not the only one that is not aware of every single 
draft (including individual ones) that gets submitted to the IETF and 
relates to the RAI area ;o) There are simply too many things going on. 
That is why area-wide and cross-WG reviews are useful.

Cheers,

Gonzalo

---

From: Robert Sparks <[email-masked]>
Date: Fri, 25 Jul 2008 08:53:34 -0500

Not a big deal, but not a trivial problem either. Lets talk to the  
tools folks and see if we can find why that autorez failed.

RjS

On Jul 25, 2008, at 1:00 AM, Gonzalo Camarillo wrote:

> history in the draft, the tracker moves it automatically to "dead"  
> every time the draft expires. When a new version is submitted, the  
> tracker resurrects the draft, also automatically (i.e., it moves it  
> out of the dead state). However, the tracker failed to do so the  
> last time the draft was refreshed, for some reason:
>
> In any case, since the text of the draft is available at the IETF  
> site anyway, this is no big deal.
>
> Thanks,
>
> Gonzalo
>
> Robert Sparks wrote:

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 27 Jul 2008 16:24:26 +0300

Hi

actually it would be a good idea extend the throttling with *forcing* a 
minimum rate of reports
as Adam Roach has proposed in an email discussion within the geopriv 
mailing list discussion.

sal

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Jul 2008 07:40:52 +0100

> Why would you require an update even if nothing has changed?

It's not that nothing has changed -- it's that nothing has changed 
enough to satisfy the <trigger> criteria in a filter associated with a 
subscription.

Think of these forced NOTIFY messages like an I-frame in an MPEG video 
stream.

/a