Subject: Re: [Simple] When does RLS reduce Presence traffic?

From: "Beck01, Wolfgang" <[email-masked]>
Date: Thu, 7 Sep 2006 13:45:46 +0200

Avshalom wrote:
> 
> The following doc may be relevant 
> 
> http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-00.txt 
> 
The paper tells the bitter truth. While we have put a lot of effort to keep state
out of ordinary SIP signalling, we now have to deal with massive stateful presence
servers. Due to its nature, we cant keep the state complete out of the network
(as long as we dont use p2p approaches). We can either put intelligence into the servers
to reduce the number of subscribe, publish, and notify messages: RLS and URI lists.
Or we can try to minimize the load per subscription, by using only reginfo in the network
and moving more complex presence features into the end device.

Wolfgang

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Aki Niemi <[email-masked]>
Date: Mon, 11 Sep 2006 12:20:10 +0300

> and moving more complex presence features into the end device.

Another option to reduce the number of messages is to use subnot-etags:

http://www.ietf.org/internet-drafts/draft-niemi-sip-subnot-etags-01.txt

Cheers,
Aki

---

From: <[email-masked]>
Date: Wed, 13 Sep 2006 10:16:53 +0300

Hi,

Would it be useful to write some kind of BCP on the mechanisms to reduce
presence traffic in case the UAs are using low-capacity access networks
or there are some other reasons for doing it? There are plenty of
different ways specified/proposed already:

- Resource List Service
- subnot-etags
- filtering
- partial notify/publish
- throttling
- Presence specific sigcomp dictionary

For some reason people have been very reluctant to let some of these
progress in the IETF. Fortunately the partial notify/publish stuff is
now finally in AD review, but for instance throttling (franky a trivial
thing compared to a lot of other things) has been around forever and not
moving forward, and even the sub/not etag draft is still just an
individual submission.

Markus

>-----Original Message-----
>From: ext Aki Niemi [mailto:[email-masked]] 
>Sent: 11 September, 2006 12:20
>To: ext Beck01, Wolfgang
>Cc: [email-masked]
>Subject: Re: [Simple] When does RLS reduce Presence traffic?
>
>> The paper tells the bitter truth. While we have put a lot of 
>effort to 
>> keep state out of ordinary SIP signalling, we now have to deal with 
>> massive stateful presence servers. Due to its nature, we 
>cant keep the 
>> state complete out of the network (as long as we dont use p2p 
>> approaches). We can either put intelligence into the servers 
>> Or we can try to minimize the load per subscription, by using only 
>> reginfo in the network and moving more complex presence 
>features into the end device.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Sep 2006 11:12:01 -0400

I think this topic in general about optimizations is exactly what we 
need to be working on here in the simple group. This is why I liked the 
rang problem-statement draft; it put some context down and set the stage 
for requirements for this work. And thats where we need to start - which 
  aspects of the performance do we really need to optimize and why?

-Jonathan R.

[email-masked] wrote:

>>http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statem
>>
>>>>ent-00.txt
>>>>
>>>

-- 
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

---

From: Avshalom Houri <[email-masked]>
Date: Fri, 15 Sep 2006 18:31:43 +0300

Hope to have new version in mid October.
Any requirements/suggestions will be helpful.

Initial list of topics that I think should be added to the draft:

* State management analysis - How much state will be required
   by the presence server etc.
* (Jonathan) Analyze how much better it can get. I.e, for the various
   configurations, what is the optimal that any protocol could do in order
   to convey the same information?
* (Markus) Look into usage of dictionary for presence

--Avshalom

Jonathan Rosenberg <[email-masked]> 
15/09/2006 18:12

To
[email-masked]
cc
[email-masked], [email-masked]
Subject
Re: [Simple] When does RLS reduce Presence traffic?

-Jonathan R.

---

From: David Viamonte <[email-masked]>
Date: Fri, 15 Sep 2006 18:37:39 +0200

Hi,

One question for my understanding: is your I-D focusing on interdomain
Presence or you aim at generic BCP as well?

As a triggerer of this thread :-) I like the BCP idea (read some
general comments below) and would like to be involved there as well.

A couple of comments about trying to find "universal" Presence
optimizations:

1. Is there a
sufficiently general
set of requirements which can be assumed for all environments? (e.g.:
depending on what the requirement is, some enhancements may or may not
apply. A clear example is throttling, which has a direct dependency on
how timely Presence information must be available at the Watcher
application).

2. The performance of some mechanisms (at least the RLS) is
highly dependant on user behavior and traffic patterns (e.g.: how many
entries in the contact list, frequency of the Presence updates, ...).
Additionally, some mechanisms may have cross-linked dependencies with
others (e.g.: RLS performance vs. Subscription Timers). Therefore, the
BCP should be general enough to ensure good
performance in a wide range of circumstances (this may imply
sub-optimal performance in some cases).

I have made some investigation
further about when an RLS is more effective than the PS (based on
frequency of updates, subscription times, ...), so would be happy to
contribute there.

Kind regards,

David

David Viamonte

Senior Technology Manager
Genaker - eSI Mobile Solutions SLL
http://www.genaker.net

mailto:[email-masked]
mobile:+34-679962309

Avshalom Houri escribió:

Hope to have new version in mid
October.

Any requirements/suggestions will
be
helpful.

Initial list of topics that I think
should be added to the draft:

* State management analysis - How
much
state will be required

by the presence server
etc.

* (Jonathan) Analyze how much
better
it can get. I.e, for the various

configurations, what is
the optimal that any protocol could do in order

* (Markus) Look into usage of
dictionary
for presence

--Avshalom

Jonathan
Rosenberg <[email-masked]>

15/09/2006 18:12

To

[email-masked]

cc

[email-masked],
[email-masked]

Subject

Re: [Simple] When
does RLS reduce Presence
traffic?

I think this topic in general about optimizations
is exactly what we

rang problem-statement draft; it put some context down and set the
stage

for requirements for this work. And thats where we need to start -
which

-Jonathan R.

> thing compared to a lot of other things) has been around forever
and
not

>>>keep state out of ordinary SIP signalling, we now have to
deal
with

>>to reduce the number of subscribe, publish, and notify

>>messages: RLS and URI lists.

>>>Or we can try to minimize the load per subscription, by
using
only

--

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

Simple mailing list

[email-masked]