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

From: David Viamonte <[email-masked]>
Date: Wed, 06 Sep 2006 09:52:56 +0200

Dear SIMPLE experts,

I am working with OMA Presence and IETF related specifications. I have
a question for which I would appreciate your feedback.

RFC 4662 mandates usage of RLMI in all NOTIFY messages sent in scope of
the subscription to an eventlist.

This means that NOTIFY messages sent by the RLS will contain at least
two bodies: the RLMI summary, and one or more PIDF documents related to
one or more Presentities, respectively. This is particularly true for
NOTIFY messages sent as a consequence of having received a PUBLISH from
a Presence Source.

NOTIFY messages sent as a consequence of a SUBSCRIBE request are more
likely to contain several Presence documents about several
Presentities, due to RLS aggregation.

My point is: NOTIFY messages that are issued by the RLS as a
consequence of a PUBLISH message are quite likely to be larger than
what the same message would have been, had the subscription been an
individual one (e.g.: directly managed by the Presence Server). This is
so because NOTIFY message sent by the RLS contain RLMI+PIDF, while
NOTIFY messages sent by the PS only contain PIDF.

It seems clear to me that, on the other hand, NOTIFY messages sent as a
response to a SUBSCRIBE request are likely to be smaller in the case of
the RLS, due to the RLS aggregation capabilities.

My point is that, for sufficiently lasting subscriptions, most of the
notification traffic would be generated due to Presence Sources
publishing Presence information, rather than due to initial and
refreshed subscriptions.

If this case becomes feasible, I see a potential paradox: the overall
amount of Presence traffic generated by a Watcher subscribing to N
individual Presentities (to the PS) becomes, at some point, smaller
than the overall Presence traffic due to the same Watcher subscribing
once (to the RLS) to an eventlist containing the N Presentities.

This is so because most NOTIFY messages in the second case have to
carry the additional payload (the RLMI data).

I agree that RLS traffic might be mitigated by the RLS Rate Aggregation
capabilities, but if we consider that in general Presence information
has to be received in a quite timely manner, Rate Aggregation becomes

only "relatively" valuable, IMMO.

I also would agree that there are a number of additional optimizations
which you can apply to further reduce traffic, such as notification
filtering, partial notification and even SigComp. However, all these
can be applied both to RLS-generated and to Presence Server-generated
notifications, so they do not impact this discussion.

Could anyone bring some light about this topic and clarify to me what I
may be misunderstanding?

Thanks,

David

--
David Viamonte

Senior Technology Manager
Genaker - eSI Mobile Solutions SLL
http://www.genaker.net
mailto:[email-masked]
mobile:+34-679962309

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Sep 2006 09:14:55 -0400

David,

There may be some validity to your analysis. The details vary a lot 
depending on your assumptions about the characteristics of the traffic. 
For instance, in cases where presence status changes slowly, the traffic 
may be dominated by subscription refreshes and the resulting NOTIFYs.

A quite interesting case is when a user has a lot of buddies, but a 
presence display that can't, or doesn't, show them all at one time. And 
perhaps the ones that are displayed change over time. (Think of a phone 
with limited display real estate, and a scrolling window to check status 
of buddies.) In such a case a subscription to the full buddy list may be 
expensive for the watcher, and also is wasteful in backend subscriptions 
that aren't being noticed. In this case it might be better for the 
watcher to only subscribe to those buddies that are currently being 
displayed, plus maybe a few others that might be viewed with a single UI 
action.

Bottom line is that there are a number of trade offs depending on 
details of the application. One size doesn't fit all. So if 
subscriptions to a list don't work for you, do something else.

	Thanks,
	Paul

David Viamonte wrote:
> Dear SIMPLE experts,
> 
> I am working with OMA Presence and IETF related specifications. I have a 
> question for which I would appreciate your feedback.
> 
> likely to contain several Presence documents about several Presentities, 
> due to RLS aggregation.
> 
> My point is: NOTIFY messages that are issued by the RLS as a consequence 
> of a PUBLISH message are quite likely to be larger than what the same 
> message would have been, had the subscription been an individual one 
> (e.g.: directly managed by the Presence Server). This is so because 
> NOTIFY message sent by the RLS contain RLMI+PIDF, while NOTIFY messages 
> sent by the PS only contain PIDF.
> 
> individual Presentities (to the PS) becomes, at some point, smaller than 
> the overall Presence traffic due to the same Watcher subscribing once 
> (to the RLS) to an eventlist containing the N Presentities.
> 
> This is so because most NOTIFY messages in the second case have to carry 
> the additional payload (the RLMI data).
> 
> filtering, partial notification and even SigComp. However, all these can 
> be applied both to RLS-generated and to Presence Server-generated 
> ------------------------------------------------------------------------
>

---

From: David Viamonte <[email-masked]>
Date: Wed, 06 Sep 2006 15:54:45 +0200

Thanks Paul,

I agree with you: RLS is not a black&white answer to reduce
Presence traffic, and I agree that there are some interesting use cases
as you point out (e.g.: how to optimize Presence traffic when the
device is in idle mode, ...). Thanks for the clarification, as I was
not sure if I was missing something.

I see optimizing
Presence traffic as an
interesting challenge, given the existence of a number of different and
complementary options, which might perform different depending on the
use case on how they are combined together (e.g.: performance of the
RLS vs. setting up large subscription timers)...

Thanks for the answer ;-)

Cheers,

David

David Viamonte

Paul Kyzivat escribió:

David,

There may be some validity to your analysis. The details vary a lot
depending on your assumptions about the characteristics of the traffic.
For instance, in cases where presence status changes slowly, the
traffic may be dominated by subscription refreshes and the resulting
NOTIFYs.

A quite interesting case is when a user has a lot of buddies, but a
presence display that can't, or doesn't, show them all at one time. And
perhaps the ones that are displayed change over time. (Think of a phone
with limited display real estate, and a scrolling window to check
status of buddies.) In such a case a subscription to the full buddy
list may be expensive for the watcher, and also is wasteful in backend
subscriptions that aren't being noticed. In this case it might be
better for the watcher to only subscribe to those buddies that are
currently being displayed, plus maybe a few others that might be viewed
with a single UI action.

Thanks,

Paul

David Viamonte wrote:

Dear SIMPLE experts,

Thanks,

David

--

David Viamonte

http://www.genaker.net

mobile:+34-679962309

Simple mailing list

[email-masked]