[Standards] Council on Stanza Repeaters without Multicast

Carlo v. Loesch CvL at mail.symlynX.com
Fri Apr 4 13:35:05 UTC 2008


Dave Cridland typeth:
| again, it gives directed acyclic routing to MUC, which repeaters  
| don't do. (Well, I hope not).

My Multicast Repeaters suggestion does just that, but without
the overhead of having MUC apps running on every node.
Why do you hope Repeaters do not solve your problem?

Two years ago you guys decided to bet on XEP-0033. This time
you want to place your bets on IRC-like decentralized conference
control? We've gone that path in PSYC before, and stepped back
to a generic routing plan. Less likely to produce bugs. Since
we don't have redundant subscription protocols the whole thing
is a bit cleaner in PSYC.

Whichever wheel you choose to invent, I don't know of any that
hasn't already been driven.

| I don't think we'll have a problem scalaing presence, because I don't  
| think it really needs to be scaled - it's neither low-hanging fruit,  

 [x] You underestimate the problem.

| It's certainly reasonable that we'd save a few stanzas by doing  
| something similar to repeaters or smart presence, but I think we'd be  
| saving perhaps 5 stanzas per presence burst, as opposed to several  
| thousand, potentially, per MUC or PubSub event. That's not  
| insignificant, but I'm far from convinced it's worth doing for that  
| sake alone.

With typically over 70% of XMPP inter-server traffic being presence
data[3], and close to 60% of it being redundantly transmitted[4], XMPP
currently has a large overhead in delivering presence data to multiple
recipients. New protocols are being researched to alleviate this
problem.

 [3] http://mail.jabber.org/pipermail/standards/2006-May/011158.html
 [4] http://mail.jabber.org/pipermail/standards/2006-May/011182.html

A few things may have changed since 2006, and of course there is
more gain in MUC and pubsub, but you can't say that 50% protocol
overhead is not a significant issue.

| Maybe. But I'm far from convinced, and I'm concerned that a strategy  
| which attempts to convolve MUC, PubSub, and Presence scalability  

It would be a good idea to adapt MUC, pubsub and presence to use a
common generic subscription model with multicast distribution, rather
than figure out a different distribution strategy for each protocol
application.

| Incidentally, repeaters are simply a slightly more explicit, and  
| generic, model of smart presence, and the (then-) council dropped  
| that. The biggest difference is that Repeaters are proposed by people  
| well-known to the community, and that's not a particular useful  
| technical argument to me. (It does mean that there's a greater chance  
| that the proposal fits the XMPP model, as in this case, but it  
| doesn't make it automatically technically better.)

Hehe. Nice to hear that from you.
Anyway, it may have improved the council's understanding of the issue.
So after being mislead by XEP-0033 this time around they have a new
chance of taking a wiser decision. Of course there are things that
can be improved about Repeaters, but the path you are heading out to
is going to keep XSF busy for several more years until XMPP is
actually a viable solution to the problems. Until then you will
honestly have to admit, that large chatrooms and pubsubs are better
done with IRC channels and bots (they don't have a nice XML structure,
but they work up to close to a million participants), in case someone
asks. You could also mention PSYC, which has nice structures and scales
even better, but I bet you won't do that.

| We know that compression+XEP-0033, for example, yields fewer stanzas  
| but greater bandwidth than compression alone. We know that "Smart  
| Presence" yields both fewer stanzas and less bandwidth, but fails to  
| match our model - I don't think it matches the model in its last  
| incarnation, and there's way too much handwaving in that protocol.

Please define "handwaving" and mention the exact parts of the document
that you would like to have modified.




More information about the Standards mailing list