[Standards-JIG] proto-JEP: Smart Presence Distribution

Carlo v. Loesch CvL at mail.symlynX.com
Wed May 24 07:53:44 UTC 2006


In an effort to produce a proposal that will satisfy the requirements of
everyone on standards-jig, Philipp came up with a different strategy on
how to distribute presence without handing out control to remote servers,
without relying on remote rosters and without defeating privacy lists. 

The new proto-JEP has been updated on
	http://www.jabber.org/jeps/inbox/smartpresence.html
and
	http://smarticast.psyced.org/jep-smart-presence.html

For the convenience of citing the proto-JEP directly in an e-mail
discussion I have included a text rendering of it below.


-------------------------------------------------------------------------------

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 at 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

Philipp Hancke

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

Carlo von Loesch

Email: lynX at jabber.getting.psyced.org
JID: lynX at 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. |
|--------------+--------------------------------------------------------------|
|              | Delivery of information to a group of destinations           |
|  Multicast   | 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     | List of local recipients subscribed to a 'Smart Unicast' or  |
|   Context    | in future a 'Multicast' context. In this case the context is |
|  Recipient   | the presence information of a sender. The list is computed   |
|     List     | in different ways depending on the context.                  |
|--------------+--------------------------------------------------------------|
|              | For the purpose of synchronizing the 'Local Context          |
|              | Recipient List', any unexpected error on the virtual circuit |
| Transmission | (presumably TCP) is to be seen as a transmission error. Also |
|    Error     | 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 at montague     | online                         |
|-----------------------+--------------------+--------------------------------|
| Abram, servant of     | abram at montague     | online                         |
| Montague              |                    |                                |
|-----------------------+--------------------+--------------------------------|
| Balthasar, servant of | balthasar at montague | offline                        |
| Montague              |                    |                                |
|-----------------------+--------------------+--------------------------------|
| Juliet                | juliet at capulet     | online, with resources balcony |
|                       |                    | and chamber                    |
|-----------------------+--------------------+--------------------------------|
| Nurse                 | nurse at capulet      | online                         |
|-----------------------+--------------------+--------------------------------|
| Peter                 | peter at capulet      | online                         |
|-----------------------+--------------------+--------------------------------|
| Sampson               | sampson at capulet    | online                         |
|-----------------------+--------------------+--------------------------------|
| Gregory               | gregory at capulet    | online                         |
|-----------------------+--------------------+--------------------------------|
| Anthony               | anthony at capulet    | offline                        |
|-----------------------+--------------------+--------------------------------|
| Potpan                | potpan at 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 at montague/inlove' to='juliet at capulet'/>
<presence from='romeo at montague/inlove' to='juliet at capulet' type='probe'/>
<presence from='romeo at montague/inlove' to='nurse at capulet'/>
<presence from='romeo at montague/inlove' to='nurse at capulet' type='probe'/>
<presence from='romeo at montague/inlove' to='peter at capulet'/>
<presence from='romeo at montague/inlove' to='peter at capulet' type='probe'/>
<presence from='romeo at montague/inlove' to='sampson at capulet'/>
<presence from='romeo at montague/inlove' to='sampson at capulet' type='probe'/>
<presence from='romeo at montague/inlove' to='gregory at capulet'/>
<presence from='romeo at montague/inlove' to='gregory at capulet' type='probe'/>
<presence from='romeo at montague/inlove' to='anthony at capulet'/>
<presence from='romeo at montague/inlove' to='anthony at capulet' type='probe'/>
<presence from='romeo at montague/inlove' to='potpan at capulet'/>
<presence from='romeo at montague/inlove' to='potpan at capulet' type='probe'/>
<presence from='romeo at montague/inlove' to='abram at montague'/>
      

And it replies to the local probe queries as appropriate.

Example 3. Capulet Server proxies the packets

<presence from='romeo at montague/inlove' to='juliet at capulet'/> (to balcony resource)
<presence from='romeo at montague/inlove' to='juliet at capulet'/> (to chamber resource)
<presence from='romeo at montague/inlove' to='nurse at capulet'/>
<presence from='romeo at montague/inlove' to='peter at capulet'/>
<presence from='romeo at montague/inlove' to='sampson at capulet'/>
<presence from='romeo at montague/inlove' to='gregory at 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 at montague/inlove' to='abram at montague'/>
    

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

Example 6. Local server distributes to involved servers

<presence from='romeo at montague/inlove' to='capulet/route'/>
<presence from='romeo at 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 at montague/inlove' to='juliet at capulet'/> (to balcony resource)
<presence from='romeo at montague/inlove' to='juliet at capulet'/> (to chamber resource)
<presence from='romeo at montague/inlove' to='nurse at capulet'/>
<presence from='romeo at montague/inlove' to='peter at capulet'/>
<presence from='romeo at montague/inlove' to='sampson at capulet'/>
<presence from='romeo at montague/inlove' to='gregory at 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 at 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.1 (2006-04-15)

First draft.

(ph)

Version 0.0.2 (2006-04-21)

2nd draft.

(cvl)

Version 0.0.3 (2006-05-11)

Juliet gets a second resource.

(ph)

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)

-------------------------------------------------------------------------------

-- 
» Carlo v. Loesch » http://symlynX.com » psyc://ve.symlynX.com/~lynX
	    xmpp:lynX at ve.symlynX.com » irc://ve.symlynX.com/#symlynX
        CryptoChat » https://ve.symlynX.com:34443/LynX/?room=symlynX
network chat technology since 1988. no joke.  » tel:+49/30/6950-8782



More information about the Standards mailing list