[Standards-JIG] Multicast JEPs in the making

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Wed May 17 15:15:12 UTC 2006

Hello there, 

You just have to convince the list that your findings are bringing all the
advantages you mentioned in your nice message. We are all ears. 

I myself would be particularly interested by some metrics about the
scalability you have achieved with your prototype. 

Looking forward to it then.


P.S. What is "your IETF experience" btw?

-----Original Message-----
Message: 4
Date: Wed, 17 May 2006 09:23:52 +0200 (CEST)
From: CvL at mail.symlynX.com (Carlo v. Loesch)
Subject: [Standards-JIG] Multicast JEPs in the making
To: standards-jig at jabber.org
Message-ID: <200605170723.k4H7NqS29394 at fly.symlynX.com>
Content-Type: text/plain; charset=iso-8859-1

hello friends of openly federated messaging, i salute you.

excuse the surprise, but from our ietf experience we have learned
that implementing ideas and writing spec drafts for them brings
things forward quicker than publicly discussing unfinished ideas.
so we have implemented a plan for smarter distribution of
one-to-many message types between servers and are now in the
process of writing the appropriate JEPs to them.

we have opted for a step-by-step plan which is minimally invasive
to the existing XMPP protocol syntax and allows developers to enjoy
little improvements with each step, without having to implement
the complete thing in one shot.

'Smart Presence' as a protocol extension is actually a protocol
reduction which integrates totally naturally into the existing XMPP
syntax: we simply leave the to= field out on interserver messages
and maintain a few data structures on the receiver's side so
it knows where to forward things to. the same principle applies
to MUC. this already reduces interserver traffic a lot.

in a further JEP we will specify how to make listening servers
chain into each other to form a multicast tree. this will also
be a simple extension on top of the "smart" distribution JEPs.

so expect 3 easy to digest JEPs that will not bring any new
features for end-users really, but will help jabber become much
more scalable than it is today.

concerning pubsub we have realized that the current pubsub model
is so extremily feature rich, that a switch to a multicast
distribution scheme is not an easy task. you can either reduce
the features of pubsub dramatically in favor of quickly deploying
a scalable pubsub system, or we can sit down and do a very long
and intense redefinition of the pubsub interserver protocol.
we have already written down notes on what would need to be done,
if you're interested, but it is too much to quickly come up with
a JEP.

the JEPs do not address negotiation yet, as we first wanted to
have your feedback, and we want to leave it to you to decide
which type of negotiation is adequate. is it a protocol feature,
or is it a new version of XMPP?

we are looking forward to discussion with you, JEPs are made to
be edited further. it is up to you to take our experience in
multicast chat as a starting point for jabber's needs, or to come
up with something completely different.

kind regards from berlin,

More information about the Standards mailing list