Subject: [Simple] Comments on SIMPLE problem statement and TR on scaling Presence wrt Content Indirection

From: David Viamonte <[email-masked]>
Date: Wed, 22 Nov 2006 14:03:09 +0100

Dear SIMPLE experts,

Following up on this topic, I would like to ask if there is any agreed
position at the SIMPLE WG wrt application of Content Indirection to
SIMPLE Presence publications / notifications (e.g.: RFC 4483).

I have seen there is no reference to this topic in the "Scaling
Presence" report (http://mice.cs.columbia.edu/getTechreport.php?techreportID=426).

In http://www.ietf.org/internet-drafts/draft-rang-simple-problem-statement-01.txt
a reference is made, although the mechanism is questioned due to a
couple of issues (which I comment below). Since this mechanism would
seem -at first sight- as a good and simple baseline to reduce Presence
traffic, I would like to get some feedback from the experts to
understand the technical reasons why this is currently not in scope of
the Presence optimizations discussions (maybe it is implicitly
considered, or disregarded for some reason I am missing?). Any feedback
and light on this will be appreciated ;-)

Now, regarding the reference to Content Indirection in section 7.2 of "draft-rang-simple-problem-statement-01", I would like to make some additional
comment, and I will appreciate any feedback about them:

"This optimization may be useful in some cases
but in reality it may have several drawbacks:

1. Due to partial/privacy/filtering and other functionalities, it will
be relatively a rare case where many watchers will get exactly the same
presence document".

I agree that partial/privacy/filtering mechanisms
diminish the effectiveness of Content Indirection. However, I do not
see the case of several watchers getting the same Presence document as
an extremely "rare case". If we consider Privacy, for example, a
Presence Source may have 2-4 different privacy profiles for its
subscribed watchers, but I do not expect having an extremely tailored
Presence document for each and every potential Watcher out there. This
is simply by applying common sense: I do not expect users being able to
manage their Privacy settings in an extremely complex manner
(particularly from wireless devices), so I would expect maybe three
different spheres: professional, family, friends... or something like
this.

I don't mean that things "will be" like I say in the previous
paragraph, but I also don't see why the Problem Statement I-D should
assume the opposite case. If I take common Messaging / Presence / VoIP
tools on the Internet, I think the common trend is using very simple
policies wrt to Privacy ("Show / Hide my Presence to User X"), and this
behaviour still provides a lot of value to end users, so I don't see
why we should assume that SIMPLE Presence should behave in an extremely
more complex manner...

Consider a
not-so-conservative
case: a Presentity has 25 subscribed Watchers, for which it defines
four different spheres (family, friends, work, default). In such case,
Content Indirection would help to reduce the amount of PIDF information
exchanged across domains by 84% (21/25), as only four docs would be
downloaded and reused for the four different types of Watchers (SIP
overhead remains the same). This
applies to (re-)subscriptions and real notifications.

Observe that Partial / Filtering mechanisms can be managed directly by
the RLS (once the PS has already applied Privacy, since the PS is -for
the time being- the one that knows the Privacy settings of the
Presentity). So once Privacy is applied, a common document can be
exchanged across domains for each different Privacy setting, and the
RLS may further process the Presence document to deliver tailored
versions of it to its Watchers. If we apply content indirection to the
RLS - PS path, we would significantly reduce the amount of PIDF/RPID
payload exchanged between the RLS and the PS.

"2. There should be a mechanism that will enable removing the content
from the content server at the appropriate time. Defining the
appropriate time is far from trivial since the removal should be
synchronized with all the watcher that need to get the content."

I agree this should be thought a bit deeper. Two comments on this, though:

- Once a NOTIFY with a URL has been sent, the Presence document may not
need to be removed until a subsequent Presence update is received.
Thus, no need arises to calculate "when" a Presence document should be
removed. Simply, when the next Presence update is received, that
document will be obsoleted, and a new NOTIFY with a new link (including
something like an ETag) will be sent. This gives enough time to any RLS
to retrieve the document, and does not pose any additional security
threat (pending further analysis), as the same information is available
via Content Indirection, as it would be via a regular NOTIFY message.

- I do agree that additional authorization mechanisms may be required
to implement this function. This is because if the URL is static across
publications of the same Presentity, an RLS (or even a Watcher) could
keep trying to retrieve the document even if its subscription has
expired or has been cancelled, if the HTTP "leg" is not secured someway
(HTTPs?). Thus, I think that some sort of combination of Content
Indirection + Authorization is required, to avoid security holes, but I
don't see this issue as something un-workable...

Sorry for this long mail. I would appreciate any
feedback on this, as I would like to understand whether it is wise or
stupid to still consider Content Indirection as a potentially good
mechanism to further reduce Presence traffic (e.g.: across domains).
Obviously, this would not be in any manner against to other well-known
mechanisms being discussed in this list.

Thanks for any feedback. Hope the above comments are useful for some of
the currently ongoing discussions.

Kind regards,

David

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