headers
Paul Kyzivat | 2 Aug 2008 00:45
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06


Brian Rosen wrote:
> It works, it's just too much signaling.  It's also hard for the watcher to
> know when to switch.
> 
> I really think min is s simpler mechanism.
> 
> I've been talking to the throttle authors.  I'll have a proposal on the list
> shortly.

I hear you. I understand it is simpler. But I just have trouble making 
any *sense* semantically out of a minimum frequency for a throttle.

I certainly hope it won't have you sending *identical* data when nothing 
has changed since the last send.

	Paul

> Brian
> 
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat <at> cisco.com]
>> Sent: Thursday, July 31, 2008 10:22 PM
>> To: Brian Rosen
>> Cc: 'sipping'
>> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
>>
>>
>>
>> Brian Rosen wrote:
(Continue reading)

Permalink | Reply |
headers
Salvatore Loreto | 7 Aug 2008 17:23
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06

Hi Paul,

just to clarify,
with the *max=X* you are asking not to receive more then a Notify every 
X seconds, no matter what will happen during the X seconds
with the *mix=Y* you are asking to receive an update, if something has 
changed, every Y second. So if you won't receive anything after Y second
you can relay on the fact that nothing is changed .

Sal

Paul Kyzivat wrote:
>
>
> Brian Rosen wrote:
>> It works, it's just too much signaling. It's also hard for the 
>> watcher to
>> know when to switch.
>>
>> I really think min is s simpler mechanism.
>>
>> I've been talking to the throttle authors. I'll have a proposal on 
>> the list
>> shortly.
>
> I hear you. I understand it is simpler. But I just have trouble making 
> any *sense* semantically out of a minimum frequency for a throttle.
>
> I certainly hope it won't have you sending *identical* data when 
> nothing has changed since the last send.
(Continue reading)

Permalink | Reply |
headers
Paul Kyzivat | 7 Aug 2008 18:20
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06


Salvatore Loreto wrote:
> Hi Paul,
> 
> just to clarify,
> with the *max=X* you are asking not to receive more then a Notify every 
> X seconds, no matter what will happen during the X seconds
> with the *mix=Y* you are asking to receive an update, if something has 
> changed, every Y second. So if you won't receive anything after Y second
> you can relay on the fact that nothing is changed .

OK, at least you aren't proposing to send every Y seconds even if 
nothing has changed!

But what is the difference between the min present and the min absent? 
What you describe sounds like what would happen anyway - when there is a 
change, you get notified.

Of course the notifier will always have some latency, and so may not get 
around to sending for awhile. But I don't think you can legislate that away.

Or are you saying that you will receive a notification after Y seconds 
if the event state has changed, even if the result after applying 
filters is unchanged???

	Paul

> Sal
> 
>
(Continue reading)

Permalink | Reply |
headers
Adam Roach | 13 Aug 2008 00:23
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06

On 8/7/08 11:20 AM, Paul Kyzivat wrote:
>
>
> Salvatore Loreto wrote:
>> Hi Paul,
>>
>> just to clarify,
>> with the *max=X* you are asking not to receive more then a Notify 
>> every X seconds, no matter what will happen during the X seconds
>> with the *mix=Y* you are asking to receive an update, if something 
>> has changed, every Y second. So if you won't receive anything after Y 
>> second
>> you can relay on the fact that nothing is changed .
>
> OK, at least you aren't proposing to send every Y seconds even if 
> nothing has changed!
>
> But what is the difference between the min present and the min absent? 
> What you describe sounds like what would happen anyway - when there is 
> a change, you get notified.

The interesting thing here is what happens when <trigger> elements are 
used in filters associated with these subscriptions. The state may have 
changed, but it may not have changed enough to satisfy any of the 
<trigger> criteria.

That's the real value of setting a minimum amount of time between 
notifications.

/a
(Continue reading)

Permalink | Reply |
headers
krisztian.kiss | 9 Aug 2008 01:03
Picon

Re: Comments on draft-niemi-sipping-event-throttle-06

Hi Paul et al,

>Or are you saying that you will receive a notification after Y 
>seconds if the event state has changed, even if the result 
>after applying filters is unchanged???

That is exactly the idea. If you look at the use case Brian described
as...
"send me an update when the target has moved at least 10 meters, but
don't send more than 10 updates per minute.  Also, if the target hasn't
moved more than 10 meters in a minute, send me an update anyway" you
would get a NOTIFY if the target moved 9 meters and one minute already
passed from the last notification.
I also prefer this approach (adding a "min" value to throttle) instead
of letting the watcher constantly monitor whether the supplied filter is
still satisfactory and re-SUBSCRIBE with new filter if needed. The
watcher could still do that in some cases but in most cases enough
NOTIFYs could be received thanks to the "min" value.

During the discussion with Brian, Salvatore and Adam we also discussed
adding an average rate as a 3rd parameter to throttle.  Some
applications may need that in addition to minimum time between
notifications. We need some kind averaging algorithm, nothing really
complex but a simple running average. It would be good to extend the
discussion also about this parameter and get the WG's feedback.

Cheers,
Krisztian

>-----Original Message-----
(Continue reading)

Permalink | Reply |
headers
Adam Roach | 13 Aug 2008 00:48
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06

On 8/8/08 6:03 PM, krisztian.kiss <at> nokia.com wrote:
> During the discussion with Brian, Salvatore and Adam we also discussed
> adding an average rate as a 3rd parameter to throttle.  Some
> applications may need that in addition to minimum time between
> notifications. We need some kind averaging algorithm, nothing really
> complex but a simple running average.

And I promised to propose a coherent scheme that ties all three of these 
parameters together.

As Krisztian mentions, we'll have three "Event" header field parameters 
on the wire.

The first, "throttle", would work as described in the current draft.

The second, "force", would specify a maximum notification time period, 
in seconds. Whenever the time since the most recent notification exceeds 
the value in the "force" parameter, then the current state would be sent 
in its entirety (just like after a subscription refresh).

The third, "average", would specify an average cadence at which 
notifications are desired, in seconds. It works similar to the "force" 
parameter, except that it will slow down the speed at which 
notifications are sent if several have already been sent recently. I've 
played around with the numbers for this a bit, and I think I've found a 
formula that had good damping properties to satisfy this goal.

The formula has three inputs:

   1. "average" - The value of the "average" parameter conveyed in the
(Continue reading)

Permalink | Reply |
headers
Song, Youngsun | 12 Aug 2008 17:52
Favicon

Differences between RFC4722 and RFC5022 for MSCML

Hello,

Could someone please describe the differences between RFC4722 and RFC5022 for MSCML? Is there anyplace
that summarizes the changes?

Thanks for your help in advance.
YoungSun
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply |
headers
Diego A Alonso | 12 Aug 2008 18:03
Picon
Favicon

Re: Differences between RFC4722 and RFC5022 for MSCML

Hi,
	4722 is Obsolete.
			
		Rgds,

				Diego

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf
Of Song, Youngsun
Sent: Tuesday, August 12, 2008 12:52 PM
To: 'sipping <at> ietf.org'
Subject: [Sipping] Differences between RFC4722 and RFC5022 for MSCML

Hello,

Could someone please describe the differences between RFC4722 and RFC5022
for MSCML? Is there anyplace that summarizes the changes?

Thanks for your help in advance.
YoungSun
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.138 / Virus Database: 270.6.1/1605 - Release Date: 8/11/2008
4:59 PM
(Continue reading)

Permalink | Reply |
headers
Paul Kyzivat | 9 Aug 2008 06:42
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06

Hi Krisztian,

krisztian.kiss <at> nokia.com wrote:
> Hi Paul et al,
> 
>> Or are you saying that you will receive a notification after Y 
>> seconds if the event state has changed, even if the result 
>> after applying filters is unchanged???
> 
> That is exactly the idea. If you look at the use case Brian described
> as...
> "send me an update when the target has moved at least 10 meters, but
> don't send more than 10 updates per minute.  Also, if the target hasn't
> moved more than 10 meters in a minute, send me an update anyway" you
> would get a NOTIFY if the target moved 9 meters and one minute already
> passed from the last notification.

Well, it still seems a bit odd to me. But I think the main thing thatSo, 
needs to be considered is to distinguish between voluntary filters 
applied by request of the caller, and authorization based filters that 
are applied because a subscriber isn't permitted to see certain parts of 
the state. In that case, notifications that show no change would leak 
information about state changes to inaccessible information.

If the filter is just related to the amount of change, not masking a 
particular piece of state, then this isn't a problem. But then this only 
applies to that class of filter.

So just to double check - if I am subscribed to presence with a filter 
that says to unconditionally exclude location - and I have a "min"
(Continue reading)

Permalink | Reply |
headers
Brian Rosen | 13 Aug 2008 22:24

Re: Comments on draft-niemi-sipping-event-throttle-06

The change in location would not trigger a notification based on min.
However, if min was set, time would trigger a notification.  If you
unconditionally exclude location, the PIDF wouldn't contain location I would
think.

Brian

> -----Original Message-----
> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf
> Of Paul Kyzivat
> Sent: Saturday, August 09, 2008 12:42 AM
> To: krisztian.kiss <at> nokia.com
> Cc: sipping <at> ietf.org
> Subject: Re: [Sipping] Comments on draft-niemi-sipping-event-throttle-06
> 
> Hi Krisztian,
> 
> krisztian.kiss <at> nokia.com wrote:
> > Hi Paul et al,
> >
> >> Or are you saying that you will receive a notification after Y
> >> seconds if the event state has changed, even if the result
> >> after applying filters is unchanged???
> >
> > That is exactly the idea. If you look at the use case Brian described
> > as...
> > "send me an update when the target has moved at least 10 meters, but
> > don't send more than 10 updates per minute.  Also, if the target hasn't
> > moved more than 10 meters in a minute, send me an update anyway" you
> > would get a NOTIFY if the target moved 9 meters and one minute already
(Continue reading)

Permalink | Reply |
headers
Paul Kyzivat | 14 Aug 2008 00:05
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06


Brian Rosen wrote:
> The change in location would not trigger a notification based on min.
> However, if min was set, time would trigger a notification.  If you
> unconditionally exclude location, the PIDF wouldn't contain location I would
> think.

Hmm. If I follow you, then indeed that would potentially leak 
information that the location, or at least something filtered out, has 
changed, even though it doesn't say how it has changed.

If this is just voluntary filters, and the changed information is 
potentially accessible, then this is no big deal.

But if this also applies to the sort of filtering that goes on due to 
lack of authorization to see a particular piece of information, then it 
*is* a problem. Just *knowing* that you have moved, when I am not 
authorized to see your location, could be a bad thing.

	Thanks,
	Paul

> Brian
> 
>> -----Original Message-----
>> From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On Behalf
>> Of Paul Kyzivat
>> Sent: Saturday, August 09, 2008 12:42 AM
>> To: krisztian.kiss <at> nokia.com
>> Cc: sipping <at> ietf.org
(Continue reading)

Permalink | Reply |
headers
Adam Roach | 14 Aug 2008 00:13
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06

On 8/13/08 5:05 PM, Paul Kyzivat wrote:
>
>
> Brian Rosen wrote:
>> The change in location would not trigger a notification based on min.
>> However, if min was set, time would trigger a notification.  If you
>> unconditionally exclude location, the PIDF wouldn't contain location 
>> I would
>> think.
>
> Hmm. If I follow you, then indeed that would potentially leak 
> information that the location, or at least something filtered out, has 
> changed, even though it doesn't say how it has changed.

No. That's not what we're trying to say.

With this parameter (what Brian is calling "min" and I'm calling 
"force"), you'll get a notification. It doesn't matter whether something 
you can see has changed. It doesn't matter whether something you *can't* 
see has changed. It doesn't matter what triggers you have in place.

It will act *EXACTLY* *AND* *PRECISELY* *LIKE* the NOTIFY you get after 
a SUBSCRIBE refresh. If there's an information leak here, then it's been 
here for over 6 years.

But I don't think there is one.

/a
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
(Continue reading)

Permalink | Reply |
headers
Paul Kyzivat | 14 Aug 2008 01:32
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06


Adam Roach wrote:
> On 8/13/08 5:05 PM, Paul Kyzivat wrote:
>>
>>
>> Brian Rosen wrote:
>>> The change in location would not trigger a notification based on min.
>>> However, if min was set, time would trigger a notification.  If you
>>> unconditionally exclude location, the PIDF wouldn't contain location 
>>> I would
>>> think.
>>
>> Hmm. If I follow you, then indeed that would potentially leak 
>> information that the location, or at least something filtered out, has 
>> changed, even though it doesn't say how it has changed.
> 
> No. That's not what we're trying to say.
> 
> With this parameter (what Brian is calling "min" and I'm calling 
> "force"), you'll get a notification. It doesn't matter whether something 
> you can see has changed. It doesn't matter whether something you *can't* 
> see has changed. It doesn't matter what triggers you have in place.
> 
> It will act *EXACTLY* *AND* *PRECISELY* *LIKE* the NOTIFY you get after 
> a SUBSCRIBE refresh. If there's an information leak here, then it's been 
> here for over 6 years.
> 
> But I don't think there is one.

OK, then I agree there is no information leak.
(Continue reading)

Permalink | Reply |
headers
Ian Elz | 15 Aug 2008 11:11
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06

Paul,

You may think that it is wasteful to notify when there are no changes
but there could be services which will monitor for 'no change'. These
types of services could monitor no change and perform actions if there
is no change after a specified period.

You do not want to rely on the absence of notifications to perform the
action as this could be a result of a failure in the system.

Having a minimum rate of notifications would be specified by the
specific service needing the data.

It is necessary to be able to specify that there is no minimum rate to
allow services which are only interested when changes do actually occur.

Ian Elz

System Manager
DUCI LDC UK
(Lucid Duck)

Office: + 44 24 764 35256
gsm: +44 7801723668
ian.elz <at> ericsson.com

-----Original Message-----
From: sipping-bounces <at> ietf.org [mailto:sipping-bounces <at> ietf.org] On
Behalf Of Paul Kyzivat
Sent: 14 August 2008 00:32
(Continue reading)

Permalink | Reply |
headers
Adam Roach | 14 Aug 2008 17:10
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06

On 8/13/08 6:32 PM, Paul Kyzivat wrote:
>
> OK, then I agree there is no information leak.
>
> So in effect you are creating "session timer for subscriptions".
>
> While I think it is unnecessary and wasteful to do this when there has 
> been no change, I will not object - as long as it has been agreed that 
> it is fine for a notifier to terminate the subscription when it knows 
> that future notifications will all be redundant. In particular, when 
> only location is being conveyed, and its for a UA with a fixed 
> location. I think Brian agreed that made sense.

I think the plan is to make the parameters act pretty much like this 
kind of stuff does elsewhere -- that is, the client can send a requested 
"force" parameter of x, but the server can reply with an authoritatice 
"force: parameter of "y" (where y>= x). Presumably, this would include 
the case where y == infinity (i.e., removing the force parameter 
altogether).

Make sense?

/a
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
(Continue reading)

Permalink | Reply |
headers
Paul Kyzivat | 14 Aug 2008 18:45
Picon
Favicon

Re: Comments on draft-niemi-sipping-event-throttle-06


Adam Roach wrote:
> On 8/13/08 6:32 PM, Paul Kyzivat wrote:
>>
>> OK, then I agree there is no information leak.
>>
>> So in effect you are creating "session timer for subscriptions".
>>
>> While I think it is unnecessary and wasteful to do this when there has 
>> been no change, I will not object - as long as it has been agreed that 
>> it is fine for a notifier to terminate the subscription when it knows 
>> that future notifications will all be redundant. In particular, when 
>> only location is being conveyed, and its for a UA with a fixed 
>> location. I think Brian agreed that made sense.
> 
> I think the plan is to make the parameters act pretty much like this 
> kind of stuff does elsewhere -- that is, the client can send a requested 
> "force" parameter of x, but the server can reply with an authoritatice 
> "force: parameter of "y" (where y>= x). Presumably, this would include 
> the case where y == infinity (i.e., removing the force parameter 
> altogether).
> 
> Make sense?

Maybe its just me, but no, it doesn't make a lot of sense to me.

Thinking further about what this means - you say the notification you 
get is exactly line the initial notify after a subscription. That means 
the subscriber could achieve the same result by sending a reSUBSCRIBE at 
this minimum interval. The only value of this mechanism is then saving
(Continue reading)

Permalink | Reply |
headers
Adam Roach | 15 Aug 2008 00:26
Favicon

Notifier-terminated subscriptions (was Re: Comments on draft-niemi-sipping-event-throttle-06)

On 8/14/08 11:45 AM, Paul Kyzivat wrote:
>
> In any case, the rate value is a bit orthogonal to the question I was 
> asking. The rate becomes moot if the subscription is terminated. I 
> just want to ensure that it is acceptable behavior for the notifier to 
> terminate the subscription when it believes it has said all there is 
> to say on the subject, and that a subscriber that wants to be notified 
> on an ongoing basis won't get upset with this.

Okay, I think I see what you're saying now. I agree that the question 
you're raising is unrelated to throttling. I would assert, then, that it 
does not need to be addressed in the throttle document.

I've changed the subject to reflect the (new, unrelated) topic you're 
raising.

> In particular I am thinking of the gateways to millions (maybe 
> billions) of landline phones that have fixed locations. When one of 
> them makes a 911 call, and that happens to be handled by a SIP PSAP, 
> the GW ought not be required to maintain a subscription after having 
> delivered the one and only address it has for that line. 

It seems to me that you'd want a new "reason" code to represent this 
kind of situation. I'll note it as an suggested improvement in the bug 
tracker for 3265.

/a
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
(Continue reading)

Permalink | Reply |

Gmane