[Standards] Council on Stanza Repeaters without Multicast

Dave Cridland dave at cridland.net
Wed Apr 2 23:22:16 UTC 2008

On Wed Apr  2 23:22:12 2008, CvL at mail.symlynX.com wrote:
> I was pointed to your council meeting log at
> http://logs.jabber.org/council@conference.jabber.org/2008-04-02.html
Given that PSYC's webpages suggest that "Only politics can stop that  
now", I think we may be off to a non-useful conversation, here, but  

> Some thoughts and numbers about
> http://www.xmpp.org/extensions/inbox/repeaters.html
> you discussed between 14:40 and 14:55.
> <Kev> this is an odd spec - it loses us the 'no spoofing' which we
>       currently enjoy
> I notice what you mean.. repeaters have double 'from'.. the sending
> server and the originating sender. In a simple no-trust situation
> these SHOULD be on the same host or domain, then my server is merely
> sending stanzas in my name in a more efficient way. That's something
> to add to "10. Security Considerations".
Yes, I concur that this - although weird - doesn't introduce any  
fundamental security issues if done right. However, it does make it  
easier to break thing at the implementation stage.

> <Dave> I'm not wholly convinced that, in the current design, it will
>        actually result in "better" network usage.
> <Dave> The single thing that worries me most on this is simply that
>        nobody seems to have done any figures on whether this  
> genuinely saves
>        bandwidth.
> I know Fippo's postings aren't the easiest read. He expects  
> everyone to
> be as deep in it as he is himself. He has used stpeter's model from
> http://www.xmpp.org/internet-drafts/draft-saintandre-xmpp-presence-analysis-03.html
> found a bug in the formulas, then with the corrected formula  
> figured out
> numbers for scenario 5.1 as follows:
> 	580000000 for the "standard" behaviour of xmpp (also dubbed "rfc")
> 	251200000 for repeaters XEP
> 	197200000 for smart presence XEP from 2004
> For completeness, smart presence is here:
> http://www.xmpp.org/extensions/inbox/smartpresence.html
> It basically does the same as repeaters, but focused on presence  
> only.
Right, but *NONE OF THESE* figures take into account two things:

A) Compression

It's crucial on two counts:

1) It's much simpler to implement, and 
2) Given that we are (or should be) encrypting every S2S connection,  
then TLS is giving us compression anyway, and moreover, it's cheaper  
to compress than not to compress.

We've been down the road before where on some admittedly fairly  
simple figures I did a while back - and repeated for Peter's  
scalability draft in the SIMPLE WG, I think - the existing presence  
"splurges" compress really well, often better than the "optimized"  

Smart Presence was one proposal that beat pure compression, as I  
recall, but it has security implications which I'm not going to  

B) RTT delays

The introduction of Stanza Repeaters gives us RTT delays whenever a  
list needs changing. That just strikes me as worrying - I don't think  
anyone has clear figures on how much delay would be introduced, but  
I'm sure you'll agree that additional latency does not a performance  
improvement make.

It may be possible to alter the protocol to remove these.

> He resumes:
> | Regardless of protocol details, the concept of remote fan-out  
> using
> | lists stored on the remote side is superior to the "current" way  
> of
> | doing things.
That's an opinion, not a fact. The facts are that Stanza Repeaters  
*do* introduce at least some round-trips, and have not been  
considered WRT post-compression figures, which the scalability drafts  
specifically don't touch because it would put XMPP in such a horrific  
advantage to SIMPLE, and is exceedingly difficult to put into a  
simple formula.

> This isn't even taking into account what a huge gain repeaters
> represent when applied to MUCs. large pubsubs also start having
> a chance to actually scale.
But you can do both MUC and PubSub way better if you design something  
specific to them, and I think that's possible to do.

> All of this gets even better when you apply real multicast to it,
> but you don't need to worry about that now. You are already
> improving a lot by being more strategic in the way you unicast.
> That is what the repeaters XEP and similar earlier protoXEPs  
> propose.
Unfortunately, your notions of junctions and multicast simply don't  
fit the security model of XMPP. They do, however, work perfectly well  
if considered as a highly distributed XMPP cluster, but that's  
another story.

> <Kev> right, we don't have, still, afaik a decent model for testing
>       the effect of such things on 'real' usage
> I hope stpeter's draft isn't the worst of choices.
Not the worst of choices, but bear in mind that the draft in question  
was a comparison to a draft discussing SIP/SIMPLE scaling - it  
doesn't match XMPP usage, but a rather sterile guess at probable  
activities of SIMPLE users. So Kevin's right here - we don't have a  
decent model, and the best one we have is basically forced on us from  
another protocol.

> Not at all. My sendmail is busy until next day to distribute to a  
> few
> thousand recipients. Ok, sendmail is stupid, but I wouldn't want it  
> to
> try to connect a thousand hosts at the same time. IRC can handle  
> that
> much better, so does PSYC. How? It just forwards to some thirty  
> hosts
> which themselves forward to some thirty hosts. Stuff arrives in near
> real-time, even with thousands of recipients. That's why multicast  
> is
> the only way to go. And persisting recipient lists is fundamental to
> have a ghost of a chance of being scalable. I've done this stuff for
> a decade now, you can trust I know what I'm talking about.
Unfortunately, email did this for several years - probably before  
your time - and look what happened.

And please don't say that IRC has done this for several decades,  
unless you want me to have you explain how I can run up my own IRC  
server and talk to anyone else on IRC. Consider, for a moment, why  
I'm sending you this using SMTP, and not X.400 (my mailserver *DOES*  
speak both).

So no, I'm not going to trust you. In fact, it's my job here not to  
trust you, so don't take that personally.

> <Dave> I'm pretty sure it'd be easy to write a repeater that did  
> allow
>        spoofing, and moreover, bypassing of privacy lists, etc.
>        But I don't think it's a fundamental property of repeaters.
> With the security set-up in place, you can only mess up your local
> data, as always. Repeaters, if properly defined, are just an  
> optimization.
> Why shouldn't the packets inside be treated to the same scrutiny as
> any packet?
Because they pass through a different code-path, there is a stronger  
likelyhood of bugs.

> <stpeter> Dave: it saves bandwidth compared to XEP-0033
> <stpeter> (which may not be saying much)
> <Dave> stpeter, No, I mean, does it save bandwidth compared no not  
> having it.
> No comment.
I hope my comments above have explained that in more detail.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list