Subject: [Sipping] comments on draft-vakil-sipping-notify-pause

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 12 Mar 2007 23:20:53 -0400

Interesting draft, thanks for putting this together.

The fundamental premise here is that this is an optimization; that the 
cost of terminating a subscription and resubscribing is more than the 
cost of just pausing. I can certainly believe this is true, but its not 
well motivated by the use cases I think.

There are three examples given to when a client doesn't want 
notifications anymore but doesn't want to unsubscribe:

  o  An endpoint, used by the subscriber for presence event may not be
       active at that endpoint, but still logged into the system.  This
       idle endpoint keeps on receiving unnecessary notifications

    o  A wireless handset receiving notifications for events, not paid
       attention to, while wasting over the air bandwidth.  The same
       wireless endpoint may also consume processing and battery power,
       which might be needed for other voice applications, to process
       these unwanted notifications

    o  This problem gets worse for subscriptions to list resources.  It
       tends to create high notification traffic related to the members
       of the list.  This rate increases as the size of the list
       increases.  This puts an undue burden on the notifier, to send
       notification for each list element's event state udpate.
       Therefore, it's preferred to simply pause the notifications on the
       event list subscription

Only the first two are really use cases; the third just says that the 
use cases are worse for list subscriptions. The first and second cases 
seem the same to me. So its all about this one case of a wireless client 
where the user isn't looking at their screen so why bother sending it 
notifications.

It was my understanding that many wireless devices don't use 
subscriptions at all, but just poll. For example when you enter your 
address book, it would poll for current presence and display that. The 
odds are slim that someones status changes in the 5 seconds you are 
looking at your address book so the poll is good enough.

So, in this case, there isn't a subscription to pause in the first 
place, since it was only a poll.

I think the idea here has merit, but I'd like to see these use cases 
more well fleshed out and better justified. As a general rule, I do 
think there is room for improvement in the performance of sub/not 
handling. I just want to make sure we tackle the right optimizations to 
get the biggest bang for our buck.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   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: Mohammad Vakil <[email-masked]>
Date: Tue, 13 Mar 2007 09:18:02 -0700

Thanks Jonathan for taking the time out to provide comments. I can fine tune the use cases.

BTW, regarding wireless handset example you gave, that usually they can poll and not have a subscription is not true. Because processing a fetch subscription(expires=0) is equal in cost to processing a first subscribe of (expires!=0) on the server. Therefore, it's not prudent to poll every 5 sec. There *are* applications where handsets do create a persistent subscription to the list of resources. Basically, with this optimization what we're allowing is a pre-processed subscription on the server, which can be brought back to life with un-pause without having to install fresh subscription.

Besides wireless case, the first use case was about soft clients running on PCs in locked mode indicating "away" states. No user is looking at the updated states received in that mode, then why not save bandwidth and processing on the server.

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Monday, March 12, 2007 8:21 PM
To: IETF Sipping List
Subject: [Sipping] comments on draft-vakil-sipping-notify-pause

Thanks,
Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 13:17:46 -0400

Note that this could apply not just when a pc is in "locked" mode. It 
could apply any time the buddylist doesn't have focus.

	Paul

---

From: Mohammad Vakil <[email-masked]>
Date: Tue, 13 Mar 2007 10:45:11 -0700

Correct, this should be a general use case, not just PC locked.

Another point can be made clear in the draft is, essentially between pause and un-pause, one can do polls using regular refresh subscription logic. Since, it's in notify=off mode, notifier will not un-pause the notification stream. Thus enabling the scenario, Jonathan brought up, at the same time not incurring poll (expire=0) processing cost on the server.

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, March 13, 2007 10:18 AM
To: Mohammad Vakil
Cc: Jonathan Rosenberg; IETF Sipping List
Subject: Re: [Sipping] comments on draft-vakil-sipping-notify-pause

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 14:16:51 -0400

> Correct, this should be a general use case, not just PC locked.

Actually I didn't say what I meant. I meant: could apply any time the 
buddylist isn't *visible*.

> Another point can be made clear in the draft is, essentially between pause and un-pause, one can do polls using regular refresh subscription logic. Since, it's in notify=off mode, notifier will not…

That presents an interesting dilemma:

While the subscription is paused, it will still need to be refreshed. If 
it becomes time to refresh, and the subscriber still isn't interested in 
the status, then it would like the refreshing subscribe to not cause a 
notify (or perhaps an empty one). But if while paused the subscriber 
would like to poll, then it would like to receive a full notification. 
(Or perhaps a delta from the previous one received.)

These two actions are indistinguishable from one another, so you can't 
have both. It seems like there needs to be a way to distinguish these, 
so both can be used.

Ignoring that, it does seem kind of appealing to be able to establish 
the session and then poll within it when status is desired. That could 
be even more appealing with a filter, requesting just the desired info.

	Paul

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 13 Mar 2007 22:26:41 +0100

> have both. It seems like there needs to be a way to distinguish these,
you mean something like 
http://www1.tools.ietf.org/html/draft-niemi-sip-subnot-etags-03?

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 18:43:41 -0400

> http://www1.tools.ietf.org/html/draft-niemi-sip-subnot-etags-03?

Sorry - I haven't paid attention to that one. But I just looked at it, 
and I don't think it solves the problem here. The above can only 
suppress return of the current state if you know the etag for it. But if 
you have paused notifications then you won't know the current etag, so 
you won't be able to suppress notifications that way if you just want to 
refresh the subscription.

	Paul

---

From: Mohammad Vakil <[email-masked]>
Date: Tue, 13 Mar 2007 16:29:11 -0700

We've couple of cases.

1. expires!=0;notify=off
It pauses stream, but could generate full state notification.
(currently draft says "should not", a change can be considered in this area)

2. expires!=0;notify=on
It un-pauses notification stream, and generates full state notifications.

Number #1 can be done number of times to mean poll/fetch in a paused state.

Now to your filtering suggestion earlier, number #1 can also be used with RFC 4661 event filtering mechanism to pull what's relevant.

Thoughts?

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Tuesday, March 13, 2007 3:44 PM
To: Jeroen van Bemmel
Cc: Mohammad Vakil; IETF Sipping List
Subject: Re: [Sipping] comments on draft-vakil-sipping-notify-pause

        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Mar 2007 22:17:39 -0400

> Number #1 can be done number of times to mean poll/fetch in a paused state.

The problem is that there are two sub-cases of 1, both of which are of 
use by the same client, when the stream has already been paused previously:

1a) just refresh the subscription, don't notify. (Needed if the 
subscription is about to expire, and the client wants to preserve it but 
doesn't want the state right now)

1b) request for a full notification, leave paused, and reset the 
expiration time for the subscription. (Needed when you want to poll 
while paused)

How about notify=off for 1a, and notify=once for 1b?

	Paul

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 14 Mar 2007 02:32:26 -0700

Paul Kyzivat wrote:
> > (currently draft says "should not", a change can be considered in
this
> area)

Going back to draft-niemi-sip-subnit-etags-03, there is a solution given
for this sort of problem.  In case 1a, include the following header:
      Suppress-Notify-If-Match: *
And in case 1b, don't.  By using '*', you don't need to know the current
etag, which I think was one of your earlier comments.

The other aspect of draft-vakil-sipping-notify-pause is the suppression
of asynchronous NOTIFYs, which I think can be achieved using event
filtering, as Mohammed suggested.

Does that cover pretty much everything in the draft?

Regards,

Michael

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 14 Mar 2007 11:18:41 +0100

> Going back to draft-niemi-sip-subnit-etags-03, there is a solution
> given for this sort of problem.  In case 1a, include the following
>       header: Suppress-Notify-If-Match: *
> And in case 1b, don't.  By using '*', you don't need to know the
> current etag, which I think was one of your earlier comments.

Comment related to the above: if we are trying to optimize the network 
usage, then why choose a header name with 24 characters?

Regards,
Jeroen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 14 Mar 2007 07:58:55 -0400

The PC locked or unfocused case is an interesting one.

I think it'd be handy to see some modeling here (as was done in 
http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-00.txt). 
That draft is also about subscription optimizations. This is kind of my 
worry. We have now many drafts all biting at different parts of the 
"presence scale" problem:

http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scaling-analysis-00.txt
http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-03.txt
http://www.jdrosen.net/papers/draft-rosenberg-sipping-reg-sub-00.txt
http://www.ietf.org/internet-drafts/draft-vakil-sipping-notify-pause-00.txt

and I recall there were some others too.

I want to make sure we find the right optimizations that cover the 
largest problem set. Which one is the biggest bang for our buck under 
which scenarios?

Another thought; you might be able to achieve this pausing with the 
existing filtering mechanisms (RFC 4661). If you specify a filter that 
basically includes nothing and delivers to you notifications on no 
events, then you'll probably get the same effect as your draft. Have you 
looked at that?

Thanks,
Jonathan R.

Mohammad Vakil wrote:

> BTW, regarding wireless handset example you gave, that usually they
> can poll and not have a subscription is not true. Because processing
> a fetch subscription(expires=0) is equal in cost to processing a
> first subscribe of (expires!=0) on the server. Therefore, it's not
> prudent to poll every 5 sec. There *are* applications where handsets
> do create a persistent subscription to the list of resources.
> Basically, with this optimization what we're allowing is a
> pre-processed subscription on the server, which can be brought back
> to life with un-pause without having to install fresh subscription.
> 
> Besides wireless case, the first use case was about soft clients
> running on PCs in locked mode indicating "away" states. No user is
> looking at the updated states received in that mode, then why not
> save bandwidth and processing on the server.
> 
> 
> -----Original Message----- From: Jonathan Rosenberg
> [mailto:[email-masked]] Sent: Monday, March 12, 2007 8:21 PM To:
> IETF Sipping List Subject: [Sipping] comments on
> draft-vakil-sipping-notify-pause
> 
> The fundamental premise here is that this is an optimization; that
> the cost of terminating a subscription and resubscribing is more than
> the cost of just pausing. I can certainly believe this is true, but
> its not well motivated by the use cases I think.
> 
> active at that endpoint, but still logged into the system.  This idle
> endpoint keeps on receiving unnecessary notifications
> 
> which might be needed for other voice applications, to process these
> unwanted notifications
> 
> tends to create high notification traffic related to the members of
> the list.  This rate increases as the size of the list increases.
> This puts an undue burden on the notifier, to send notification for
> each list element's event state udpate. Therefore, it's preferred to
> simply pause the notifications on the event list subscription
> 
>  use cases are worse for list subscriptions. The first and second
> cases seem the same to me. So its all about this one case of a
> wireless client where the user isn't looking at their screen so why
> bother sending it notifications.
> 
> address book, it would poll for current presence and display that.
> The odds are slim that someones status changes in the 5 seconds you
> are looking at your address book so the poll is good enough.
> 
> handling. I just want to make sure we tackle the right optimizations
> to get the biggest bang for our buck.
> 
> Thanks, Jonathan R.
> 
> -- Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza 
> Cisco Fellow                                   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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 14 Mar 2007 13:47:02 +0100

> events, then you'll probably get the same effect as your draft. Have
> you looked at that?
>

Jonathan,

I had the same thought, one could use RFC4661 to specify an event filter 
that includes nothing (or excludes everything). Problem is that RFC4661 does 
not discuss what happens if the filter results in an empty document, I 
suspect one would end up receiving an empty NOTIFY (or a minimal valid XML 
document, there is room for interpretation here).

So the difference _could_ be: empty NOTIFY versus no NOTIFY at all

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Mar 2007 08:55:45 -0400

> etag, which I think was one of your earlier comments.

Ah! Obviously I didn't read the -etags draft very carefully.

Yes, that seems to provide the needed functionality.

> filtering, as Mohammed suggested.

If every event type had a suitable filter then it does seem that might 
be an alternative to the pause mode. But that would make it more 
cumbersome to poll while paused. You would have to supply a new filter 
to get what you wanted, and then subscribe yet another time to reinstate 
the "pause-filter".

Now perhaps this could be solved by distinguishing between "permanent" 
filters and "one-time" filters, but that would need to be worked out.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Mar 2007 09:04:54 -0400

Jeroen van Bemmel wrote:
> that includes nothing (or excludes everything). Problem is that RFC4661 
> does not discuss what happens if the filter results in an empty 
> document, I suspect one would end up receiving an empty NOTIFY (or a 
> minimal valid XML document, there is room for interpretation here).

I agree things could be clearer on this subject, but I don't think it 
makes sense to send empty notifies for this. The filter determines what 
you are interested in seeing. If there are no changes in that there is 
no purpose in telling you that something you aren't interested in changed.

This is related to notifying only of differences, where again you only 
want to be notified if something you care about has changed. And also to 
permissions, where you are restricted by policy of the notifier about 
what you are allowed to see. That is a sort of mandatory filter. And 
again you wouldn't want to notify that something has changed that the 
subscriber isn't permitted to see.

Using a filter, if there is info that you don't want to see, but do want 
to know has changed, there should be some element that is a 
hash/digest/summary of the info, that will change and cause you to be 
notified. Then you can request expanded info on that if you desire.

	Paul

---

From: "Michael Procter" <[email-masked]>
Date: Wed, 14 Mar 2007 06:12:38 -0700

> to get what you wanted, and then subscribe yet another time to
reinstate

Or you could simply poll out-of-dialog.  There are pros and cons to this
of course, but some applications might find it acceptable.

> filters and "one-time" filters, but that would need to be worked out.

That sounds like a cleaner solution to me.  There is already the
capability to mark a filter as enabled or not.  Marking one as
'one-shot' doesn't seem to be too much of a stretch.

Regards,

Michael

---

From: Mohammad Vakil <[email-masked]>
Date: Wed, 14 Mar 2007 10:30:48 -0700

Yes, I did take a look at all of these drafts, and to add to your list also notify throttling mechanism. No one meets the bar, and I felt, right at the core level (3265), you want some extra functions.

3265 enables:
- creation of persistent subscription
        - starts notification stream
- refresh of existing persistent subscription
        - notification stream continues
- unsubscribe
- one off fetches/polls

It'd be very much beneficial to add the following functions at the root level (3265) regardless of any event package semantic:
- stop the stream, maintain the subscription session
- restart the stream
- polls within an established subscription session (with stopped stream)

Now there're pros and cons, when you try to achieve optimizations with either 4661, subnot-etag, or notify throttling, etc.

- 4661 requires support for XML processing on both sides, where you're trying to reduce the processing with the optimization itself and still doesn't fully address pause (Jeroen and Paul brought up on other thread).

- Notify throttling mechanism requires full support of throttling on the server, where server can only honor 0 rate, and doesn't want to employ buffers to fully throttle, which is heavy on the server.

- Subnot-etag only addresses the subsequent notifications resulting from refreshes and unsubscribes, and not the stream

Thanks,
-Mohammad

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Wednesday, March 14, 2007 4:59 AM
To: Mohammad Vakil
Cc: IETF Sipping List
Subject: Re: [Sipping] comments on draft-vakil-sipping-notify-pause

Thanks,
Jonathan R.

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Thu, 15 Mar 2007 11:19:47 +0100

(As SIP WG chair)

I believe that the predecessors of the simple charter item 

http://www.ietf.org/internet-drafts/draft-ietf-simple-interdomain-scalin
g-analysis-00.txt 

were aware of, and took account of  

Which is a SIP WG charter item.

Therefore I do not believe there is any issue between these two drafts.

I currently have a call out on the SIP WG list as to whether the latter
is ready for WGLC. If you think that other work needs to be taken into
account, then NOW is the time to identify those issues to the SIP WG
list.

Obviously please be specific as to the aspects that need further work.

Regards

Keith

> Sent: Wednesday, March 14, 2007 11:59 AM
> To: Mohammad Vakil
> Cc: IETF Sipping List
> That draft is also about subscription optimizations. This is 
> kind of my worry. We have now many drafts all biting at 
> different parts of the "presence scale" problem:
> 
> I want to make sure we find the right optimizations that 
> cover the largest problem set. Which one is the biggest bang 
> for our buck under which scenarios?
> 
> Another thought; you might be able to achieve this pausing 
> with the existing filtering mechanisms (RFC 4661). If you 
> specify a filter that basically includes nothing and delivers 
> to you notifications on no events, then you'll probably get 
> the same effect as your draft. Have you looked at that?
> 
> Thanks,
> Jonathan R.
> 
> 
> 
> 
> Mohammad Vakil wrote:
> 
> > can poll and not have a subscription is not true. Because 
> processing a 
> > fetch subscription(expires=0) is equal in cost to 
> processing a first 
> > subscribe of (expires!=0) on the server. Therefore, it's 
> not prudent 
> > to poll every 5 sec. There *are* applications where 
> handsets do create 
> > a persistent subscription to the list of resources.
> > pre-processed subscription on the server, which can be 
> brought back to 
> > life with un-pause without having to install fresh subscription.
> > 
> > looking at the updated states received in that mode, then 
> why not save 
> > bandwidth and processing on the server.
> > 
> > 
> > cost of just pausing. I can certainly believe this is true, but its 
> > not well motivated by the use cases I think.
> > 
> > attention to, while wasting over the air bandwidth.  The 
> same wireless 
> > endpoint may also consume processing and battery power, 
> which might be 
> > needed for other voice applications, to process these unwanted 
> > notifications
> > 
> > seem the same to me. So its all about this one case of a wireless 
> > client where the user isn't looking at their screen so why bother 
> > sending it notifications.
> > 
> 07054-2711
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>