Subject: [simple] Discussion about solution(s) for reducing load in the air interface in publishing

From: [email-masked]
Date: Tue, 11 May 2004 12:22:27 +0300

Hi,

I'm resending this using the plain text format instead of the rich text to enhance readability.

BR, Eva
--------------

Hi,

This mail is for discussing the publication requirement concerning partial publications.

The requirement (req10) states that "It must be possible for a PUA to send full presence information (all of the presence information that the PUA knows about a presentity) in a publication, and there should also be a way for PUAs to send partial or incremental presence information."

The issue which the requirement mainly tries to address is to find a mechanism for reducing load and traffic in the air interface, e.g., there is a wireless terminal having a PUA.
 
In order to discuss about the solution in more detail I wanted to provide a more concrete use case:
A presentity's presence information is structured so that it contains several tuples for different communication means.
Most of the tuples contain external objects (e.g. icons describing the status of the communication means). The time for updating the content of the tuples varies depending on the communication mean (=tuple) in question. The presence attributes inside tuples may change.

There seems to be at least three different solutions for this:
1. Using the SIP PUBLISH mechanism in a "clever" way meaning that e.g. inside one client presence information is divided into multiple (virtual) PUAs. The devision can be based on e.g. similar need/time for providing updates or for each tuple there is an own PUA defined. At least tuples which contain large content should be published by separate PUAs.
 
2. Using the SIP PUBLISH and content indirection (CI) mechanisms when large contents are published.

3. Specifying partial publication (PP) mechanism as done for the event notifications
(see a draft proposal in http://www.ietf.org/internet-drafts/draft-lonnfors-simple-partial-publish-00.txt). 

I collected the following aspects which should be considered when thinking about the solution:
- how effectively the solution saves traffic and/or the amount of data in the air interface
- savings in the client and/or terminal implementations
- complexity of the solution (affects e.g. the processing performance).
 
Some initial analysis on the solutions as follows:
 
The problem using the content indirection (2) is that it requires a storage where the content can be stored by a PUA to be supported, and the PA should have access to the storage. If it cannot be assumed that every PA either has a content storage available or is able to access storages provided by PUAs then the content indirection is not suitable for being the only solution.
 
The partial publication (3) requires standardizing new functionality and support for a new content type while the SIP PUBLISH and CI solutions (1 and 2) do not require new standardization effort. It can be said that all the solutions require extra implementation effort. Also the solution 1 requires specific implementation (a kind of multi-PUA PUBLISH system instead of a single PUA system) at the client side. 
 
The number of SIP PUBLISH and response messages will be higher with the SIP PUBLISH solution (1) than with the partial publish and CI. This is because a higher amount of PUAs which each need to handle initial publications, refreshes etc. separately.

When thinking about possible processing savings in the notification side, both the CI (2) and PP (3) help the PA in discovering changed information, and there is no need for the PA to process unchanged information each time when only something has changed.
 
Additionally, the partial publication and CI mechanisms allow deviding tuples into different PUAs to be based on other criterium than the criterion of saving data amount in the air interface. E.g., the criterion could be to have tuples belonging to an application under the same PUA, or there could be only one PUA per a terminal client.> 

Having listed a couple of views and aspects above I'd like to open discussion on the suitable solution(s) and hear your opinnions on which solution is the best and should be selected. My proposal is to continue the work based on the solution 3 (partial publication). 

BR, Eva Leppanen

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