JEP-xxxx: Smart Presence Distribution

This document documents the current distribution model for presence and introduces a smart presence distribution strategy to cut down on S2S traffic and load.

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.1
Last Updated: 2006-04-15
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM
Supersedes: None
Superseded By: None
Short Name: Not yet assigned

Author Information

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 following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Table of Contents

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 is already successfully in use with the PSYC (Protocol for SYnchronous Conferencing) [1] as a part of its approach to multicasting.

2. 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 1: Dramatis Personae

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.

3. 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.

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 receivers is computed by the Montague Server based on subscription information in the roster of Romeo.

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)

<presence/> 
      

<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'/>
      

<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'/>
      

5. Smart Unicast Model

This new approach however leaves it to the receiving server to sort out who is to receive the information, thus cutting down on interserver traffic dramatically.

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

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)

This document proposes to extend the 'jabber:server' namespace to allow stanzas not to possess a 'to' attribute also in S2S traffic.

Upon receiving a stanza without 'to' attribute, the receiving server must distribute it to a list of recipients, the local context subscriber list, that is determined based upon the bare JID of the 'from' attribute.

<presence/> 
    

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

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

<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'/>
    

6. Security Considerations

It should be noted that the 'Broad Unicast' model SHOULD limit the size and frequency of presence "broadcasts", otherwise it may be vulnerable to Denial-of-Service attacks.

7. IANA Considerations

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

8. Jabber Registrar Considerations

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

Notes

Revision History

END