[Standards] Council on Stanza Repeaters without Multicast

Philipp Hancke fippo at goodadvice.pages.de
Tue Apr 8 12:06:06 UTC 2008

Dave Cridland wrote:
> On Fri Apr  4 15:55:26 2008, Philipp Hancke wrote:
>> Dave Cridland wrote:
>> [...]
>>> Sure, I think everyone here does. I sincerely hope so, anyway - we
>>> will have significant impact here in the future.
>> We agree that messages should be sent only once per link?
> Ideally, yes. In fact, ideally, less than once, although that's often
> difficult. (This isn't sarcasm - it is possible)

My bad. That should have been "at most once" of course ;-)

> No, any time the repeater expands to <= 2 jids, there's also no gain,
                                      ? why not < 2. Wrapping overhead?
I think n=1 can be handled as a special case that reduces repeater
creation to noop and usage to the normal behaviour.

> and a significant hit on complexity. It's the complexity bit I'm worried
> about.

Likewise, I am worried about the complexity of detecting if a presence
broadcast / muc message storm is legitimate. Repeaters simplify that

> http://hancke.name/jabber/repeater-usage.html is great, by the way, but
> really does read to my eyes like an argument against them - hideously
> complicated.

The unsubscribe and exit operations with their impact on the trust rules
made me dislike it.

The flows become much simpler under the following assumptions:
* Repeater addresses can be computed in advance (eliminates
  round-trips btw). The algorithm in version 0.0.1 of the proposal
  seemed  quite good (unfortunately, the editors inbox has no attic
  versions). Service discovery extensions even probably provide enough
  flexibility to let the remote domain choose the hash length according
  to its needs (security/scaling vs additional bytes).
* the JIDs that are added/removed from the repeater are taken from the
  'to' attribute of the stanza

The result is here: http://hancke.name/jabber/repeater-usage-0.2.html
Essentially smart-presence and smart-muc with added hash to take
care of any sync issues. The repeater syntax is really useful, as
it enables re-sync and a solution for the polite-blocking feature.

>>> The result of solving them would be that PubSub would almost
>>> spontaneously grow directed acyclic routing, and this would be
>>> virtually transparent to clients, and to a large degree, transparent
>>> to servers. Note that this is more powerful than repeaters, as well
>>> as simpler.
>> As long as the local server (slave) rewrites the address to that of the
>> "master". Otherwise you have a usability problem ("but I want to join
>> jdev at conference.jabber.org, not 12431AFA at myserver"). Make it transparent
>> to the client.
> Absolutely. This isn't terribly easy, unfortunately, since the local
> server has to do some clever handling of directed presence.

At least most major clients include
<x xmlns='http://jabber.org/protocol/muc'/>
these days. The channel prefix of IRC is a much more simple and
effective solution though :-)

>>> Again, we gain a lot from this. It's a simple design, and one that
>>> can potentially get us some resilience to failure, which is nice. And
>>> again, not my design, and not a particularly new suggestion.
>> IRC is there, you can't really come up with something brilliant new
>> that can't be interpreted as "irc does it almost the same" ;-)
> Well, absolutely. Although this is actually much closer to PSYC, as I
> understand it.

We like both approaches. master/slave when we need the additional
flexibility of implementing local behaviour (split mode, moderation,
etc), master-controlled with fan-out-only as the default.

Most of the problem IRC has with this are due to the lack of authority.
"Nicknames are not owned" was the second wrong decision in its history.

>>> If we solve scalability in MUC and PubSub - and I think we can
>>> *without* repeaters, and I think that repeaters are not well
>>> understood, and may cause greater harm than good - then I think this
>>> is way beyond good enough. I believe that for both MUC and PubSub,
>>> using a slave entity which passes on subscriptions to a master
>>> entity, and manages
>> may pass on for "open" nodes ;-)
> I think MUST at all times.
> First off, open nodes should get the statistics. This is arguably a
> political choice rather than technical, but I suspect that if a feed
> publisher knows there are several million subscribers, they'll make more
> effort in their XMPP strategy.

Live statistics are costly. A "I distributed your message to x
recipients" statistics in reply to a publish accomplishes almost the
same. The backdraft (for the publisher) is that he won't see who got
this, just anonymous numbers. Which is a benefit for the users privacy.

>>> redistribution backwards, will yield equal or high efficiency, with
>>> much simpler implementation, fewer security issues (in implementation
>>> or design), and will give us all the benefits of a tree-based
>>> heirarchical distribution without breaking any trust models.
>> You can apply the same master-slave design to presence.
>> The recipient list modification operations will be different for the
>> three use-cases, but the plan stays the same.
> It's possible that we could, indeed I'd hate to say we never will, but
> I'm not sure the outlay in complexity covers it.

There is probably only one way to find it out. Implementing it and
see how it works in practice.

> A full solution to its woes would be essentially indistinguishable for
> Stanza Repeaters, so there's little point in doing so, but anyway, the
> point is that these three cases are not actually as similar as one might
> hope, and the case that has the highest cost in terms of complexity is
> also the one which has the lowest gain.

The SIMPLE people consider presence a problem. On the other hand,
comparing XMPP and SIMPLE is comparing apples and oranges.

> So I think the sane strategy is to simply ignore it for now. :-)

Attach less value to it and make it 'network transparent'.
polite blocking does not work anyway ;-)

> Why is it that people prefer the idea of "buy two get one free" to "2/3
> price"? The supermarkets love it, of course, because the consumer ends
> up buying things they do not actually want - often, people will buy two
> just for the additional one, even though they only wanted one to begin
> with.

"Pappa ante Portas" (if available from your video shop) will enlighten

What you most likely get for free is the xcast_send operation.
Getting rooms and presence under the same hood was quite beneficial
for us.

> But, that short digression aside, we can get - using the same
> methodology, although a different protocol - good scaling on MUC and
> PubSub. We might get something similar on Presence and PEP, too, but I'm
> not holding my breath.

The impact of remote fan-out on pep is interesting. Notification
filtering on the remote server instead of the user's server is MUCH
cheaper then.

Presence is most likely the hardest of the three. It may require more
than one repeater per source-jid. That could also be a feature.


More information about the Standards mailing list