|
List Info
Thread: When does RLS reduce Presence traffic?
|
|
| When does RLS reduce Presence traffic? |
|
2006-09-07 11:45:46 |
Avshalom wrote:
>
> The following doc may be relevant
>
> http://www.ietf.org/internet-draft
s/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
Simple ietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|
|
| When does RLS reduce Presence traffic? |
|
2006-09-11 09:20:10 |
to, 2006-09-07 kello 13:45 +0200, ext Beck01, Wolfgang
kirjoitti:
> Avshalom wrote:
> >
> > The following doc may be relevant
> >
> > http://www.ietf.org/internet-draft
s/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.
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
_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|
|
| When does RLS reduce Presence traffic? |
|
2006-09-13 07:16:53 |
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:aki.nieminokia.com]
>Sent: 11 September, 2006 12:20
>To: ext Beck01, Wolfgang
>Cc: simpleietf.org
>Subject: Re: [Simple] When does RLS reduce Presence
traffic?
>
>to, 2006-09-07 kello 13:45 +0200, ext Beck01, Wolfgang
kirjoitti:
>> Avshalom wrote:
>> >
>> > The following doc may be relevant
>> >
>> >
>http://www.ietf.org/internet-drafts/draft-ra
ng-simple-problem-statem
>> > ent-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.
>
>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
>
>
>_______________________________________________
>Simple mailing list
>Simpleietf.org
>https:/
/www1.ietf.org/mailman/listinfo/simple
>
_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|
|
| When does RLS reduce Presence traffic? |
|
2006-09-15 15:12:01 |
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.
Markus.Isomakinokia.com wrote:
> 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:aki.nieminokia.com]
>>Sent: 11 September, 2006 12:20
>>To: ext Beck01, Wolfgang
>>Cc: simpleietf.org
>>Subject: Re: [Simple] When does RLS reduce Presence
traffic?
>>
>>to, 2006-09-07 kello 13:45 +0200, ext Beck01,
Wolfgang kirjoitti:
>>
>>>Avshalom wrote:
>>>
>>>>The following doc may be relevant
>>>>
>>>>
>>
>>http://www.ietf.org/internet-drafts/draft-ra
ng-simple-problem-statem
>>
>>>>ent-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.
>>
>>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
>>
>>
>>_______________________________________________
>>Simple mailing list
>>Simpleietf.org
>>https:/
/www1.ietf.org/mailman/listinfo/simple
>>
>
>
> _______________________________________________
> Simple mailing list
> Simpleietf.org
> https:/
/www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex
Plaza
Cisco Fellow Parsippany,
NJ 07054-2711
Cisco Systems
jdrosencisco.com FAX: (973)
952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|
|
| When does RLS reduce Presence traffic? |
|
2006-09-15 15:12:01 |
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.
Markus.Isomakinokia.com wrote:
> 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:aki.nieminokia.com]
>>Sent: 11 September, 2006 12:20
>>To: ext Beck01, Wolfgang
>>Cc: simpleietf.org
>>Subject: Re: [Simple] When does RLS reduce Presence
traffic?
>>
>>to, 2006-09-07 kello 13:45 +0200, ext Beck01,
Wolfgang kirjoitti:
>>
>>>Avshalom wrote:
>>>
>>>>The following doc may be relevant
>>>>
>>>>
>>
>>http://www.ietf.org/internet-drafts/draft-ra
ng-simple-problem-statem
>>
>>>>ent-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.
>>
>>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
>>
>>
>>_______________________________________________
>>Simple mailing list
>>Simpleietf.org
>>https:/
/www1.ietf.org/mailman/listinfo/simple
>>
>
>
> _______________________________________________
> Simple mailing list
> Simpleietf.org
> https:/
/www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D. 600 Lanidex
Plaza
Cisco Fellow Parsippany,
NJ 07054-2711
Cisco Systems
jdrosencisco.com FAX: (973)
952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
|
|
| When does RLS reduce Presence traffic? |
|
2006-09-15 15:31:43 |
|
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 <jdrosencisco.com>
15/09/2006 18:12
|
|
To
| Markus.Isomakinokia.com
|
cc
| simpleietf.org, aki.nieminokia.com
|
Subject
Re: [Simple] When does RLS reduce Presence
traffic? | | | |
|
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.
Markus.Isomakinokia.com wrote:
> 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:aki.nieminokia.com]
>>Sent: 11 September, 2006 12:20
>;>To: ext Beck01, Wolfgang
>>Cc: simpleietf.org
>>Subject: Re: [Simple] When does RLS reduce Presence traffic?
>>
>>to, 2006-09-07 kello 13:45 +0200, ext Beck01, Wolfgang kirjoitti:
>>
>>>Avshalom wrote:
>>>
>>>>The following doc may be relevant
>>>;>
>>>>;
>>
>>http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statem
>>
>>>>ent-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.
>>
>>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
>>;
>>
>>_______________________________________________
>>;Simple mailing list
>>Simpleietf.org
>>https://www1.ietf.org/mailman/listinfo/simple
>>
>
>
> _______________________________________________
> Simple mailing list
> Simpleietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D.
600 Lanidex Plaza
Cisco Fellow
Parsippany, NJ
07054-2711
Cisco Systems
jdrosencisco.com
FAX: (973) 952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
Simpleietf.org
https://www1.ietf.org/mailman/listinfo/simple
|
| When does RLS reduce Presence traffic? |
|
2006-09-15 16:37:39 |
|
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
genaker.net">mailto:david.viamontegenaker.net
mobile:+34-679962309
Avshalom Houri escribió:
il.ibm.com"
type="cite">
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
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.
nokia.com">Markus.Isomakinokia.com wrote:
> 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 [nokia.com">mailto:aki.nieminokia.com]
>>Sent: 11 September, 2006 12:20
>;>To: ext Beck01, Wolfgang
>>Cc: ietf.org">simpleietf.org
>>Subject: Re: [Simple] When does RLS reduce Presence traffic?
>>
>>to, 2006-09-07 kello 13:45 +0200, ext Beck01, Wolfgang
kirjoitti:
>>
>>>Avshalom wrote:
>>>
>>>>The following doc may be relevant
>>>;>
>>>>;
>>
>>http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statem
>>
>>>>ent-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.
>>
>>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
>>
>>;
>>_______________________________________________
>>Simple mailing list
>>ietf.org">Simpleietf.org
>>https://www1.ietf.org/mailman/listinfo/simple
>>
>
>
> _______________________________________________
> Simple mailing list
> ietf.org">Simpleietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D.
600 Lanidex Plaza
Cisco Fellow
Parsippany, NJ
07054-2711
Cisco Systems
cisco.com">jdrosencisco.com
FAX: (973) 952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
ietf.org">Simpleietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
ietf.org">Simpleietf.org
https://www1.ietf.org/mailman/listinfo/simple
|
| When does RLS reduce Presence traffic? |
|
2006-09-15 15:31:43 |
|
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 <jdrosencisco.com>
15/09/2006 18:12
|
|
To
| Markus.Isomakinokia.com
|
cc
| simpleietf.org, aki.nieminokia.com
|
Subject
Re: [Simple] When does RLS reduce Presence
traffic? | | | |
|
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.
Markus.Isomakinokia.com wrote:
> 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:aki.nieminokia.com]
>>Sent: 11 September, 2006 12:20
>;>To: ext Beck01, Wolfgang
>>Cc: simpleietf.org
>>Subject: Re: [Simple] When does RLS reduce Presence traffic?
>>
>>to, 2006-09-07 kello 13:45 +0200, ext Beck01, Wolfgang kirjoitti:
>>
>>>Avshalom wrote:
>>>
>>>>The following doc may be relevant
>>>;>
>>>>;
>>
>>http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statem
>>
>>>>ent-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.
>>
>>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
>>;
>>
>>_______________________________________________
>>;Simple mailing list
>>Simpleietf.org
>>https://www1.ietf.org/mailman/listinfo/simple
>>
>
>
> _______________________________________________
> Simple mailing list
> Simpleietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D.
600 Lanidex Plaza
Cisco Fellow
Parsippany, NJ
07054-2711
Cisco Systems
jdrosencisco.com
FAX: (973) 952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
Simpleietf.org
https://www1.ietf.org/mailman/listinfo/simple
|
| When does RLS reduce Presence traffic? |
|
2006-09-15 16:37:39 |
|
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
genaker.net">mailto:david.viamontegenaker.net
mobile:+34-679962309
Avshalom Houri escribió:
il.ibm.com"
type="cite">
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
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.
nokia.com">Markus.Isomakinokia.com wrote:
> 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 [nokia.com">mailto:aki.nieminokia.com]
>>Sent: 11 September, 2006 12:20
>;>To: ext Beck01, Wolfgang
>>Cc: ietf.org">simpleietf.org
>>Subject: Re: [Simple] When does RLS reduce Presence traffic?
>>
>>to, 2006-09-07 kello 13:45 +0200, ext Beck01, Wolfgang
kirjoitti:
>>
>>>Avshalom wrote:
>>>
>>>>The following doc may be relevant
>>>;>
>>>>;
>>
>>http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statem
>>
>>>>ent-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.
>>
>>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
>>
>>;
>>_______________________________________________
>>Simple mailing list
>>ietf.org">Simpleietf.org
>>https://www1.ietf.org/mailman/listinfo/simple
>>
>
>
> _______________________________________________
> Simple mailing list
> ietf.org">Simpleietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D.
600 Lanidex Plaza
Cisco Fellow
Parsippany, NJ
07054-2711
Cisco Systems
cisco.com">jdrosencisco.com
FAX: (973) 952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
ietf.org">Simpleietf.org
https://www1.ietf.org/mailman/listinfo/simple
_______________________________________________
Simple mailing list
ietf.org">Simpleietf.org
https://www1.ietf.org/mailman/listinfo/simple
|
| When does RLS reduce Presence traffic? |
|
2006-09-15 15:31:43 |
|
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 <jdrosencisco.com>
15/09/2006 18:12
|
|
To
| Markus.Isomakinokia.com
|
cc
| simpleietf.org, aki.nieminokia.com
|
Subject
Re: [Simple] When does RLS reduce Presence
traffic? | | | |
|
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.
Markus.Isomakinokia.com wrote:
> 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:aki.nieminokia.com]
>>Sent: 11 September, 2006 12:20
>;>To: ext Beck01, Wolfgang
>>Cc: simpleietf.org
>>Subject: Re: [Simple] When does RLS reduce Presence traffic?
>>
>>to, 2006-09-07 kello 13:45 +0200, ext Beck01, Wolfgang kirjoitti:
>>
>>>Avshalom wrote:
>>>
>>>>The following doc may be relevant
>>>;>
>>>>;
>>
>>http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statem
>>
>>>>ent-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.
>>
>>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
>>;
>>
>>_______________________________________________
>>;Simple mailing list
>>Simpleietf.org
>>https://www1.ietf.org/mailman/listinfo/simple
>>
>
>
> _______________________________________________
> Simple mailing list
> Simpleietf.org
> https://www1.ietf.org/mailman/listinfo/simple
>
--
Jonathan D. Rosenberg, Ph.D.
600 Lanidex Plaza
Cisco Fellow
Parsippany, NJ
07054-2711
Cisco Systems
jdrosencisco.com
FAX: (973) 952-5050
http://www.jdrosen.net
PHONE: (973) 952-5000
http://www.cisco.com
_______________________________________________
Simple mailing list
Simpleietf.org
https://www1.ietf.org/mailman/listinfo/simple
|
[1-10]
|
|