JEP-xxxx: Smart Presence Distribution

This document compares the current distribution model for presence with a new smart presence distribution strategy to cut down on S2S traffic and load, by maintaining a certain amount of state on the receiving side.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <standards-jig@jabber.org> mailing list.


JEP Information

Status: ProtoJEP
Type: Standards Track
Number: xxxx
Version: 0.0.4
Last Updated: 2006-05-19
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM
Supersedes: None
Superseded By: None
Short Name: Not yet assigned

Author Information

Philipp Hancke

Email: fippo@jabber.goes.symlynX.com
JID: fippo@goodadvice.pages.de

Carlo von Loesch

Email: lynX@jabber.getting.psyced.org
JID: lynX@ve.symlynX.com

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (<http://creativecommons.org/licenses/by/2.5/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


Table of Contents

1. Introduction
2. Terminology
3. Example Scenario
4. Broad Unicast Model
4.1. Protocol
5. Smart Unicast Model
5.1. Protocol
5.2. Use Cases for Local Context Recipient List
5.2.1. Adding a Recipient to the List
5.2.2. Deleting a Recipient from the List
5.2.3. Resetting The List
5.2.4. Updating The List
5.2.5. Error on Sender Side
5.2.6. Error on Receiving Side
6. Negotiation
7. Security Considerations
8. Further Application
9. IANA Considerations
10. Jabber Registrar Considerations
Notes
Revision History


1. Introduction

This document describes an optimized strategy of presence delivery called "Smart Unicast" to address the most pressing scalability issues involved with the currently used "Broad Unicast" strategy. The technique described here is inspired by a similar technique used by the PSYC (Protocol for SYnchronous Conferencing) [1] as a part of its approach to multicasting.

2. Terminology

Table 1: Glossary

Unicast Delivery of information to a single destination.
Broadcast Delivery of information to every destination on the network.
Multicast Delivery of information to a group of destinations simultaneously, using the most efficient strategy to deliver messages over each link of the network only once and create clones when the links to the destinations split.
Local Context Recipient List List of local recipients subscribed to a 'Smart Unicast' or in future a 'Multicast' context. In this case the context is the presence information of a sender. The list is computed in different ways depending on the context.
Transmission Error For the purpose of synchronizing the 'Local Context Recipient List', any unexpected error on the virtual circuit (presumably TCP) is to be seen as a transmission error. Also XMPP stream errors are to be considered a transmission error to this purpose, with one exception: A 'connection-timeout' is a normal operation and not to be considered a transmission error.

3. Example Scenario

Upon receiving a presence stanza from a client lacking a 'to' address, the server must distribute this information on behalf of the client. We will first present the characters used in the examples, then show how the same operation of presence distribution is achieved using the old and the new distribution strategies.

Table 2: Dramatis Personae

Name JID Status
Romeo romeo@montague online
Abram, servant of Montague abram@montague online
Balthasar, servant of Montague balthasar@montague offline
Juliet juliet@capulet online, with resources balcony and chamber
Nurse nurse@capulet online
Peter peter@capulet online
Sampson sampson@capulet online
Gregory gregory@capulet online
Anthony anthony@capulet offline
Potpan potpan@capulet offline

Romeo enters the scene and sends his initial presence to all subscribers. At the same time he also probes the presence of his subscribers to obtain an up-to-date buddy list.

4. Broad Unicast Model

In the XMPP specification this strategy is referred to as 'Broadcast Model'. To avoid confusion with other meanings of the term 'broadcast' we prefer to speak of 'Broad Unicast'.

The Montague server fans out a copy of the presence information to each peer, even if more than one peer happens to use the same receiving server.

The list of recipients is computed by the Montague Server based on subscription information in the roster of Romeo filtered by his Privacy Lists configuration.

Note that the Capulet Server already handles distribution to all of Juliets available resources.

Romeo -------> Montague Server ----------> Capulet Server ------> Juliet (balcony)
					   Capulet Server ------> Juliet (chamber)
               Montague Server ----------> Capulet Server ------> Nurse
               Montague Server ----------> Capulet Server ------> Peter
	       Montague Server ----------> Capulet Server ------> Sampson
               Montague Server ----------> Capulet Server ------> Gregory
               Montague Server ----------> Capulet Server (Anthony is offline)
               Montague Server ----------> Capulet Server (Potpan is offline)
               Montague Server ----> Abram
               Montague Server (Balthasar is offline)

4.1 Protocol

Example 1. Client sends presence without "to" attribute

<presence/> 
      

Example 2. Local server distributes on behalf of the client

<presence from='romeo@montague/inlove' to='juliet@capulet'/>
<presence from='romeo@montague/inlove' to='juliet@capulet' type='probe'/>
<presence from='romeo@montague/inlove' to='nurse@capulet'/>
<presence from='romeo@montague/inlove' to='nurse@capulet' type='probe'/>
<presence from='romeo@montague/inlove' to='peter@capulet'/>
<presence from='romeo@montague/inlove' to='peter@capulet' type='probe'/>
<presence from='romeo@montague/inlove' to='sampson@capulet'/>
<presence from='romeo@montague/inlove' to='sampson@capulet' type='probe'/>
<presence from='romeo@montague/inlove' to='gregory@capulet'/>
<presence from='romeo@montague/inlove' to='gregory@capulet' type='probe'/>
<presence from='romeo@montague/inlove' to='anthony@capulet'/>
<presence from='romeo@montague/inlove' to='anthony@capulet' type='probe'/>
<presence from='romeo@montague/inlove' to='potpan@capulet'/>
<presence from='romeo@montague/inlove' to='potpan@capulet' type='probe'/>
<presence from='romeo@montague/inlove' to='abram@montague'/>
      

And it replies to the local probe queries as appropriate.

Example 3. Capulet Server proxies the packets

<presence from='romeo@montague/inlove' to='juliet@capulet'/> (to balcony resource)
<presence from='romeo@montague/inlove' to='juliet@capulet'/> (to chamber resource)
<presence from='romeo@montague/inlove' to='nurse@capulet'/>
<presence from='romeo@montague/inlove' to='peter@capulet'/>
<presence from='romeo@montague/inlove' to='sampson@capulet'/>
<presence from='romeo@montague/inlove' to='gregory@capulet'/>
      

And it replies to its local probe queries as appropriate.

5. Smart Unicast Model

This new approach teaches the receiving servers to memorize who has received presence information and is to receive it again, thus cutting down on interserver traffic.

It requires that first a fan out according to the 'Broad Unicast' model has taken place. During that operation the receiving servers now additionally MUST create a list of recipients they were asked to forward a sender's presence to. After that, the list can be used for the 'Smart Unicast Model' as follows.

In the example, the Montague Server sends a single presence to the Capulet Server, which is then distributed based on the subscription information in the newly created list.

Romeo -------> Montague Server ----------> Capulet Server ------> Juliet (balcony)
					   Capulet Server ------> Juliet (chamber)
			                   Capulet Server ------> Nurse
                                           Capulet Server ------> Peter
                                           Capulet Server ------> Sampson
                                           Capulet Server ------> Gregory
			                   Capulet Server (Anthony is offline)
			                   Capulet Server (Potpan is offline)
               Montague Server ---> Abram
               Montague Server (Balthasar is offline)

5.1 Protocol

Upon receiving a presence stanza with one of its domain names in the 'to' attribute, the receiving server must distribute it to the 'Local Context Recipient List', determined by a preceding 'Broad Unicast' or other operations detailed in the use cases below.

Example 4. Client sends presence without "to" attribute

<presence/> 
    

Example 5. Local server distributes to online local clients

<presence from='romeo@montague/inlove' to='abram@montague'/>
    

The local messages are delivered and probes responded to as before.

Example 6. Local server distributes to involved servers

<presence from='romeo@montague/inlove' to='capulet/route'/>
<presence from='romeo@montague/inlove' to='capulet/route' type='probe'/>
    

But from now on only one copy of the message is sent to each remote servers. Upon receiving this stanza, the capulet server then uses the 'Local Context Recipient List' to distribute the information to its subscribers.

Example 7. Remote server distributes each packet to those subscribers which are online

<presence from='romeo@montague/inlove' to='juliet@capulet'/> (to balcony resource)
<presence from='romeo@montague/inlove' to='juliet@capulet'/> (to chamber resource)
<presence from='romeo@montague/inlove' to='nurse@capulet'/>
<presence from='romeo@montague/inlove' to='peter@capulet'/>
<presence from='romeo@montague/inlove' to='sampson@capulet'/>
<presence from='romeo@montague/inlove' to='gregory@capulet'/>
    

It also replies to the probe query for each of its subscribers.

5.2 Use Cases for Local Context Recipient List

For each remote sender transmitting presence information, the receiving server MUST create an empty 'Local Context Recipient List'.

5.2.1 Adding a Recipient to the List

When receiving a presence stanza without "type" attribute, the recipient joins the sender's list, given he has a subscription of "to" or "both".

5.2.2 Deleting a Recipient from the List

When receiving a presence stanza of type "unavailable", the recipient leaves the sender's list.

5.2.3 Resetting The List

The reception of a 'Smart Unicast' presence of type 'unavailable' MUST also clear the current list of recipients on the receiving side for this presence sender. Therefore the next presence update must be a series of targeted unicast presence updates, or a 'Broad Unicast' to populate the sender's list again, which to the receiving server look the same.

Example 8. List is to be reset on receiving side

<presence from='romeo@montague/inlove' to='capulet/route' type='unavailable'/>
    

5.2.4 Updating The List

In case a change happens in the configuration of the recipients, the sender can update the list of the involved servers by first resetting the list as defined in the paragraph above, then sending a series of presence notifications, which will populate the list again.

5.2.5 Error on Sender Side

When a transmission error is detected on the sending side, the sender must presume the state on the receiving side is no longer safe and SHOULD initiate an update as defined above.

5.2.6 Error on Receiving Side

Should the receiving side detect a transmission error, it SHOULD delete its list. It may also lose its list due to any other kind of technical problem.

On receiption of a 'Smart Unicast' without a list in place, it SHOULD return a <service-unavailable/> error to the sender. The sender MAY then execute an update as defined in the paragraph above, which will both re-transmit the presence to the intended recipient and restore the recipient list.

6. Negotiation

This protocol MUST be negotiated between parties willing to optimize traffic. A stream feature negotiation is appropriate. During such a negotiation the resource name is agreed upon, which in this example was 'route'.

7. Security Considerations

Both models respect the often requested requirement, that the sender should always be in charge of specifying who is to receive the messages.

8. Further Application

The 'Smart Unicast' model can be applied to any one-to-many communication, such as Multi-User Chat [2] and Publish-Subscribe [3]. Inspecting these options is however beyond the scope of this document and will be addressed in future documents.

9. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [4].

10. Jabber Registrar Considerations

This JEP requires no interaction with the Jabber Registrar [5].


Notes

1. PSYC (Protocol for SYnchronous Conferencing) is a distributed chat and messaging protocol which was designed with elaborate multicast distribution strategies in mind. For further information, see <http://www.psyc.eu>.

2. JEP-0045: Multi-User Chat <http://www.jabber.org/jeps/jep-0045.html>.

3. JEP-0060: Publish-Subscribe <http://www.jabber.org/jeps/jep-0060.html>.

4. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

5. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.


Revision History

Version 0.0.4 (2006-05-19)

We no longer use the roster to define who is to receive our presence. Instead we recommend to send the first presence by the regular 'broad unicast', asking the receiving servers to cache whom they relayed presence to, then send by 'smart unicast' expecting the receiving servers to simply re-use the list created by the initial fan out.

(cvl)

Version 0.0.3 (2006-05-11)

Juliet gets a second resource.

(ph)

Version 0.0.2 (2006-04-21)

2nd draft.

(cvl)

Version 0.0.1 (2006-04-15)

First draft.

(ph)


END